Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:

А>>Дальше $url будет заэскейплен/заквочен и добавлен в базу данных.
S>Тогда уязвимость возникает в момент ескейпленья/квочения. Если сделать его неаккуратно, то можно получить всё, что угодно.

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

Почему второй способ правильнее? Да очень просто — при вставке в БД символы \r\n будут вполне себе невинными, а когда этот URL будет извлечен из БД и попадет, например, в HHTP response — то эти символы позволят провести атаку под названием HTTP Response splitting.

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