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

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

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

Может кто исправит орфографическую ошибку в названии?

mattruma 18.09.2008 18:09
SQL Injection: Атаки в реальной жизни и как это вредит бизнесу
SQL Injection: Атаки в реальной жизни и как это вредит бизнесу
Один-единственный вредоносный запрос может нанести ущерб вашему бизнесу. Уязвимости вашего кода могут привести к:
17
1
1 891
9
Перейти к ответу Данный вопрос помечен как решенный

Ответы 9

SQL-инъекция

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

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

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

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

Ответ принят как подходящий

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

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

В первую десятку входят:

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

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

Доброго времени суток,

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

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

HTH.

ваше здоровье, Роб

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

XSS

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

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

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

XSRF

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

SQL-инъекция

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

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

Другие вопросы по теме