Текущий процесс
В течение многих лет мы использовали Java-апплеты, встроенные в веб-приложения, которые запускаются в браузере IE, чтобы позволить пользователю проходить аутентификацию.Причина этого заключается в том, что веб-приложения должны взаимодействовать с нашим агентом идентификации, который работает на компьютере пользователя как отдельное приложение Windows.Веб-приложение (java-апплет) загружает DLL, установленную на компьютере, и веб-приложение затем может получить токен аутентификации от нашего агента идентификации с помощью открытых методов в загруженной DLL.
Проблемы с текущим процессом
- Основная проблема заключается в безопасности этого процесса аутентификации - Java-апплеты давно устарели в большинстве браузеров (кроме IE)
- Все накладные расходы по настройке системы, Java и IE, чтобы веб-приложения могли запускать Java-апплеты для определенных доменов.
- Java должна быть установлена на машине -> в идеале мы хотим получитьизбавиться от этой зависимости
- Поддерживается только IE -> в идеале мы хотим, чтобы веб-приложения работали в любом браузере настольного компьютера
Другие решения, которые мы пробовали, но не сделалине идеальны
Передача токена аутентификации в веб-приложение как часть параметров URL -> это небезопасно.Несмотря на то, что мы могли бы зашифровать переданные параметры URL с помощью некоторого общего секрета, однако этот подход не выглядит для нас правильным и представляет другие уязвимости.
Использование сокетов в работающем веб-приложении и нашемличность агента для достижения межпроцессного взаимодействия.Это было установлено в качестве рабочего решения на незащищенных (http) веб-сайтах.Для защищенных веб-сайтов (https) этот подход не работал из-за ограничений XSS.
ВОПРОС:
Есть ли в настоящее время какие-либо возможности передачизащищенный контекст аутентификации (токен) от процесса Windows к веб-браузеру / веб-сайту (например, установка файлов cookie сеанса, локальное хранилище и т. д.), и как этого можно достичь?
Большое спасибо за все ваши предложения.
ОБНОВЛЕНИЕ
Я не правильно сказал, что Передача токена аутентификации в веб-приложение какчасть параметров URL небезопасна - , она защищена от сетевого уровня, если используется https .
1. Однако запуск процесса браузера сURL будет сохранять URL в истории браузера (см. здесь ).Решением может быть запуск процесса браузера в режиме инкогнито с заданным URL-адресом, поэтому новый URL-адрес сохраняется в истории браузера или сохраняется в любом месте.
2. С учетом вышеизложенного все еще существует проблема, заключающаяся в том, что пользователь может видеть полный URL-адрес в браузере, пока не будет использован токен аутентификации и пользователь не будет перенаправлен (полный URL-адрес неболее заметным), и если пользователю / злоумышленнику удается получить полный URL-адрес, URL-адрес можно использовать повторно (атака с сортировкой или повторным воспроизведением).Однако это может быть смягчено путем применения некоторой дополнительной логики в службе, которая использует токен аутентификации - и это то, что токен может быть использован только один раз (так что атака воспроизведения невозможна).
3. Потенциальная проблема с решением во 2-м пункте может возникнуть, если токен аутентификации по какой-то причине не может быть использован (например, проблемы с сетью), что означает, что атака воспроизведения будет действительно работать - захват сеанса пользователя.
Есть ли способ как-то смягчить проблему в 3-м пункте?