Тестирование веб-безопасности

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

Это может включать XSS (межсайтовый скриптинг), атаки SQL Injection, старый добрый DDOS или попытки фишинга клиентов вашего сайта. Только вчера я наткнулся на целый раздел инструментов Firefox для аудита сайтов и их потенциала на предмет различных уязвимостей.

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


security xss ddos penetration-testing penetration-tools
person Community    schedule 12.11.2009    source источник

Ответы (2)


arrow_upward
7
arrow_downward

Я сделал обзор безопасности, белый ящик и черный ящик, для десятков (сотни?) приложений и сайтов.

  1. XSS и SQL-инъекции широко освещаются в прессе, но знаете, что я считаю наиболее распространенным недостатком безопасности? Оставляя функции отладки и тестирования в производственном коде. Либо подделывая параметры POST (isDebug=True), либо просматривая сайт и находя оставшиеся страницы, это худшие ошибки, которые я вижу в отношении безопасности. Если вы включаете тестовый/отладочный код, поместите его в отдельную ветку кода или, по крайней мере, подготовьте контрольный список для удаления перед запуском.

  2. Следующая наиболее распространенная уязвимость, которую я видел, — это просто возможность обойти механизмы безопасности путем захвата URL-адреса из источника страницы. Техническое название — «Принудительная навигация» или «Принудительный просмотр». Это может сделать любой, кто умеет читать HTML, но я удивлен разнообразием уязвимых приложений. Вчера, просматривая сайт покупки билетов, я смог купить билеты на аншлаговые шоу, используя этот метод. На предыдущих сайтах я мог вообще не платить (многие сайты Paypal передают URL-адрес «совершения покупки» в PayPal через параметры POST — yoink!). Вам нужна какая-то внутренняя проверка состояния или проверка, чтобы гарантировать завершение, оплату, доступность, точность и т. д.

  3. Честно говоря, я обычно позволяю таким инструментам, как AppScan, BURP proxy, WebScarab, Fortify, FindBugs или YASCA (в зависимости от бюджета и доступности исходного кода), обнаруживать атаки XSS и SQL-инъекций за меня. Я попробую простые вещи самостоятельно, поищу очевидные дыры, но слишком много известных комбинаций, чтобы пробовать самому. У меня есть небольшая коллекция скриптов и тестовых примеров для более сложных или недавно обнаруженных недостатков.

Я остановлюсь на 3, потому что я действительно могу продолжать весь день, я теряю фокус от вашего вопроса, и никто не хочет читать стену текста.

Некоторые ресурсы для новых и опытных гуру веб-безопасности: (ARGH. Я пока не могу официально публиковать ссылки. Скопируйте/вставьте. Извините)

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

http://www.owasp.org/

Пособие по тестированию веб-безопасности

Эта книга написана для аудиторов, тестировщиков и в меньшей степени для разработчиков. Что довольно необычно для книги О'Рейли.

websecuritytesting.com

Классификация уязвимостей с помощью Fortify

www.fortify.com/vulncat/

Общее перечисление слабых мест (предупреждение: обширное)

nvd.nist.gov/cwe.cfm

Перечисление и классификация распространенных шаблонов атак (предупреждение: еще больше)

capec.mitre.org/

Руководства Google по веб-безопасности

(довольно слабый)

code.google.com/edu/security/index.html

person Community    schedule 12.11.2009

arrow_upward
1
arrow_downward

Я присоединился к проекту веб-приложения, который включал библиотеку документов. Он ссылался на документы примерно так: http://example.com/getdocument?file=somefile.pdf. Конечно, мне просто нужно было попробовать file=/etc/passwd, и, конечно же, это сработало.

Решение. Выполните очистку пользовательского ввода и/или используйте некоторый уровень абстракции между ресурсами, запрошенными в URL-адресе, и фактическими ресурсами файловой системы.

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

person Community    schedule 12.11.2009