2012-03-29 4 views
2

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

В основном у меня есть веб-сервис, и в этом веб-сервисе пользователи могут зарегистрироваться для 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 защищен, не говоря о том, что он просто говорит по-английски.

Спасибо!

ответ

3

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

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

+0

Спасибо за вотум доверия. Я просто параноик-перфекционист, я полагаю. – kingmaple

+0

Я мог бы использовать фактический HMAC, чтобы избежать атак с расширением длины, хотя похоже, что вы не уязвимы, так как вы помещаете секрет последним, а не первым. http://en.wikipedia.org/wiki/Hmac http://en.wikipedia.org/wiki/Length_extension_attack – alberge

2

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

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

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

примера 1-временные маркера алгоритма:

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

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

3) клиент проверяет маркер с помощью ключа

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

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

+1

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

+0

см. Обновление для 2-фазного api с использованием одноразового токена. также вы можете полностью зашифровать сообщение, используя подход Diffie-Hellman или аналогичный подход к сеансу связи. – Guard

+0

Если вы завершите транзакцию в TLS, это приведет к тому же. –