Как предотвратить подделку межсайтовых запросов с помощью URL-адреса изображения? - PullRequest
3 голосов
/ 31 января 2010

С ha.ckers.org / xss.html :

IMG Embedded команды - это работает когда веб-страница, где это впрыскивается (как веб-доска) позади защита паролем и этот пароль защита работает с другими командами в том же домене. Это можно использовать чтобы удалить пользователей, добавьте пользователей (если пользователь, который посещает страницу, является администратор), отправьте учетные данные в другом месте и т. д. .... Это один из менее используемый, но более полезный XSS векторы:

<IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode">

или

Перенаправление 302 /a.jpg http://victimsite.com/admin.asp&deleteuser

Я разрешаю пользователям публиковать изображения на форуме. Как это можно защитить?

Я использую Java Struts, но любые общие ответы приветствуются.

Ответы [ 5 ]

5 голосов
/ 31 января 2010

Если вы следуете правилам HTTP-спецификации , такой вид атаки не принесет вреда. В разделе 9.1.1 Безопасные методы написано:

[…] Методы GET и HEAD НЕ ДОЛЖНЫ иметь значение действия, кроме извлечения. Эти методы следует считать «безопасными». Это позволяет пользовательским агентам представлять другие методы, такие как POST, PUT и DELETE, особым образом, чтобы пользователь знал о том, что запрашивается небезопасное действие.

Естественно, невозможно гарантировать, что сервер не генерирует побочные эффекты в результате выполнения запроса GET; на самом деле, некоторые динамические ресурсы считают, что это особенность. Важным отличием здесь является то, что пользователь не запрашивал побочные эффекты, поэтому не может нести за них ответственность.

Таким образом, все запросы, которые изменяют данные на стороне сервера, должны быть разрешены только через POST. И даже там вы должны разрешать только те запросы, которые ваша система аутентифицировала, генерируя токены, которые действительны только для определенной формы / действия.

3 голосов
/ 31 января 2010

Эта атака представляет собой просто запрос HTTP GET, направленный на любой URL. Вы не можете надежно заблокировать его, предотвращая определенные <img> теги.

Вместо этого вам нужно убедиться, что на вашем сайте нет целей (URL-адреса, которые отвечают на GET запросы и что-то менять)

Если нет «сочных» URL-адресов, которые отвечают на HTTP GET (не POST) и изменяют данные, злоумышленнику будет нечего атаковать. (<img> теги не могут использоваться для создания HTTP POST)

2 голосов
/ 31 января 2010

Путем введения тега <img> кто-то может обойти защиту XSRF на основе реферера для запроса GET. Причина в том, что реферер для запроса GET, выданного <img>, имеет тот же реферер, что и сам хост. Таким образом, это обойдёт проверку кода, чтобы увидеть, различаются ли реферер и хост.

Вы не должны позволять людям размещать html на вашей странице. В этом случае вы должны позволить пользователям загружать их, а затем размещать изображения локально. Если вы действительно хотите, чтобы люди размещали теги IMG на вашем сайте, убедитесь, что URL-адрес не указывает на ваш сервер, потому что это то, что сделает атака! Также не используйте защиту XSRF на основе реферера, используйте токен. Внедрение тега <img> не может обойти защиту xsrf на основе токенов.

2 голосов
/ 31 января 2010

Межсайтовый скриптинг - одна из причин, по которой вы не должны позволять пользователям форума публиковать изображения, ссылаясь на изображения вне вашего сайта. Публикация изображений должна обеспечиваться, позволяя пользователям загружать файл изображений на ваш сайт и используя внутренний относительный URI.

0 голосов
/ 01 февраля 2010

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

Если вы разрешаете людям публиковать изображения, но на вашем сайте нет уязвимостей XSRF, ваш сайт не находится в опасности; другие сайты с XSRF уязвимостями, так как ваши пользователи будут по незнанию отправлять запросы на другой сайт через встроенное изображение при посещении вашего сайта. Вредоносный тег <img> будет выглядеть примерно так:

<img src="http://my-bank-website.com/withdraw_money.php?amount=100000&account=mandy-the-hacker" />

Обратите внимание, что это не реальное изображение, но браузер этого не узнает, поэтому он в любом случае выполнит запрос, перечислив $ 100 000 на mandy-the-hacker счет, при условии пользователь в настоящее время вошел в систему my-bank-website.com . Вот как работают уязвимости XSRF.

Единственный способ предотвратить это - заставить пользователей загружать изображений вместо предоставления URL-адресов для них. Однако злонамеренный пользователь все еще может просто предоставить ссылку на уязвимость XSRF, поэтому удаление возможности предоставления URL-адресов на самом деле ничего не поможет; вы на самом деле не наносите вред другому сайту, разрешая теги <img>, они наносят себе вред, не используя пользовательских токенов в формах .

...