Как обезопасить POST запросы?

Каким образом можно обезопасить POST запросы на сервере?
Есть вариант с присвоением токена юзеру и проверкой его на стороне сервера, но не знаю на сколько данный вариант хороший.
  • Вопрос задан
  • 1381 просмотр
Пригласить эксперта
Ответы на вопрос 5
@FanatPHP
Никак.

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

Единственные условно действенные методы "защиты" - это, в зависимости от задачи - авторизация и каптча.

CSRF - это немного из другой оперы. Защищает от того, чтобы авторизованный на твоем сайте пользователь не совершил какое-либо действие, нажав кнопку на стороннем сайте.
Ответ написан
Alex_Wells
@Alex_Wells
PHP/TS/Kotlin developer
Если у вас кукисы - CRSF. Если у вас что либо другое - CORS (точнее, его отсутствие или правильная настройка).
Ответ написан
Вы отдали свою страницу. Дальше что-то происходит в «чёрном ящике» пользователя. И вот вы получаете POST-запрос.

Нет никакого контроля над тем, что внутри Ч.Я. То ли просто браузер и клик пользователя по кнопке. То ли вашу страницу с формой разобрали, изменили, подменили, передали боту, и тот отправляет свой каверзный POST-запрос, прикидываясь браузером со страницей.

С точки зрения вашего сервера, поступивший POST-запрос приходит снаружи неизвестно, от кого.

Вернее, известен IP адрес. Можно проверить, отдавали ли только что этому же IP страницу с формой.

Можно со страницей отдавать уникальный параметр, который ожидать вместе с POST-данными, и который использовать можно лишь 1 раз.

Можно ещё как-то усложнять «защиту». Например, заставлять браузер пользователя произвести какие-то вычисления обфусцированным нечитаемым длинным JavaScript'ом и вернуть их результат с POST-запросом, а на сервере это проверять.

Но всё, абсолютно всё, что происходит в Лас-Вегасе у пользователя, поддаётся подделке.

А что, если...
  1. работать только по HTTP/2 и принимать POST-запрос только, если он пришёл по ранее открытому соединению?
  2. вместо POST использовать WebSocket'ы.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
С помощью подписи запроса.
1. HASH - подпись с применением функций хеширования и формул конкатенации данных запроса.
2. RANDOM - случайная строка символов или число для создания уникального запроса
3. TIMESTAMP - контроль давности запроса на стороне сервера.

Подробно: здесь

Основные критерии:
1. Отсечение ботов по поведенческому фильтру и капча при критичных запросах к серверу (частые POST/GET-запросы, авторизация, восстановление доступа и т.п.).
2. Отображение важных информационных данных (таблица, график, исходник, ссылки) для гостя - только после решения капчи (для залогиненного пользователя - это отключаем).
Ответ написан
Jukk
@Jukk
Хорошая валидация на сервере которая не допускает запись в БД если данные пришли "левые".
От ботов — капча

здесь написано про защиту с помощью больших чисел: https://habr.com/ru/post/137961/
но все равно автор рекомендует капчу
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы