Здравствуйте, DOOM, Вы писали:
ость возникает в момент ескейпленья/квочения. Если сделать его неаккуратно, то можно получить всё, что угодно.
DOO>Вообще есть 2 стратегии защиты от кривых данных пользователя:
DOO>1) Пытаться вырезать (заквотить) все "опасные" символы.
DOO>2) Пытаться все-таки понять, что ожидается от пользователя и прикрутить строгие валидаторы.
DOO>Да очень просто — при вставке в БД символы \r\n будут вполне себе невинными
А также, например, символы %0d+%0a ...
DOO>Вывод: данные единожды полученные от пользователя могут использоваться в заранее непредсказуемом количестве мест, соответственно, единовременная очистка от опасных символов ничего не гарантирует и в коде придется проводить такую очистку каждый раз для всех данных, которые хотя бы потенциально содержат полученные от пользователя значения. Понятно, что это нереально — поэтому лучше использовать вариант 1 — строгие валидаторы (естественно, на стороне сервера — но лучше и там, и там, чтобы пользователи не материли).
Есть еще:
а) продолжение второй стратегии: понять что ожидается
отдавать пользователю и прикрутить такие же строгие валидаторы на выходе, как и на входе.
б) третья стратегия (параноидальное развитие идей второй): реализовать в приложении строгую типизацию параметров всех точек входа (т.е. нарисовать на собственном DSL или в конфиге или чистом XML и т.п., контракты всех точек входа в веб-приложение и тестировать данные, получаемые в запросах, на предмет соответствия их типов, декларированных для данной конкретной точки входа, бросая исключение несоответствия типов, если нам пытаются подсунуть что-то другое). Вкупе со строгой валидацией форматов параметров (в т.ч. соответствия, скажем строк, конкретным регуляркам, диапазонов числовых типов и т.п. и тестированием строк на НЕсоответствие конкретным регуляркам, типа
этих) это дает лучший эффект. Главное, результаты проверок типов и форматов где-нибудь кэшировать, а то DOS будет обеспечен.
Третью стратегию видел (точнее участвовал в реализации
) уже на двух продуктивных приложениях, причем одно из них позиционируется как high-load. Всей группой тестили — замечаний так и не выкатили.