Нужен ли токен CSRF для jQuery .ajax ()? - PullRequest
26 голосов
/ 01 февраля 2012

Итак, у меня есть базовый метод .ajax () POST для PHP-файла.

Какие меры безопасности мне нужны?

В нескольких постах упоминалось использование скрытого MD5поле ввода, которое вы отправляете через AJAX и проверяете в файле PHP.Это достаточно хороший метод?

Ответы [ 4 ]

35 голосов
/ 26 апреля 2012

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

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

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

В самом простом:

  • При входе в систему создайтедлинный случайный строковый токен и сохраните его для пользователя.
  • Добавьте параметр в запрос $.ajax(), который включает токен.
  • По запросу убедитесь, что токен совпадает с тем, который вы сохранили.для пользователя.
  • Если токен не совпадает, у вас есть хакер CSRF.

Хакер не может получить доступ к вашей БД и фактически не может прочитать страницу, которую выотправилпользователь (если он не получает атаку XSS, но это другая проблема), поэтому не может подделать токен.

Все, что имеет значение с токеном, это то, что вы можете предсказать (и проверить) это и что хакер не может .

По этой причине проще всего сгенерировать что-то длинное и случайное и сохранить его в БД, но вместо этого вы можете создать что-то зашифрованное.Я бы не назвал MD5 только именем пользователя - если злоумышленники CSRF выяснят, как генерировать ваши токены, вы будете взломаны.

Другой способ - сохранить токен в cookie (а не в вашей базе данных).так как злоумышленники не могут прочитать или изменить ваши куки, просто заставьте их повторно отправить.Тогда вы токен в токене совпадений данных HTTP POST в cookie.

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

2 голосов
/ 01 февраля 2012

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

Я рекомендую прочитать Шпаргалку по профилактике CSRF .Использование секретного токена для каждого пользователя является наиболее распространенной формой защиты.

0 голосов
/ 24 декабря 2018

Вот простая демонстрация, которую вы можете попробовать с django:

На HTML-странице

{%block content%}
<form id="userForm">
{%csrf_token%}
  <input type="text" id="username" placeholder="User Name">
  <input type="password" id="password" placeholder="Password">
</form>
{%endblock%}

Код Java-Script

%(document).on('submit','#userForm',function(e){
   e.preventDefault();

 $.ajax({

    type = 'POST',

    url:'path/to/url',

    data:{
     username:$('#username').val(),
     password:$('#password').val(),
     csrfmiddlewaretoken:$('input[name=csrfmiddlewaretoken').val()
    },

   success:function(data){
       alert('Successfull');
   }
  });

});
0 голосов
/ 19 января 2018

Токен не требуется, но вы все равно должны защищать все функции, которые изменяют состояние, от CSRF.

Один из простых способов сделать это - добавить заголовок, отправленный с запросом AJAX. Случайный токен не требуется.

Это работает, потому что:

  • На формы HTML не могут быть добавлены пользовательские заголовки злоумышленником.
  • Пользовательские заголовки не могут передаваться между доменами без включенного CORS.

Конечно, код на стороне сервера должен гарантировать наличие заголовка перед выполнением его действия.

Дополнительная информация: Какой смысл в заголовке X-Requested-With?

...