Путями я могу защитить свой сайт, исключая XSS и Внедрение SQL?
Так, члены моего веб-сайта могут отправить темы, ответы, комментарии, отредактировать их и так далее. Я всегда использую htmlspecialchars и addslashes чтобы вводы HTML защитили мой сайт от XSS и атак с использованием кода на SQL. Это достаточно или является там чем-то больше, что я отсутствую?
Спасибо.
6 ответов
В веб-приложениях многое может пойти не так. Помимо XSS и SQLi, существуют:
- CSRF - Cross Site Request Forgery
- LFI/RFI - Local File Include/Remote File Include, вызванные
include(),require()... - Инъекция CRLF в
mail() - Обращение к пространству имен глобальных переменных, вызванное
register_globals,extract(),import_request_variables() - Обход каталога:
fopen(),file_get_contents(),file_put_contents() - Удаленное выполнение кода с
eval()илиpreg_replace()с/e - Удаленное выполнение кода с
passthru(),exec(),system()и ``
Существует целое семейство уязвимостей, касающихся Broken Authentication and Session Management, которое является частью OWASP Top 10, который каждый программист веб-приложений должен прочитать.
A Study In Scarlet - хорошая черная книга, в которой рассматриваются многие из перечисленных мной уязвимостей.
Однако есть и странные уязвимости, такие как эта в Wordpress. Окончательным авторитетом в том, что такое уязвимость, является система CWE, которая классифицирует СТОЛЬКО уязвимостей, многие из которых могут влиять на веб-приложения.
Вы должны использовать mysql_real_escape_string() для SQL, а не addslashes. (Предполагается, что вы используете MySQL)
Лучший подход для защиты от SQL-инъекций - использовать функцию escape, специально написанную для каждой базы данных - например, для PostGreSQL используйте pg_escape_string для экранирования строковых полей перед вставкой их в базу данных. Или, в вашем случае, используйте mysql_real_escape_string.
SQL-инъекция:
Никакие дополнительные косые черты и mysql_real_escape_string сами по себе не помогут. Но только при соблюдении некоторых правил. И даже тогда этого недостаточно. Вот почему подготовленные операторы лучше подходят для новичков - они не требуют размышлений.
И экранирующие, и подготовленные операторы могут помочь только с данными . Для операторов / идентификаторов есть особые правила. (Впрочем, ничего страшного - каждая возможная комбинация должна быть жестко закодирована в скрипте)
XSS:
Не разрешать пользователям использовать HTML.
Чтобы предотвратить это, можно использовать как strip_tags () (без разрешенных тегов), так и htmlspecialchars () .
Если вы хотите разрешить некоторую разметку, подумайте об использовании BB-кода.
CSRF:
Любая значимая форма должна содержать уникальный токен, который следует сравнивать с токеном, сохраненным в сеансе.
Вы должны использовать подготовленные операторы (см. PDO ), чтобы предотвратить SQL-инъекцию. При выводе содержимого htmlspecialchars () кажется достаточным для предотвращения XSS.
Также просмотрите эти ссылки, чтобы узнать о других способах защиты вашего сайта:
http://phpsec.org/projects/guide/
При вставке данных в базу данных используйте подготовленные операторы. PDO лучше, чем mysql_real_espace_string.
При отображении данных, таких как комментарии, сообщения, используйте htmlentities.