Общие уязвимости для приложений WinForms

Я не уверен, что это по теме или нет, но это так специфично для .NET WinForms, что, я считаю, здесь имеет больше смысла, чем на сайте security stackexchange.

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

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

Пример:

SQL Injection (Owasp A-1)

Стандартная практика
- Использовать хранимые параметризованные процедуры, где это возможно, для доступа к данным, где это возможно.
- Использовать параметризованные запросы, если хранимые процедуры невозможны. (Использование сторонней БД, которую мы не можем изменить)
- Сбросить одиночные кавычки, только если указанные выше варианты невозможны.
- Разрешения базы данных должны быть разработаны с принципом наименьших привилегий.
- По умолчанию пользователи/группы не имеют доступа
- При разработке документируйте доступ, необходимый для каждого объекта (Таблица/Просмотр/Сохраненная процедура) и бизнес-потребность для доступа.
- [надрез]

В любом случае мы использовали Top 10 OWASP в качестве отправной точки для общеизвестных уязвимостей, характерных для веб-сайтов.

(Наконец, на вопрос)

В редких случаях мы разрабатываем приложения WinForms или Windows Service, когда веб-приложение не отвечает потребностям. Мне интересно, есть ли эквивалентный список общеизвестных уязвимостей безопасности для приложений WinForms.

Сверху моей головы я могу думать о нескольких...

SQL Injection по-прежнему вызывает озабоченность.
Переполнение буфера обычно предотвращается с помощью CLR, но это более возможно, если использовать не управляемый код, смешанный с управляемым кодом.
.NET-код может быть декомпилирован, поэтому хранение конфиденциальной информации в коде, в отличие от зашифрованного в app.config...

Есть ли такой список или даже несколько версий такого списка, из которого мы можем заимствовать, чтобы создать собственный? Если да, где я могу его найти?

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

Ответ 1

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

Итак, в некотором смысле, для вас, как разработчика настольного приложения, правила безопасности не всегда применяются, так как приложение, которое вы запускаете, не является черным ящиком, а белым ящиком. С веб-службой/сайтом вы ожидаете, что атаки не смогут изменить внутреннее состояние, но с любым настольным приложением (Java,.NET, native) можно "легко" изменить состояние приложения, пока приложение и особенно с Java и .NET, отладка и декомпиляция приложения довольно просто.

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

Вещи, которые вы должны смотреть, это то, что действительно сложно полностью защитить ваш уровень данных, когда приложение для настольного ПК напрямую подключается к базе данных. Например, SQL-инъекция не является проблемой для вашего настольного приложения в этом случае, так как приложение может напрямую подключаться к базе данных, так что пользователь может. И если пользователь может подключиться к базе данных, он может выполнить любой произвольный запрос. Это крайняя форма SQL-инъекции, но она полностью пропускает ваше приложение.

Попытка защитить двухуровневое приложение часто означает использование хранимых процедур в качестве промежуточного (служебного) уровня (и предотвращения прямого доступа к таблицам). Разработка и обслуживание хранимых процедур намного дороже, чем разработка .NET(веб-сервиса).

Ответ 2

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

В управляемом коде все еще есть все риски безопасности, так как разработчик может открывать все виды дыр. Структура (.NET) не является риском для нее, но разработчик.

Здесь у вас есть список инструментов, вы можете прочитать там, какие угрозы безопасности они будут проверять:

Список анализа статического кода

Но, конечно, есть известные уязвимости, как вы можете видеть здесь:

выполнение удаленных кодов технологий

повышение уровня привилегий

Существуют более известные и не разрешенные недостатки, которые можно найти на известных сайтах безопасности. (включая бесполезные атаки)

** БОЛЬШЕ ПОДРОБНОЙ ИНФОРМАЦИИ, это был контрольный список, упомянутый в комментарии **

Контрольный список безопасности MS (не знаю, почему это "отставке" , поскольку это в основном нейтральная информация

Открытый проект безопасности веб-приложений

MS Anti-межсайтовый скриптинг

Реализация справки по безопасности MS ASP (очень хороший информационный сайт)

CAT.NET... Средство анализа статической безопасности MS

Ответ 3

Я боюсь, что невозможно создать локальное приложение winform, которое действительно безопасно, поскольку пользователи могут всегда взламывать ваши приложения.

Но есть некоторые способы замедлить процесс взлома. Большинство методов выполнялось на уровне сборки, например. мусорные коды и упаковки.

Другой способ состоит в том, чтобы ваши исполняемые коды (то есть коды, которые поступают в память при выполнении программы) изменяются со временем. Однако вы должны сначала убедиться, что все остальные коды (которые не выполняются тогда) безопасны. Это можно сделать с помощью шифрования. Но вы также должны убедиться, что программа шифрования более надежно защищена. Программа шифрования всегда фиксируется в ПЗУ и обеспечивается физическими средствами.

Другой способ - воспользоваться преимуществами сети. Часто обновляйте локальные приложения и запрещайте старые версии. Таким образом, ваш код может изменяться достаточно быстро, чтобы превзойти процесс взлома.

Ох... я бросаю мусор или это просто не по теме? Мои извинения.