Как защитить веб сервис (API)

Question

[KLUBS]

Добрый день.

Есть веб сервис на php-apache (самописный, чуть-чуть похож на этот). Сервис для работы с базой MySql. Сервис нужен, потому что на хостинге часто возникают проблемы с доступностью базы удаленно (не localhost). Нужно прописывать IP и прочие неудобности. Работать с сервисом будет программа на C#.

Собственно вопрос: Как защитить веб сервис от чужих Evil

1. Адрес сервиса никто не узнает, как защитить его от публикования, и индексирования?
2. http://developers.vgorode.ru/wiki/Защищенное_взаимодействие_приложения_с_API — тут написано про подпись md5, а где можно почитать как и от чего она защищает и какую проверку делать на сервере?
3. Чем (каким алгоритмом) можно шифровать, так чтобы можно было реализовать на php и .net (ну или скачать готовые, бесплатные). Клиент у сервиса будет один — эта программа, поэтому ключи можно вшить прямо в код.

Answer 1

[mark_ablov]

что шифровать?
шлёте ключ, php проверяет его, если он неправильные, ничего не отсылает, если правильный — высылает данные.

Comments

[KLUBS]

шифровать данные post запроса. каким алгоритмом шифровать? шифровать, чтобы любители не перехватили запросы и не получили данные. Да и чтобы данные отправляемые сервисом, тоже нельзя была просто так получить Они чуть-чуть коммерчески ценные.

[burdakovd]

SSL есть? Тогда можно своё шифрование не делать.

[mark_ablov]

а, защита от сниффинга.
тогда советую AES-128, например. Реализация есть и для C# и для PHP.

[KLUBS]

SSL нет. а про подписи заросов что-нибудь посоветуете?

[mark_ablov]

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

[burdakovd]

Насчёт аутентификации — по Вашей ссылке всё описано.

md5 гарантирует, что запрос отправлен тем, кто знает api_secret, без него контрольную сумму не составить

Что должен делать сервер:
* получить запрос
* вычислить sign, сравнить его с переданным, если не совпадает вернуть «Incorrect signature.». Это гарантирует, что запрос отправлен вышей программой, т.к. только она могла создать правильный sign.
* проверить, что переданный timestamp отличается от текущего времени на сервере не более чем на 100 секунд, если это не так — то вернуть «Invalid timestamp.». Это защищает от того, что злоумышленник перехватит запрос подержит его у себя часок, и начнёт посылать его много раз подряд.
* Проверить, что за последние 200 (= 100 * 2) секунд не было запроса с таким же sign. Защита от повторов. Использованные sign необходимо хранить в служебной таблице в течение минимум 200 секунд. Нужно для защиты от дублирования злоумышленником запросов.

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

Защищать передаваемые данные можно любым шифрованием, но проще всего SSL.

[burdakovd]

Вот черт, ну туда написал.

@mark_ablov

Кажется мне, что AES не защитит от клонирования злоумышленником легитимных запросов. Там нет ни рандомизированной установки соединения (как в SSL), ни timestamp-ов с проверкой на повторы, как описано по ссылке топикстартера.

[mark_ablov]

да, не защитит, только какой смысл злоумышленнику в зашифрованной инфе от сервера?
вы описали простейшую токенную систему, но нужна ли она в данном случае, когда идёт шифровка всего траффика?

[burdakovd]

А если запросы не только GET? Если запрос вида «перевести 100$ от пользователя A к пользователю B»? Злоумышленник сохранит это запрос, и спустя час повторит.

[mark_ablov]

ээ, в REST'е идеология такого не позволяет :)

[burdakovd]

Или приложение спрашивает: «Какой у меня сейчас баланс?». Злоумышленник перехватывает ответ сервера (не расшифровывая его), и возвращает этот ответ на все последующие запросы приложения. Таким образом приложение будет думать что всё ок, но это не так. Хотя описанная схема от такого не защищает, для этого нужно привязывать ответ к конкретному запросы, например используя случайный id запроса и указывая его в ответе.

Но это всё велосипеды, SSL бы от всего описанного защитил бы, нужен аналог, но который можно реализовать на уровне PHP.

[burdakovd]

@mark_ablov

Я в REST не очень разбираюсь. Как оно может такого не позволять? Как отличить легитимный повторный запрос от клона, если не использовать случайный id?

[mark_ablov]

смысл REST'a в том, что никакой интерактивности, а только получение данных.

[KLUBS]

У меня не совсем REST. Изменять данные я буду. Почему сервис — потому что база удаленно недоступна, а доступ нужен. Или можно как-то по другому? придумал пока что только сервис, напишу методы а программа зная адрес, пароли явки будет работать с ним. Если в программе и в сервисе зашить ключи для шифрования, это не решит проблему передачи данных?

[mark_ablov]

тогда действительно нужны токены.
схема примерно такая:
1. Отсылаем запрос (можно и плейн-текстом) на получение токена.
2. Сервер генерирует токен, который шифрует ключем знакомым клиенту и отправляет клиенту.
3. Следующий запрос (который содержит нужную команду) отсылаем шифрованную с ключем==токену.
4. Сервер отдаёт ответ опять же шифрованный токеном.

Токены одноразовые.

[KLUBS]

1. выдали токен, его сервер запомнил?
2. почему не подходит или плоха система подписи запроса (api_secret) и шифрование ключом, известным и серверу и клиенту?

[mark_ablov]

1. Само собой :)
2. api_secret нисколько не увеличивает безопасность и эффективность простого шифрования секретным ключем.

[KLUBS]

api_secret — я имел ввиду, ключ приложения (как это делают в настоящих api)
1. Для этого нужно вводить сессию, или писать в базу по api_secret — токен? Где можно про эту систему
почитать подробнее? А шифровать — AES-128?

[mark_ablov]

> api_secret — я имел ввиду, ключ приложения (как это делают в настоящих api)
вместо api_secret у вас ключ шифрования.
> Для этого нужно вводить сессию, или писать в базу по api_secret — токен?
как угодно
> А шифровать — AES-128?
один из вариантов.

имхо, все ответы даны, перечитайте внимательно эту беседу, и всё будет ок :)

[burdakovd]

@mark_ablov

Как гарантировать одноразовость токенов? Сервер может её гарантировать (условно) потому что токен большой и генерируется случайно.

А клиент? Он должен хранить все использованные ранее токены и проверять чтоб не было повтора? Это нереально, тем более если клиент запускается не с одного ПК. Если он не хранит использованные ранее токены, то возможен такой поворот событий:

1. Отсылаем запрос на получение токена.
2. Сервер генерирует токен, который шифрует ключем знакомым клиенту и отправляет клиенту. (злоумышленник сохраняет шифрованный ответ)
3. клиент посылает запрос, шифруя токеном
4. сервер посылает ответ, шифруя токеном (злоумышленник копирует шифрованный ответ себе)

5. клиент хочет послать ещё запрос, посылает запрос на получение токена
6. злоумышленник отвечает ему сохранённым в пункте 2 ответом
7. клиент посылает запрос (злоумышленник может сравнить этот запрос с запросом из пункта 3, и сравнивая их на равенство может получить какую-то дополнительную информацию)
8. злоумышленник отвечает ему сохранённым в пункте 4 ответом

Токен использован дважды, ответ сервера подменён, клиент ничего не заметил, злоумышленник торжествует.

[mark_ablov]

очень просто — токен содержит в себе timestamp.
заодно и уникальность добавляется.

[mark_ablov]

а как узнать что timestamp прошедший если рассинхрон с сервером?
тоже очень просто — при первом handshake сервер отправляет свой timestamp, который заведомо меньше либо равен таймстмпу из токена. А инфы злоумышленнику это не даёт никакой.

[KLUBS]

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

[mark_ablov]

это далеко не SSL, а пишется по 50 строк на каждой стороне.
> Почему простой подписи запроса и шифрования (ключ известен обоим) будет не достаточно?
токен это и есть подпись запроса.

[burdakovd]

@KLUBS
Просто подписи (которая кстати если есть шифрование не обязательна) и шифрования недостаточно из-за replay attack. Чтобы решить эту проблему нужно использовать что-то генерируемое случайно с обоих сторон, или использовать timestamp (но возня с timestamp мне не кажется надёжной).

Велосипеды придумывать опасно, так что лучше найти «канонические» решения этой проблемы и найти их в реализованном виде на нужных языках или аккуратно закодить самому.

[burdakovd]

Сказал, что придумывать опасно, но не могу удержаться от ещё одного варианта:

1. Клиент генерирует случайный большой ключ X. Отсылает его серверу (шифруя глобальным общим ключом)
2. Сервер генерирует случайный большой ключ Y. Отправляет его клиенту (шифруя глобальным общим ключом)
3. Клиент посылает запрос, шифруя его ключом concat(X, Y)
4. Сервер посылает ответ, шифруя его ключом concat(X, Y)

Тут replay-attack не работает, потому что каждая сторона сама генерирует часть ключа сессии, и поэтому concat(X, Y) каждый аз будет разным.
Если враг подменит X или Y, то общий ключ не будет выработан.

Answer 2

[burdakovd]

@mark_ablov

Кажется мне, что AES не защитит от клонирования злоумышленником легитимных запросов. Там нет ни рандомизированной установки соединения (как в SSL), ни timestamp-ов с проверкой на повторы, как описано по ссылке топикстартера.

Answer 3

[Tagire]

OAUTH?

Answer 4

[lavel]

Самоподписанный СА-сертификат и выданные им сертификаты проверки подлинности клиента, работает на уровне Apache, клиент без сертификата получит ошибку 401 и ничего не увидит. Клиентских сертификатов можно сделать сколько угодно, их так же можно отзывать через revocation list. Так же в Common Name сертификата можно указывать любые данные, идентифицирующие пользователя в системе, т.е. по сертификату можно выполнить и аутентификацию и авторизацию.

Comments

[lavel]

да, и вот довольно подробная инструкция по настройке