Как правильно проверять, что к серверу за данными обращается именно мое приложение?

Question

[denbur]

Имеем:
- Клиент на JS
- Сервер, к примеру, на PHP, но не суть важно
- Обмен данными с помощью JSON

Клиент стучится на Сервер за данными: server.dev/data/getSomeData
Сервер что-то там творит и возвращает
{
data: "blaBlaBla"
}

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

Comments

[strib]

стучится именно мой клиент

Клиент в смысле программа или человек?

Answer 1

[Андрей]

Наиболее популярный способ аутентификации, стойкий к прослушиванию передаваемых данных - challenge-handshake :

1) сервер формирует случайное неповторяющееся число/строку достаточной длины "nonce" и направляет его клиенту перед каждым очередным запросом;

2) клиент выполняет SHA-1(key||nonce||key) и отправляет результат или его часть серверу вместе с запросом, где key - секретный ключ (стойкость системы будет зависеть от того, насколько "хорошо" Вы его спрячете в клиенте);

3) сервер, получив запрос, повторяет вычисление SHA-1(key||nonce||key) с экземпляром key, хранящимся у него на сервере, и если полученный результат совпадает с присланным клиентом - отвечает данными.

Есть множество модификаций:
а) Вы можете вместо nonce использовать строку текущего времени с определенными округлениями и уловками;
б) если параметры запроса достаточно уникальны, то Вы можете банально использовать их самих вместо (вернее сказать, в качестве - ) nonce.

В обоих этих случаях исчезает первый шаг из описанных выше - а это очень удобно.

Comments

[denbur]

Спасибо огромное! Именно этот алгоритм я и хотел найти!

[Леонид]

@OLS , а такой вопрос: как достаточно надёжно спрятать key в JS коде? Ведь ничего не стоит открыть исходник.

[denbur]

@camelos присоединяюсь. ведь если залезть в исходник, то можно увидеть не только key, но и как формируется nonce

Answer 2

[Руслан Лопатин]

Это называется аутентификация. Способов её реализации - тьма.

Answer 3

[Zerstoren]

Никак. Ключи, куки, авторизация и всё остальное только усложнит попытку посылать запросы, но это тоже можно будет обойти.

В добавок, первое правило серверного разработчика, никогда не доверяй данным пришедшим из вне. Особенно с клиента, который работает в паре с сервером.

Comments

[Пума Тайланд]

Ага и много вы авторизаций обошли?

[Zerstoren]

@opium Что значит обошел, я их проходил в автоматическом режиме. У человека стоит вопрос в том, что ему нужно знать, что к его серверу обращаются с его JS клиента.

Answer 4

[dmko]

куки?

Answer 5

[Aleksei Podgaev]

Я использую сессионный ключ.
При первичной авторизации клиента сервер генерирует для него уникальный ключ (хэш строку достаточной длинны), который потом клиент использует для доступа к данным - передаёт его серверу с каждым запросом. Можно передавать этот ключ куками, можно напрямую в GET/POST запросе в качестве параметра.
Этот способ относительно прост. Абсолютной защиты, как известно, не существует. Но в связке с другими средствами защиты как регистрацией IP адреса, временем жизни сессии и другими, этот способ даёт достаточно хороший уровень защиты от взлома.