В каком случае CSRF-exempt может быть опасен?

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

Я прочитал документы в django-docs ( https://docs.djangoproject.com/en/1.3/ref/contrib/csrf/ ) и немного информации на этой странице: http://cwe.mitre.org/top25/#CWE-352

Насколько я понял, django доставляет пользователю токен (какой-то пин-код). И чтобы убедиться, что это действительно он, он должен вернуть его в следующий раз, когда сделает запрос. И некоторые ребята из Google выяснили, что это возможно даже с ajax-запросами, поэтому с версии 1.2.6 у нас также действует новая политика их защиты. А CSRF — это когда кто-то дает мне что-то (плохой, опасный код, поврежденные файлы или что-то в этом роде), притворяясь кем-то другим.

Итак, если у меня есть такой код:

@csrf_exempt    
def grab(request):
    """
    view to download an item
    POST because it stores that a user has downloaded this item
    """
    item_id = request.POST.get('item', None)
    if not loop: return HttpResponseBadRequest('no item id provided')
    item = Item.objects.get(pk=int(item_id))

это должно быть сохранено, так как я не даю доступ к базе данных или какой-либо части моего приложения, прежде чем пытаться преобразовать данное значение в целое число. И если я неправильно запишу, что кто-то скачивает файл, то не будет слишком много вреда (в данном случае его почти нет). Предполагая, что я буду писать счета, полагаясь на это представление, освобождение от CSRF было бы очень плохой идеей (правильно?).

Я также не понимаю, почему кто-то не может украсть CSRF-токен у пользователя и использовать его, чтобы обмануть меня (или пользователя). Итак, у меня есть несколько вопросов по этой теме:

1) верны ли мои предположения сверху?

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

3) является ли CSRF примером атаки «человек посередине», это просто связано с ней или это что-то совершенно другое?

4) Любые ценные ссылки для дальнейшего чтения о таких опасностях?

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


person marue    schedule 31.03.2012    source источник


Ответы (2)


CSRF-атаки заставляют браузер жертвы отправлять поддельные запросы. Для этого достаточно простого <img> или автоматически отправленного <form> как для метода GET, так и для метода POST. И поскольку запросы отправляются браузером, он отправляет любые учетные данные для аутентификации и, таким образом, делает запросы аутентичными и законными с точки зрения сервера, поскольку они в основном не отличаются от запросов, инициированных действиями пользователя.

И именно для этого используется токен CSRF: установить разницу между запросами, инициированными пользователем, и теми, которые были подделаны сторонним сайтом. Для этой цели токен CSRF действует как секрет, известный только серверу и пользователю. Сервер помещает секрет в документ в ответ и ожидает, что он будет отправлен обратно в следующем запросе.

И поскольку секрет встроен в документ ответа, который назначен для этого конкретного пользователя, злоумышленнику необходимо будет подслушать этот конкретный ответ или получить доступ к документу каким-либо другим способом. Определенно существуют атаки, использующие токен CSRF (например, подслушивание, MITM, XSS и т. д.). Но если вы защищены от этих атак, злоумышленник не сможет подделать подлинный запрос.

person Gumbo    schedule 31.03.2012
comment
В конце туннеля появляется тусклый свет... Итак, если бы я хотел отправить злые вещи на сервер, мне сначала пришлось бы отправить некоторые данные в браузер некоторых пользователей. В этих данных я прячу какую-то форму автоматической публикации, которая отправляет на сервер для атаки. Я предполагаю, что пользователь вошел на этот сервер, потому что у него там есть учетная запись. И если сервер не будет проверять какой-то токен, ему просто придется поверить, что запрос был законным. По крайней мере, теперь у меня есть представление, как это работает и где провести черту между MIM и XSS. Спасибо за это. - person marue; 31.03.2012
comment
@marue CSRF не предназначен для отправки вредоносных данных на сервер. В первую очередь речь идет о олицетворении, поскольку атакующий сайт может отправлять законные и аутентичные запросы от имени жертвы. Подслушивание, MITM и XSS — это только средства для получения смягчающего токена CSRF (хотя, поскольку большинство схем управления аутентификацией используют сеансы на основе файлов cookie, вместо этого вы могли бы также получить идентификатор сеанса). - person Gumbo; 01.04.2012
comment
Значит, CSRF — это все и только для того, чтобы притворяться кем-то, кем вы не являетесь? Где только не значит не важно, а все остальное — это другой вектор атаки. - person marue; 01.04.2012
comment
Гамбо, так опасен ли код Маруэ? Мы хотели бы получить четкий ответ, что вы имеете в виду. Но если вы защищены от этих атак, злоумышленник не сможет подделать подлинный запрос. Спасибо - person Lucas Ou-Yang; 03.08.2013
comment
@ LucasOu-Yang Для защиты от CSRF требуется что-то, что нельзя подделать, например, непредсказуемый параметр (например, токен CSRF). Теперь, если злоумышленник сможет получить этот параметр путем прослушивания, MITM или XSS, он сможет подделать аутентичные запросы, содержащие этот непредсказуемый параметр. Теперь, если вы защищены от этих атак, злоумышленник не сможет подделать аутентичный запрос, поскольку он не сможет предсказать токен CSRF. - person Gumbo; 03.08.2013

CSRF-атака

Я обманом заставляю вас просмотреть веб-страницу, на которой я вставил некоторый код (запрос, обычно через img или form) на другой сайт (где у вас, возможно, есть какие-то права).

Безобидный пример

<img src="http://www.yoursite.net/changelanguage?lang=fr">

Я жестоко изменил язык вашего сеанса на французский. О нет! Вы можете безопасно удалить защиту csrf и сохранить попадание в базу данных.

Опасные примеры

<img src="http://www.yourbank.net/sendmoney?amt=9999&account=123>

Если вы вошли в систему yourbank.net (и у нее нет csrf или какой-либо другой защиты), ваша учетная запись уже должна чувствовать себя легче. (Мне 123 года.)

<img src="http://www.yoursite.net/admin/users/123/edit?admin=1">

Если вы вошли в свой сайт в качестве администратора, то мы оба. (Мне 123 года.)

person laffuste    schedule 07.08.2015