2008-10-27 3 views
6

У меня на моем сайте есть редактор текстового редактора, который я пытаюсь защитить от атак XSS. Я думаю, что у меня есть все, что нужно, но я все еще не уверен, что делать с изображениями. Сейчас я использую следующее регулярное выражение для проверки URL-адреса изображений, которые я предполагаю, что буду блокировать встроенный Javascript XSS атака:Межсайтовый скриптинг с изображением

"https?://[-A-Za-z0-9+&@#/%?=~_|!:,.;]+" 

То, что я не уверен в том, как открыто это оставляет меня атаки XSS от удаленное изображение. Является ли ссылка на внешний образ серьезной угрозой безопасности?

Единственное, что я могу придумать, это то, что URL-адрес ввел ссылки на ресурс, который возвращает «text/javascript» как его тип MIME вместо какого-то изображения, и затем выполняется javascript.

Возможно ли это? Есть ли другая угроза безопасности, которую я должен рассмотреть?

+2

Я также рекомендую ha.ckers.org шпаргалку: ha.ckers.org/xss.html –

ответ

4

Еще одна вещь, о которой стоит беспокоиться, это то, что вы можете легко встроить PHP-код внутри изображения и загружать его большую часть времени. Единственное, что может понадобиться атаке, это найти способ включения изображения. (Только код PHP будет выполнен, остальное будет просто эхом). Проверка типа MIME не поможет вам в этом, потому что злоумышленник может легко загрузить изображение с правильными первыми байтами, за которым следует произвольный PHP-код. (То же самое верно для HTML и Javascript-кода).

+0

Я не выпускающие пользователей загрузить изображения. Пользователям разрешается только ссылаться на изображения на других сайтах по причинам, таким как вы упомянули. –

+0

Не мог бы фильтр простого имени файла предотвратить это? – AaronSieb

+0

@AaronSieb, нет, потому что вы могли бы, например, внедрить PHP-код в поддон GIF и загрузить совершенно корректное изображение GIF с правильным типом файла и типом mime. Проблема в том, что пока я могу манипулировать веб-сайтом, чтобы включить («my_uploaded_gif.gif»), у вас проблемы. Кроме того, часы% 00 вещь. –

1

В этом случае посмотрите на контекст вокруг него: есть ли у пользователей только URL? В этом случае хорошо проверить правильность семантики URL и MIME-типа. Если пользователь также получает какие-либо теги ввода, вам нужно убедиться, что они не манипулируют, чтобы делать что-либо другое, кроме отображаемых изображений.

2

Если конечный объект находится в защищенной паролем области, и ваше приложение содержит URL-адреса, которые инициируют действия на основе запросов GET, вы можете сделать запрос от имени пользователя.

Примеры:

  • SRC = "http://yoursite.com/deleteuser.xxx?userid=1234"
  • SRC = "http://yoursite.com/user/delete/1234 «
  • SRC =» http://yoursite.com/dosomethingdangerous»
+0

Я действительно был бы уязвим для этого? Мое Regex разрешает только http/https в начале URL-адреса, поэтому Javascript (или любая его кодировка) не сможет пройти, или я ошибаюсь? –

+0

Упс, забыли про «https?: //». Я отредактирую свой ответ. –

+0

От REST мы никогда ничего не пишем с GET ... – inf3rno

Смежные вопросы