Вы не должны полагаться на метку времени, отправленную устройством, поскольку ее можно легко подделать.
Если (и только если) вы можете идентифицировать запросы, исходящие от того же пользователя или устройства, тогда вы можете использовать временную метку на сервере и использовать ту же стратегию смягчения последствий, но на этот раз у вас есть единая мера времени. (Вам необходимо сохранить отметку времени «последнего» доступа для каждого пользователя или устройства.)
Способ идентификации пользователя или устройства может заключаться в создании ha sh (например, время первого запуска + IP-адрес + ...) при первом использовании и отправляйте его вместе с запросом REST API все последующие разы. Если пользователю требуется войти в систему, вы можете сохранить это значение вместе с информацией о пользователе; в противном случае вы можете «идентифицировать» устройство аналогичным образом.
РЕДАКТИРОВАТЬ: это изменение сделано в свете вашего комментария, в котором добавлена информация, которая не была ясна раньше хотите проверить, не должно ли время отправления запроса и время получения на сервере иметь большой интервал (скажем, более 1 минуты). *
Перефразируя, вы хотите аннулировать запросы на основе их генерации время (не старше 60 секунд). Если теперь я правильно интерпретирую это, идея состоит в том, что очень вероятно, что на запросы клиента потребуется гораздо меньше 60 секунд для ответа, поэтому предполагается, что слишком старое сообщение, скорее всего, уже было правильно обработано - это может быть ответная атака.
К сожалению, ваше решение только (предсказуемо) уменьшит пространство сообщений, которое злоумышленник может использовать для выполнения ответных атак, что, следовательно, далеко не предотвращено , даже с синхронизированными отметками времени. Кроме того, если сообщение можно подделать, т.е. злоумышленник может обновить старые сообщения с новыми отметками времени, смягчение будет полностью неэффективным .
В любом случае, если вашей целью было не предотвращение ответных атак, а просто отбрасывание просроченных сообщений, тогда вы можете достичь своей цели, предложив два REST API:
- один для «подготовки» ( вам даже не нужно собирать ответ)
- другой для фактического «запроса»
и оба с метками времени клиента и с тем же идентификатор запроса .
Таким образом, вы увидите на стороне сервера две пары timestamp-requestID: (t,ID) и (t',ID). Это позволит вам просто изменить временные метки, t' - t, которые независимы от установленного временного сдвига или часового пояса. Вы также можете настроить время для запросов на стороне сервера, чтобы отклонить «запрос», поступивший слишком поздно, в связи с их соответствующей «подготовкой».
Дополнительно для повышения безопасности вы можете позволить клиентскому приложению подписывать сообщения (включая временные метки и идентификатор запроса), чтобы гарантировать целостность - сообщения нельзя подделать, не заметив этого, так что вы можете полагаться на временные метки, отправленные API. Один из способов - использовать криптографию publi c -key, но будьте осторожны при распространении ключей publi c. (Таким образом вы ограничиваете возможность атакующего отвечать только на самые последние запросы).