Мне нужно как можно больше предотвращать атаки XSS и централизованно, так что мне не нужно явно дезинфицировать каждый вход.
Мой вопрос заключается в том, что лучше всего санировать все входы на уровне обработки URL / запросов, кодировать / дезинфицировать входные данные перед обслуживанием или на уровне презентации (дезактивация продукта)? Какой из них лучше и почему?
Есть две области, где вам нужно знать:
В любом месте, где вы используете ввод как часть скрипта на любом языке, в первую очередь включая SQL. В конкретном случае SQL единственным рекомендуемым способом решения вопросов является использование параметризованных запросов (что приведет к тому, что в базе данных будет неэкранированный контент, но точно так же, как строки: это идеально). Все, что связано с магическим цитированием символов перед заменой их непосредственно в строку SQL, хуже (потому что так легко ошибиться). Все, что не может быть сделано с параметризованным запросом, – это то, что служба, защищенная от SQL-инъекции, никогда не должна позволять пользователю указывать.
В любом месте, где вы представляете что-то, что было введено как выход. Источник ввода может быть прямым (в том числе через файл cookie) или косвенным (через базу данных или файл). В этом случае ваш подход по умолчанию должен состоять в том, чтобы текст, который пользователь видит , был введенным текстом. Это очень легко реализовать правильно, так как единственными символами, которые вы на самом деле должны процитировать, являются < и & , и вы можете обернуть все это в <pre> для отображения.
Но этого часто бывает недостаточно. Например, вы можете разрешить пользователям делать какое-то форматирование. Здесь всегда так легко ошибиться. Самый простой подход в этом случае состоит в анализе ввода и определении всех инструкций форматирования; все остальное должно быть правильно указано. Вы должны сохранить форматированную версию дополнительно в базе данных как дополнительный столбец, так что вам не нужно много работать, возвращая ее пользователю, но вы также должны сохранить исходную версию, которую пользователь вводит, чтобы вы могли ее искать , Не смешивайте их! В самом деле! Аудируйте свое приложение, чтобы полностью убедиться, что вы получите это право (или, еще лучше, попросите кого-то другого сделать аудит).
Но все, что касается осторожности с SQL, по-прежнему применяется, и есть много тегов HTML (например, <script> , <object> ) и атрибутов (например, onclick ), которые никогда не были безопасными.
Вы искали советы о конкретных пакетах для выполнения работы? Тогда вам действительно нужно выбрать язык. Вышеупомянутый совет полностью не зависит от языка. Дополнительные пакеты / библиотеки могут сделать многие из этапов выше на самом деле очень легкими на практике, но вам все равно нужно быть осторожными.