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

Question

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

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

Насколько я понял, Джанго поставляет маркер (своего рода пин-кода) к пользователь. И проверить, действительно ли это он, он должен вернуть его в следующий раз, когда он сделает запрос. И некоторые ребята из 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) Какие-либо ценные ссылки для дальнейшего изучения таких опасностей?

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

Answer 1

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

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

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

Answer 2

CSRF нападение

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

Innocuous пример

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