Тестирование веб-безопасности
По вашему опыту, что вы обнаружили, над чем работали или сталкивались с точки зрения уязвимостей сайта? И какие действия вы предприняли для смягчения этих проблем?
Это может включать в себя XSS (межсайтовый скриптинг), атаки SQL-инъекций, устаревшие DDOS или попытки фишинга со стороны клиентов вашего сайта. Только вчера я наткнулся на целый раздел инструментов Firefox для аудита сайтов и их потенциала для различных уязвимостей.
Я хочу расширить свои знания в этой области, чтобы получить дополнительную информацию для чтения или изучения - это всегда хорошо - ценные ссылки тоже приветствуются! И военные истории о худшем, которое вы обнаружили, или о самой страшной дыре, которую вы видели - учиться на собственном опыте иногда лучше!
2 ответа
Я сделал обзор безопасности, белого и черного ящиков, для десятков (сотен?) Приложений и сайтов.
XSS и SQL-инъекции получают много прессы, но знаете, что я считаю наиболее распространенным недостатком безопасности? Оставляя функциональность отладки и тестирования в производственном коде. Либо путем подделки параметров POST (isDebug=True), либо путем паутинга сайта и поиска оставшихся страниц, это худшие ошибки, которые я вижу в отношении безопасности. Если вы включаете тестовый / отладочный код, поместите его в отдельную ветвь кода или хотя бы подготовьте контрольный список для удаления до запуска.
Следующая наиболее распространенная уязвимость, которую я видел, - это просто возможность обходить механизмы безопасности путем получения URL-адреса из источника страницы. Техническое название - "Принудительная навигация" или "Принудительный просмотр". Это может сделать любой, кто умеет читать HTML, но меня удивляет разнообразие уязвимых приложений. Вчера, просматривая сайт покупки билетов, я смог купить билеты на аншлаговые шоу, используя этот метод. На предыдущих сайтах мне удалось вообще пропустить оплату (многие, многие сайты Paypal передают URL-адрес "покупки завершен" через PayPal через параметры POST - yoink!). Вам нужна какая-то внутренняя проверка состояния или проверка, чтобы обеспечить завершение, оплату, доступность, точность и т. Д.
Честно говоря, я обычно позволяю инструментам, таким как AppScan, BURP-прокси, WebScarab, Fortify, FindBugs или YASCA (в зависимости от бюджета и доступности исходного кода), находить для меня атаки XSS и SQL-инъекциями. Я сам попробую простые вещи, поищу очевидные дыры, но слишком много известных комбинаций, чтобы попробовать себя. Я держу небольшую коллекцию скриптов и тестовых случаев для более продвинутых или недавно обнаруженных недостатков.
Я собираюсь остановиться на 3, потому что я действительно могу продолжать весь день, я теряю внимание на ваш вопрос, и никто не хочет читать текстовую стену.
Некоторые ресурсы для новых и опытных гуру веб-безопасности: (ARGH. Я пока не могу официально публиковать ссылки. Копировать / вставить. Извините)
Открытый проект безопасности веб-приложений (OWASP)
Руководство по тестированию веб-безопасности
Эта книга написана для аудиторов, тестировщиков и меньше для разработчиков. Что довольно необычно для книги О'Рейли.
websecuritytesting.com
Классификация уязвимостей с помощью Fortify
www.fortify.com/vulncat/
Перечисление общей слабости (предупреждение: обширное)
nvd.nist.gov/cwe.cfm
Перечисление и классификация шаблонов общих атак (предупреждение: еще более обширное)
capec.mitre.org/
Учебные руководства по веб-безопасности Google
(довольно слабый)
code.google.com/edu/security/index.html
Я присоединился к проекту веб-приложения, в котором была библиотека документов. Ссылка на документы была похожа на http://example.com/getdocument?file=somefile.pdf. Конечно, мне просто нужно было попробовать file = / etc / passwd, и, конечно, это сработало.
Решение. Выполните очистку пользовательского ввода и / или используйте некоторый уровень абстракции между ресурсами, запрашиваемыми в URL, и фактическими ресурсами файловой системы.
Это двоюродный брат атак SQL-инъекций. Изучите любой разрешенный запрос, который подозрительно выглядит так, как будто он дает клиенту слишком много контроля.