Защищать от повторных атак при использовании сигнатур запросов в безопасном взаимодействии API? - PullRequest
2 голосов
/ 29 марта 2012

Я читал о ценных бумагах API и пытаюсь найти лучший способ создать безопасный API. Я знаю, что OAuth и такие существуют, но я также пытаюсь обучиться этому процессу, а не полагаться на библиотеки.

В основном у меня есть веб-служба и пользователи этой веб-службыможете зарегистрироваться на API.Им будет предоставлен идентификатор профиля и секретный ключ, которые они должны использовать для создания запроса API из другой веб-системы.

Запрос API создается аналогично тому, как это делают банки, все входные данные, отправляемые в API, имеютчтобы отсортировать, вычислить хеш, а затем отправить хеш на сервер, например:

// Profile data
$apiProfile='api123';
$apiSecret='this-is-a-good-day-to-be-a-secret-key';

// Input
$input=array();
$input['name']='Thomas Moore';
$input['profession']='Baker';

// To ensure that the order of variables checked and received is the same on both ends:
ksort($input);

// Using serialize() for simplifying things
// http_build_query() is another option, or just placing values in order
$input['hash']=sha1(serialize($input).$apiSecret); 

// Making a request to URL:
// Using file_get_contents() as an example, would use cURL otherwise
$result=file_get_contents('http://www.example.com/api.php?'.http_build_query($input));

// SERVER CALCULATES COMPARISON HASH BASED ON KNOWN SECRET KEY AND INPUT DATA

Это действительно хорошо и работает.Но! Моя проблема - потенциальная переигровка.Если кто-то перехватит этот URL-адрес запроса, он может снова отправить его на сервер, даже если он не сможет изменить сами данные.

Теперь я прочитал кое-что об этом, что вы также должны либо проверить время, либо добавитьодноразовый токен для запроса, но я не уверен, как именно это сделать?Достаточно ли безопасна отправка метки времени с запросом?(Приемный сервер должен был убедиться, что запрос возник в течение нескольких секунд в течение времени, когда был выполнен запрос, если часы немного синхронизированы).

Я также мог бы добавить проверки IP в смесь, но они могут изменитьсяи может быть несколько подделан и доставляет больше хлопот пользователю.

Мне бы понравился этот тип системы с одноразовыми токенами, но я не уверен, как это сделать, не подвергая генерацию токенов точно такой жепроблема повторной атаки?(Последнее, что мне нужно, это разрешение выдавать безопасные токены для посредников).

Мнения и статьи были бы очень кстати, я не смог найти материал, который отвечал бы моим конкретным проблемам. Я хочу сказать, что мой API безопасен , и это не просто маркетинговый разговор.

Спасибо!

Ответы [ 2 ]

3 голосов
/ 29 марта 2012

Вам нужно только разрешить обмен токенами по защищенному каналу (https), и у вас должен быть уникальный хеш для каждого сообщения. Включите такие вещи, как метка времени и IP-адрес клиента. Если вы не используете https, вы уязвимы для атаки в стиле firesheep.

Кроме этого, вы делаете генерацию токена и правильно обмениваетесь.

2 голосов
/ 29 марта 2012

Отправка времени (и включение его в кеш) действительно возможна.

Другой вариант - двухфазный алгоритм, когда вы сначала запрашиваете токен сеанса или ключ сеанса, а затем используете его для сеанса, и его TTL хранится на сервере (это может быть время или количество разрешенных запросов). )

Что касается идеи сессионных ключей, взгляните на схемы типа http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Пример алгоритма одноразового токена:

1) клиент составляет запрос для одноразового токена, подписывает этот запрос секретным ключом и отправляет его на сервер.

2) сервер генерирует ключ, подписывает его тем же ключом и отправляет его клиенту (вместе с подписью)

3) клиент проверяет токен, используя секретный ключ

4) клиент формирует запрос, включая токен, и подписывает секретным ключом все тело запроса, а затем отправляет на сервер

5) сервер проверяет целостность всего тела и действительность токена, затем отправляет ответ (снова он может быть подписан секретным ключом для проверки целостности и авторства)

...