- редактировать: обратите внимание, я ошибаюсь из-за того, что SSL не обрабатывает атаки воспроизведения, как показано ниже. Реализация токенового подхода все еще хороша.
Подумайте о «воспроизведении» HTTPS-запроса, просто вернувшись в браузер и снова нажав кнопку.
То есть вам не нужно ничего декодировать, чтобы повторно отправить запрос SSL. Любой узел на пути может это сделать (они просто не видят трафик).
Так что, если я получу вашу транзакцию SSL, которая отправит мне 100 долларов, я смогу перехватить ее и отправить повторно, чтобы я продолжал получать деньги.
Очевидное решение этого (ну, типичное решение) состоит в том, чтобы сгенерировать токен на странице HTML, а затем сохранить то же значение в сеансе. Когда поступает запрос, вы проверяете это значение, проверяете, является ли оно текущим значением, и, если оно есть, обрабатываете его , а затем изменяете текущее значение .
Если это не текущее значение (т.е. это старое значение после того, как вы обработали «оригинальный» запрос), то вы знаете, что страница была повторно отправлена.
Это общепринятый подход для предотвращения повторного предоставления данных кредитной карты и т. Д., Но он также имеет преимущество в безопасности, заключающееся в том, что он заставляет уникальный запрос соответствовать каждому ответу. Злоумышленник в цепочке, который не может расшифровать SSL, не может пройти это.