Как мне решить проблему безопасности доступа к методу в С#?

Я работаю над проектом Point-of-Sale, который предоставляется нашей компании специальным банком .Bank предоставил DLL, которая взаимодействует с POS через USB-порт. Я добавил, что DLL, написанная на языке .NET С#, Поэтому проблем с совместимостью не существует. Существует метод внутри DLL, который называется DebitAndShareTheAmount. Этот метод имеет два основных параметра P1,P2.

P1 - это сумма в открытом тексте, а P2 - это сумма, которая должна быть вычтена из P1 снова в открытом тексте. Поэтому, если я звоню DebitAndShare(1000,10);//, это будет фактически при банковском кредите моя учетная запись с 1000 -10 = 990 $и магазин, используя мое приложение 10 $.

Проблема в том, что любой, кто имеет базовые знания программирования С# и доступа к этому компьютеру SHOP, может установить Visual Studio и использовать эту DLL и вызвать метод DebitAndShare, и вы знаете, что остальное. Фактически наше приложение будет действовать как поставщик услуг и доступны в специальных магазинах по всей стране, владельцы магазина будут оплачиваться путем предоставления услуг в нашем приложении клиентам и их суммы (10 $). Я собираюсь встретиться с разработчиками POS о проблеме безопасности я только что упомянутый.

Я просмотрел книгу MCTS и в разделе безопасности книги, я узнал, что если в DLL банка используется атрибут PublisherIdentityPermission(SecurityAction.InheritanceDemand, [email protected]"SomeCert.cer") перед методом DebitAndShare и пометить этот метод как Защищенный, то у нас может быть один уровень безопасности, это правильно? каковы ваши предложения. Я также думаю, что если банк может дать нам алгоритм шифрования, тогда этого также будет достаточно.

Ответ 1

То, что вы пытаетесь сделать, это остановить ваше приложение от взлома, это похоже на проблему с лицензией с которой я столкнулся ранее, у меня нет отличных решений от сообщества, но только некоторые хорошие предложения, суть здесь неважно, как сильно вы пытаетесь, пока вы выполняете код на компьютере, к которому у пользователя есть доступ, он всегда восприимчив, уходит в сторону от обфускации кода и даже шифрования не может защитить ваше приложение несколько раз от определенного взломщика с достаточным навыком, и, судя по прибыльности возиться с вашим приложением, будет много определенных (единственное, что им нужно знать, что это можно сделать, и они найдет кого-то со своим мастерством).

Я могу показаться пессимистом здесь, но это трудная правда.

Лучший подход, по моему мнению, состоит в том, чтобы переместить части кода, которые с большей вероятностью будут разбиты на центральный сервер, и выставить эти методы как вызовы веб-сервисов. Я знаю, что даже это не совсем безопасно, помните недавний взлом магазина Apple app. Убедитесь, что вы следовали всем лучшим практикам и надежде, вы обнаружите трещину в вашей системе, прежде чем кто-либо еще сделает

Ответ 2

Как видно из комментариев, у вас будет серьезная проблема, обеспечивающая это. Тем не менее, приходят на ум несколько подходов, которые, по крайней мере, помогут.

Пройдите в стек. В своем call-центре просмотрите текущий стек и пройдите назад. Если вы видите что-то, чего вы не ожидаете, то потерпите неудачу. Это не безупречно, но это остановит людей, которые не имеют опыта и/или могут видеть ваш исходный код.
Используйте SecureString и внешний секрет. Это требует, чтобы у вас были какие-то средства получения безопасного значения откуда-то. После этого вы можете зашифровать/подписать данные, чтобы убедиться, что они не были подделаны (через сертификаты или какой-либо другой механизм). Отладчик (a la WinDBG) все равно сможет его разбить, но менее легко.
Восстановите свой код на С++. Машинный код сложнее найти, но это все равно не остановит того, кто знает внутренние окна Windows.

Вместо того, чтобы пытаться очистить океан, защищая ваше приложение, вы можете принять ряд мер, а затем делать то, что делают банки. Ищите шаблоны, которые не имеют смысла. Если определенный POS обычно генерирует значения порядка 100, когда вы видите большой или маленький заказ, отметьте его для проверки. Неожиданное увеличение транзакций? То же самое.

Помимо технических решений, ваш лучший выбор (ИМХО) заключается в том, чтобы убедиться, что магазины частично находятся на крючке для мошенничества. Деньги на линии заставляют людей быть немного более осторожными в отношении того, кто имеет доступ к компьютеру.

Эрик

Ответ 3

Вы можете использовать его так, чтобы функция принимала что-то вроде вашего булавки, чтобы функция вызывала банковскую базу данных, чтобы проверить ваш контакт правильно. Таким образом, по крайней мере, если кто-то получит доступ, сначала придется отключить аргумент pin.

Вы также можете следовать методу Gabe и иметь систему, отображающую учетную запись на устройстве, и сделать так, чтобы функция могла быть доступна только с зарегистрированного устройства. Кроме того, возможно, чтобы исходный код не хранился на банковском компьютере, а на устройстве хранения в банковском хранилище/сейфе. Тогда человек на самом деле должен ограбить банк, чтобы добраться до него. В качестве двойной меры зашифруйте/установите пароль для устройства, чтобы только исходный код мог извлечь только алгоритм дешифрования (в банковской системе, на который разбойники вряд ли вернутся) или известный пароль.

Если это не сработает, у меня нет более разумных идей (если не сохранить источник в корзине или заблокировать источник в ядерном бункере, считается разумным).

Ответ 4

Мы должны использовать задержку подписи. Уполномоченное лицо Банка разворачивает правильно подписанную dll в устройстве. Банк подписывает его своим личным ключом.

Все вызовы через это будут аутентичными, а все остальные будут взломать запросы.