Контрольный список для уязвимостей программирования веб-сайтов

Question

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

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

Answer 1

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

1. Уязвимость OWASP Top Ten (pdf)
2. Для более болезненного исчерпывающего списка: Категория: Уязвимость

Десятка лучших:

1. Межсайтовый скриптинг (XSS)
2. Недостатки внедрения (SQL-инъекция, внедрение скрипта)
3. Вредоносное выполнение файла
4. Небезопасная прямая ссылка на объект
5. Подделка межсайтовых запросов (XSRF)
6. Утечка информации и неправильная обработка ошибок
7. Сломанная аутентификация и управление сессиями
8. Небезопасное криптографическое хранилище
9. Небезопасная связь
10. Неспособность ограничить доступ к URL

Answer 2

Я передаю информацию OWASP как ценный ресурс. Также могут представлять интерес следующие особенности атак, а именно:

• CERT Топ 10 методов безопасного кодирования
• Перечисление и классификация шаблонов общей атаки
• Шаблоны атак
• Безопасное программирование для Linux и Unix
• Таксономия ошибок кодирования, влияющих на безопасность
• Безопасное программирование с представлением статического анализа

Answer 3

Некоторые методы профилактики:

XSS

• Если вы берете какие-либо параметры / ввод от пользователя и когда-либо планируете его выводить, будь то в журнале или на веб-странице, очистите его (удалите / удалите все, что напоминает HTML, цитаты, JavaScript) Вы печатаете текущий URI страницы внутри себя, дезинфицируете! Например, даже печать PHP_SELF небезопасна. Санируйте! Отражающий XSS происходит в основном из неанизированных параметров страницы.

• Если вы берете какие-либо данные от пользователя и сохраняете их или распечатываете, предупреждайте их, если обнаруживается что-либо опасное / недействительное, и повторяйте их ввод. IDS хорош для обнаружения (например, PHPIDS). Затем выполните санитарную обработку перед хранением / печатью. Затем, когда вы печатаете что-то из хранилища / базы данных, снова выполните санитарную обработку! Входные данные -> IDS / sanitize -> store -> sanitize -> output

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

XSRF

• Никогда не использовать запрос GET для разрушительная функциональность, т.е. удаляя пост. Вместо этого только принимать запросы POST. GET облегчает взлом.
• Проверка реферер, чтобы убедиться, что запрос пришел с вашего сайта не работа . Это не сложно подделать реферер.
• Используйте случайный хеш в качестве токена, который должен присутствовать и действовать в каждом запросе, и срок его действия истекает через некоторое время. Распечатайте токен в скрытом поле формы и проверьте его на стороне сервера при публикации формы. Плохие парни должны будут предоставить правильный токен, чтобы подделать запрос, и если им удастся получить реальный токен, он должен быть до его истечения.

SQL-инъекция

• в вашем классе абстракции ORM или db должны быть методы очистки - используйте их всегда. Если вы не используете класс абстракции ORM или db ... вам следует.

Answer 4

Очевидно, проверьте каждое поле на наличие уязвимостей:

• SQL - escape-строки (например, mysql_real_escape_string)
• XSS
• HTML печатается из полей ввода (обычно это хороший признак XSS)
• Все, что не является конкретной целью, для которой было создано поле

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

Answer 5

Вы можете получить хорошие аддоны Firefox для тестирования множества недостатков и уязвимостей, таких как инъекции xss и sql из Security Compass . Жаль, что они не работают на Firefox 3.0. Я надеюсь, что они будут обновлены в ближайшее время.

Answer 6

G'day,

Хорошим инструментом статического анализа для обеспечения безопасности является FlawFinder , написанный Дэвидом Уилером. Он хорошо справляется с поиском различных мер безопасности,

Однако это не заменяет умелое чтение кем-то вашего кода. Как говорит Дэвид на своей веб-странице: «Дурак с инструментом все еще дурак!»

НТН.

веселит, Rob

Answer 7

Легко контролировать и легко исправить: очистка данных, полученных со стороны клиента. Проверка на такие вещи, как ';' может помочь предотвратить внедрение вредоносного кода в ваше приложение.

Answer 8

XSS (межсайтовый скриптинг) Атаки

Answer 9

SQL-инъекция