Вопрос действительно сводится к тому, чего вы хотите достичь. Если вы хотите сражаться с CSRF-атаками, секретный токен в дополнение к сеансовому ключу - это ваш путь. Тем не менее, изменение маркера в каждом запросе вызовет проблемы - не только будет отключена кнопка «назад», но так как одна веб-страница обычно содержит много асинхронных и параллельных загружаемых данных (изображения, css, javascript и т. Д.), Ваш подход не будет включать дополнительные данные для последующей загрузки, так как каждый дополнительный запрос изменит требуемый токен, тем самым убив сеанс.
Вы можете обойти это, вставив все ресурсы на страницу через BASE64 и другие трюки, но это серьезно помешает вашим возможностям и может столкнуться с проблемами совместимости с некоторыми браузерами.
Таким образом, ваш подход не добавит много безопасности, но, скорее всего, создаст целый ряд потенциальных проблем для ваших клиентов. Я придерживаюсь одного секретного токена за сеанс в URL-адресе для борьбы с CSRF и концентрируюсь на защите от других атак типа XSS и удобных для пользователя мер безопасности, таких как двухфакторная аутентификация с помощью смартфона или что-то подобное. В конце концов, пользователь теперь является вектором атаки №1.
Update (2012-06-14)
Маркер не будет бороться XSS-атаки, но она будет защищать от основных CSRF-атак (например, внедряя фиктивный вызов URL-адрес в изображении). У меня на самом деле была ситуация на работе сегодня, где мне нужно было получить запрос на получение от пользователя и worked up some code. Код может также использоваться для обеспечения статического, тайм-аута сеанса form - и link -tokens (правильно ваша проблема).
Идея состоит в том, чтобы иметь секретный сервер, который используется для создания хэша/AuthToken над данными для обеспечения безопасности. Если jug-код изгоев попытается изменить любую из данных данных, AuthToken не будет соответствовать. В моей конкретной проблеме у меня есть один сервер, который аутентифицирует пользователя и должен отправить свою информацию третьему лицу (имя пользователя, адрес электронной почты, имя и т. Д.). Этот GET-запрос может быть легко изменен любым пользователем после аутентификации, поэтому я должен аутентифицировать параметры GET-Request. Перезагружая AuthenticationToken-Process, третья сторона может сравнить полученный AuthTokens, таким образом, проверяя входящие данные. Без общей секретности (почти) невозможно подделать данные.
По вашей проблеме: наличие статического токена в GET и POST-запросах (или динамическом, как мой проект) защитит вас от простых CSRF-атак, например. ссылки на форумах, которые пользователь должен нажать, чтобы атаковать. Поскольку ссылка никогда не будет содержать правильный токен, ваша веб-страница будет безопасной. Однако, если злоумышленнику удается загрузить javascript на веб-страницу через XSS, вы будете ввернуты, и никакая техника в мире не поможет против него, так как javascript может сканировать все DOM-дерево страницы, чтобы найти захват любых токенов бы то ни было.
Таким образом, сводится к следующему:
- использования лексемы GET и POST-запросов на борьбу CSRF
- защитить свою страницу от XSS-инъекций
Какое это веб-приложение? Если это обычное веб-приложение, доступное в обычном веб-браузере, наличие токенов аутентификации для каждого запроса будет иметь влияние на удобство использования, поскольку история браузера (кнопка «Назад») и параллельный просмотр больше не будут работать. – Gumbo
Как клиент знает пароль? – biziclop
Gumbo: Доступно через обычный веб-браузер. Моя идея предотвратить проблемы с навигацией, о которых вы говорили, заключалась в том, чтобы сделать вызов/ответ так или иначе как часть одного запроса. Например. 1. запрос от клиента, 2. ответ с запросом и целевой URL с сервера, 3. клиент отправляет ответ на этот URL-адрес, 4. выполняется исходный запрос. Или любой другой такой метод. biziclop: Это пароль пользователя клиента, который он устанавливает при регистрации (регистрация должна быть подтверждена зарегистрированной почтовой линией) – Bachi