2013-05-01 6 views
4

Прямо сейчас у нас есть токен 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); 
+0

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

+0

не уверен ... но я думаю, что файлы cookie уязвимы для атаки CSRF – 2013-05-02 11:34:17

+0

@ user1609085 Идея маркера CSRF заключается в том, что злоумышленник пытается отправить «скрытый» запрос, олицетворяющий другого пользователя A. Злоумышленник использует какой-то другой сайт, на котором он может вводить какой-то злонамеренный код javascript, важно здесь, что с этого сайта он не может отправить токен в файл cookie или в специальный заголовок (браузеры не позволяют злоумышленнику сделать это), поэтому маркер обычно помещается туда. – le0diaz

ответ

5

Вы хотите, чтобы перевернуть вокруг потока, который вы указаны выше. После каждого сравнения вы должны создать новый токен.

Один большой недостаток лексем-за запрос, если пользователь нажимает кнопку в браузере:

  • посещение пользователя Page1 и магазины TokenA в сессии.
  • Пользователь щелкает ссылку на страницу2, отправив TokenA. Приложение проверяет TokenA в сеансе и дает пользователю TokenB.
  • Пользователь обращается к кнопке «Назад», чтобы вернуться к странице 1, информация о сеансе не обновляется.
  • Page1 до сих пор имеет только информацию для TokenA, пользователь нажимает на ссылку или отправляет форму на Страница3 направляющее TokenA, но сессия только знает о TokenB
  • App считает это CSRF нападение

Из-за этого, вам нужно внимательно следить за тем, как и когда токены обновляются.

+0

Мне нужен такой тип конфигурации в моем приложении plz, предлагайте мне для такого типа конфигурации, я могу достичь этого или нет. – user243405

+0

Привет, я знаю, что это старый пост, но сейчас я в той же ситуации. Не могли бы вы подтвердить мое понимание: 1) когда пользователь посещает страницу 1, String st = (String) request.getSession(). GetAttribute ("CSRF_TOKEN_FOR_SESSION_NAME"); вызывается и является нулевым. После этой строки rt = CSRFTokenManager.getTokenFromRequest (запрос); , который генерирует и устанавливает новое значение для атрибута сеанса. Когда проводится сравнение? – Aman

+0

Что произойдет, если пользователь обновит страницу? – Aman

-1

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

+0

Без какого-либо контекста я думаю, что ваше предложение действительно плохое. Поток, описанный Джей, на самом деле не совсем практичен. Запросы GET 99% времени не обновляет данные, поэтому, если это так, ваша система плохо разработана. Таким образом, вы в конечном итоге защищаете только POST | PUT | DELETE | HEAD ... и для тех, кто отправляется из формы, ситуация с обратной кнопкой не распространена в хорошо спроектированном приложении. обычно после отправки формы, которую вы перенаправляете, чтобы вы не могли повторно отправить форму при возвращении в историю браузера – le0diaz

Смежные вопросы