Прямо сейчас у нас есть токен csrf за сеанс. И добавив этот токен jsp, используя скрытое поле. Следующий фрагмент кода дает только одну за сессию:CSRF: Генерировать токен для каждого запроса
token = (String) session.getAttribute(CSRF_TOKEN_FOR_SESSION_NAME);
if (null==token) {
token = UUID.randomUUID().toString();
session.setAttribute(CSRF_TOKEN_FOR_SESSION_NAME, token);
}
и для каждого запроса,
//calls the above snippet and this time token will not be null
String st = CSRFTokenManager.getTokenForSession(request.getSession());
String rt = CSRFTokenManager.getTokenFromRequest(request);
здесь, usings приравнивает сравнить строки и возвращения истинным или ложным.
мой вопрос: что произойдет, если я попытаюсь сгенерировать токен для каждого запроса без получения маркера из сеанса. И, сравнивая, я получу от сеанса и запроса. это хорошая идея или что-то не хватает?
Вместо того, чтобы использовать вышеупомянутые отрывки, я пойду со следующими
//for every request generate a new and set in session
token = UUID.randomUUID().toString();
session.setAttribute(CSRF_TOKEN_FOR_SESSION_NAME, token);
//get the token from session and request and compare
String st = (String) request.getSession().getAttribute("CSRF_TOKEN_FOR_SESSION_NAME");
String rt = CSRFTokenManager.getTokenFromRequest(request);
Вы можете создать токен, а не хранить его в сеансе вообще. Добавьте его как скрытое поле в форму и как файл cookie. Когда вы получите запрос, сравните значения поля и файла cookie. –
не уверен ... но я думаю, что файлы cookie уязвимы для атаки CSRF – 2013-05-02 11:34:17
@ user1609085 Идея маркера CSRF заключается в том, что злоумышленник пытается отправить «скрытый» запрос, олицетворяющий другого пользователя A. Злоумышленник использует какой-то другой сайт, на котором он может вводить какой-то злонамеренный код javascript, важно здесь, что с этого сайта он не может отправить токен в файл cookie или в специальный заголовок (браузеры не позволяют злоумышленнику сделать это), поэтому маркер обычно помещается туда. – le0diaz