Как я могу защитить свой сайт, исключая инъекции XSS и Sql?

Question

Итак, участники моего сайта могут публиковать темы, ответы, комментарии, редактировать их и так далее. Я всегда использую htmlspecialchars и addslashes для ввода html, чтобы защитить свой сайт от атак XSS и SQL-инъекций. Этого достаточно или я скучаю по чему-то большему?
Спасибо.

Answer 1

С веб-приложением многое может пойти не так. Кроме XSS и SQLi, есть:

1. CSRF - Подделка межсайтовых запросов
2. LFI / RFI - включение локального файла / включение удаленного файла, вызванное include(), require() ...
3. CRLF впрыск в mail()
4. Пространство имен глобальных переменных, обычно вызываемое register_globals, extract(), import_request_variables()
5. Обратный путь в каталогах: fopen(), file_get_contents(), file_put_conents()
6. Удаленное выполнение кода с eval() или preg_replace() с /e
7. Удаленное выполнение кода с passthru(), exec(), system() и ``

Существует целое семейство уязвимостей, связанных с Сломанной аутентификацией и управлением сеансами , которые являются частью OWASP Top 10 , которую должен прочитать каждый программист веб-приложения .

Study In Scarlet - это хорошая черная статья, в которой рассматриваются многие из перечисленных мною уязвимостей.

Однако есть и странные уязвимости, подобные этой, в Wordpress . Окончательным авторитетом в отношении уязвимости является система CWE , которая классифицирует СТО уязвимостей, многие из которых могут влиять на веб-приложения.

Answer 2

Вы должны использовать подготовленные операторы (см. PDO ) для предотвращения внедрения SQL. При выводе содержимого htmlspecialchars () кажется достаточным для предотвращения XSS.

Также взгляните на эти ссылки, чтобы узнать о других способах защиты вашего сайта:

http://phpsec.org/projects/guide/

http://cwe.mitre.org/top25/#Listing

http://www.owasp.org/index.php/Top_10_2010-Main

Answer 3

Вы должны использовать mysql_real_escape_string () для SQL, а не добавляет косую черту. (Предполагая, что вы используете MySQL)

Answer 4

Лучшим подходом для защиты от внедрения SQL является использование функции escape, специально написанной для каждой базы данных - например, для PostGreSQL используйте pg_escape_string для экранирования строковых полей перед их вставкой в ​​базу данных.Или, в вашем случае, используйте mysql_real_escape_string.

Answer 5

SQL-инъекция:

1. Никаких надстрочных знаков, ни mysql_real_escape_string не могут помочь в одиночку.Но только при использовании по некоторым правилам.И даже тогда этого недостаточно.Вот почему подготовленные заявления лучше подходят для новичков - они не требуют размышлений.

2. И экранированные, и подготовленные операторы могут помочь только с данными .Для операторов / идентификаторов существуют разные правила.(Хотя это не страшно - каждая возможная комбинация должна быть жестко задана в сценарии)

XSS:

Не разрешать пользователям использовать HTML.
для этого можно использовать strip_tags() (без разрешенных тегов) или htmlspecialchars().
Если вы хотите разрешить некоторую разметку, рассмотрите использование BB-кода.

CSRF:

Любая значимая форма должна содержать уникальный токен, который следует сравнивать с токеном, сохраненным в сеансе.

Answer 6

При вставке данных в базу данных используйте подготовленные операторы. PDO лучше, чем mysql_real_espace_string.

При отображении данных, таких как комментарии, сообщения, используйте htmlentities.