Я не полностью согласен с другими предоставленными ответами, поэтому я опубликую свои рекомендации.
Рекомендуемое чтение
XSS_ (Cross_Site_Scripting) _Prevention_Cheat_Sheet
Инъекция HTML:
Всякий раз, когда отображается любое представленное пользователем содержимое, оно должно быть соответствующим образом очищено с помощью htmlspecialchars или htmlentities при указании ENT_QUOTES, если используется внутри одинарных кавычек. Я бы рекомендовал никогда не заключать в одинарные кавычки и всегда заключать в атрибуты двойные кавычки (не опускайте их). Это относится к таким вещам, как:
<input value="<?php echo htmlspecialchars($var); ?>" />
<textarea><?php echo htmlspecialchars($var); ?></textarea>
<p><?php echo htmlspecialchars($var); ?></p>
<img width="<?php echo htmlspecialchars($var); ?>" />
Инъекция JavaScript:
Рекомендуется (но не всегда практично) никогда не отображать пользовательский контент в событиях и JavaScript. Тем не менее, если вы делаете, есть некоторые вещи, которые можно сделать, чтобы уменьшить риск. Только передать целочисленные идентификаторы. Если вам требуется что-то вроде спецификатора типа, то перед выходом используйте белый список и / или условную проверку. Возможно принудительное использование пользовательского контента в буквенно-цифровом формате только при необходимости; preg_replace("/[^A-Za-z0-9]/", '', $string); но будьте очень осторожны с тем, что вы разрешаете здесь. Включайте контент только тогда, когда он заключен в кавычки, и обратите внимание, что htmlspecialchars / htmlentities вас здесь не защищает. Он будет интерпретироваться во время выполнения, даже если он был переведен в HTML-сущности.
Это относится к таким вещам, как:
<a href="www.stackoverlow.com/?id=<?php echo (int)$id; ?>">Click</a>
href, src, style, onClick, etc.
Не передавайте какой-либо пользовательский контент в другие области, такие как тело тегов сценария и т. Д., Если только он не был принудительно переведен в int или какой-либо другой очень очень ограниченный набор символов (если вы знаете, что делаете).
SQL-инъекция:
Используйте Подготовленные операторы , привязывайте к ним пользовательский контент и никогда не вставляйте пользовательский контент напрямую в запрос. Я бы порекомендовал создать класс для подготовленных операторов с помощью вспомогательных функций для ваших различных базовых типов операторов (и, находясь в этой теме, функционализировать все ваши операторы базы данных). Если вы решите не использовать подготовленные операторы, тогда используйте mysql_real_escape_string () или аналогичный (не addlashes ()). Проверяйте содержимое, когда это возможно, перед сохранением в базе данных, например, форсирование / проверка целочисленного типа данных, условные проверки типов и т. Д. Используйте надлежащие типы и длины столбцов базы данных. Помните, что основной целью здесь является предотвращение внедрения SQL, но вы также можете сделать здесь защиту от внедрения HTML / Javascript.
Другие ресурсы
Я провел некоторые исследования в Интернете в надежде найти простое решение, уже общедоступное. Я нашел OWASP ESAPI, но он выглядит довольно устаревшим. Ссылки на версию php не работают в нескольких местах. Я полагаю, что нашел это здесь; ESAPI PHP но, опять же, он устарел и не так прост, как я надеялся. Однако вы можете найти это полезным.
В общем, никогда не думайте, что вы защищены, например, используете htmlentities в атрибуте onClick. Вы должны использовать правильный инструмент в правильном месте и избегать действий в неправильном месте.