Может ли человек, увидев js и post запросы с их url, сымитировать запрос на сервер для каких либо целей. Если да, то как это предотвратить?
К примеру, после успешной оплаты, на сервер отправляется post запрос с определенным заголовками, а человек просто имитирует такой же запрос без оплаты
Да, сымитировать запрос можно. Поэтому есть правило: "Нельзя доверять данным, которые приходят с клиента". Следовательно, данные с клиента нужно проверять на сервере. Критические данные и операции нужно подписывать или хэшировать, чтобы избежать подмены. Например, для защиты от Replay Attack используют одноразовые токены — при повторном запросе токен уже не сработает.
В целом, суть такова: вы генерируете каким-либо образом для каждой важной операции токен, который срабатывает только один раз. Например, мы запрашиваем что-либо у сервера, тот отправляет нам данные и одноразовый токен. Далее мы совершаем какую-либо операцию, отправляя на сервер данные и тот самый токен. Если злоумышленник решит повторно отправить тот же запрос, он не сработает, поскольку токен будет уже не рабочий.
Ну и особо важные операции всё же лучше проводить сразу на сервере. Например, пользователь хочет купить что-либо в игре. Нужно не проверять на клиенте, достаточно ли средств для покупки и дальше отправлять на сервер обновлённое количество средств и данные о совершённой покупке, а нужно отправлять запрос о желании совершить покупку, а уже вся "внутренняя" логика совершается там — подальше от рук пользователя.
Здесь в вопросе - 2 разных вопроса. Мне кажется так:
1) Как защититься от любого мусора который прилетает с клиента. Скорее всего никак.
Нужно реагировать только на HTTP запросы которые имеют смысл в контексте пользовательской
сессии. Тут - как-бы бизнес логика и FSM для сессии должен все решать. Хакеры с помощью
wget, curl, python могут генерировать фаззингом миллионы самых вариативных запросов
в поиске вашего слабого места в этой части защиты.
2) Как защититься от атаки man-in-the-middle.. Это если легальный пользователь
зашел в свой клиент банк, а некто, кто физически сидит на канале может перехватывать
IP пакеты. Изменять их. Удалять. Задерживать на какое-то время или делать повторы.
Здесь коробочное решение это https (TLS/SSL) протокол по идее помогает.
не удачный пример с платежными системами.
Данные об оплате поступают от мерчанта.
В 99% процентов случаев Ваш сайт просто отправляет посетителя на сайт платежной системы так как пройти сертификацию для работы с данными карт (Payment Card Industry Data Security Standard (PCI DSS) ) большой гиморой.
Для переадресации требуется сумма платежа, идентификатор участника платежной системы в чью пользу оплата, обычно к обязательным полям добавляют возможность добавить идентификатор оплаты со стороны продавца.
Названия полей и их количество немного отличаются от платежной системе к системе.
Есть вторая схема. Предварительная регистрация платежа (бакенд дергает апи и получает ид оплаты). Редиректит пользователя на оплату конкретного счета.
Факт успешной оплаты может проверяться по инициативе со стороны бека, так и через механизм обратных вызовов (хуков)
От пользователя сайт не берет информацию. Возврат по урлу успеха на сайт максимум можно использовать только для перепроверки, что поступлении денег было.
Даже в этом случае (пользователь ничего не передает) верить не желательно.
Стоит перепроверить контрольную сумму. Ограничить доступ к хукам по ip.
Типовой способ защиты: расчет контрольной суммы от
секретнаястрока+поле_данных1+поледанных2+....+полеN
Но способ не подходит для JS так как строка будет видна :(
