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

Question

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

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

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

Answer 1

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

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

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

3. Честно говоря, я обычно позволяю таким инструментам, как AppScan, BURP-прокси, 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 / безопасность / index.html

Answer 2

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

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

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