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

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

Я прочитал документы в 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) Какие-нибудь ценные ссылки для дальнейшего изучения таких опасностей?

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

Ответы

Ответ 1

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

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

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

Ответ 2

Атака CSRF

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

Небезопасный пример

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

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

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

<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.)