id: Гость   вход   регистрация
текущее время 08:26 20/04/2024
Автор темы: kojemiaka, тема открыта 27/07/2012 13:42 Печать
Категории: инфобезопасность, защита сети
https://www.pgpru.com/Форум/ТехническиеВопросы/ПроверкаЛегитимностиПользователейПриДоступеКСерверу
создать
просмотр
ссылки

Проверка легитимности пользователей при доступе к серверу


Есть сервер (сервер), к которому производится ajax jsonp запрос со странички html (клиент). Сервер предназначен для отправки данных в json-формате. Строка запроса невооруженным глазом не видна, но если посмотреть через сниффер тоже Файерфокса или Хрома становится видна и сама строка и механизм безопасности, который сейчас используется.


Суть его в следующем. На стороне сервера и клиента есть одинаковый закрытый ключ, на основе которого каждый день генерирутся открытый ключ, который вставляется в строку запроса отдельным параметром. Открытый ключ – это комбинация даты и закрытого ключа, он меняется каждый день. На сервере, при получении запроса идет проверка открытого ключа, присланного клиентом. Если присланный открытый ключ совпадает с открытым ключом сгенерированным сервером (все так же на основе даты и закрытого ключа), то запрос обрабатывается. Если ключи не совпадают, то сервер отсылает ошибку.


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


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


 
Комментарии
— unknown (27/07/2012 14:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Есть две стороны. Обе должны быть аутентифицированы перед созданием шифрованного канала связи. Значит обе стороны должны использовать перед созданием такого канала сертификаты/ЭЦП, раз асимметричное крипто здесь уже задействовано.

И для чего такой велосипед? В любом случае, рекомендуется не переизобретать SSL, ни, тем более, не стоит отходить от общих принципов создания защищённых каналов связи (аутентификация – согласование – шифрование).
— kojemiaka (27/07/2012 14:38)   профиль/связь   <#>
комментариев: 1   документов: 1   редакций: 0
Спасибо за ответ.

Я, правда, не очень понял некоторые понятия. Про сертификаты и ЭЦП вы имеете ввиду HTTPS?
Есть ли готовые решения встройки SSL?
— unknown (27/07/2012 14:54, исправлен 27/07/2012 14:55)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Оно везде уже встроено, например в FF:


Edit--Preferences--Advanced--Encryption--View Certificates--Your-Certificates--Import

Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3