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

Question

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

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

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

Пример:

SQL-инъекция (OWASP-1)

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

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

(Окончательно вопрос)

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Static code analysis list

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

technet remote code execution

technet elevation of priviledge

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

** получения более подробной информации, это был контрольный я упомянул в комментарии **

MS Security checklist (do not know why this is "retired" as this are mostly neutral infos

Open Web application security project

MS Anti cross-site-scripting

MS ASP security reference implementation (very good information site)

CAT.NET ... MS static security analysis tool

Answer 3

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

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

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

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

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