Re[5]: Чем грозит склейка данных?
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.10.09 13:52
Оценка: 77 (3)
Здравствуйте, DOOM, Вы писали:
ость возникает в момент ескейпленья/квочения. Если сделать его неаккуратно, то можно получить всё, что угодно.

DOO>Вообще есть 2 стратегии защиты от кривых данных пользователя:

DOO>1) Пытаться вырезать (заквотить) все "опасные" символы.
DOO>2) Пытаться все-таки понять, что ожидается от пользователя и прикрутить строгие валидаторы.

DOO>Да очень просто — при вставке в БД символы \r\n будут вполне себе невинными


А также, например, символы %0d+%0a ...

DOO>Вывод: данные единожды полученные от пользователя могут использоваться в заранее непредсказуемом количестве мест, соответственно, единовременная очистка от опасных символов ничего не гарантирует и в коде придется проводить такую очистку каждый раз для всех данных, которые хотя бы потенциально содержат полученные от пользователя значения. Понятно, что это нереально — поэтому лучше использовать вариант 1 — строгие валидаторы (естественно, на стороне сервера — но лучше и там, и там, чтобы пользователи не материли).


Есть еще:

а) продолжение второй стратегии: понять что ожидается отдавать пользователю и прикрутить такие же строгие валидаторы на выходе, как и на входе.

б) третья стратегия (параноидальное развитие идей второй): реализовать в приложении строгую типизацию параметров всех точек входа (т.е. нарисовать на собственном DSL или в конфиге или чистом XML и т.п., контракты всех точек входа в веб-приложение и тестировать данные, получаемые в запросах, на предмет соответствия их типов, декларированных для данной конкретной точки входа, бросая исключение несоответствия типов, если нам пытаются подсунуть что-то другое). Вкупе со строгой валидацией форматов параметров (в т.ч. соответствия, скажем строк, конкретным регуляркам, диапазонов числовых типов и т.п. и тестированием строк на НЕсоответствие конкретным регуляркам, типа этих) это дает лучший эффект. Главное, результаты проверок типов и форматов где-нибудь кэшировать, а то DOS будет обеспечен.

Третью стратегию видел (точнее участвовал в реализации ) уже на двух продуктивных приложениях, причем одно из них позиционируется как high-load. Всей группой тестили — замечаний так и не выкатили.

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.