Security Bug с прокси сервером

В связи с тем, что в новых версиях ЛЭРС УЧЕТ перешел на HTTP протокол, на трафик клиент<->сервер начали оказывать влияние как настройки прокси клиента ЛЭРС УЧЕТ так и указанные в свойствах браузера. То есть в клиенте может быть выставлено “Не использовать прокси-сервер”, но прокси сервер может использоваться все равно, так как он прописан в свойствах браузера. В результате получилась очень странная ситуация, пользователь А производя авторизацию под своим логином и паролем заходит под учетной записью пользователя Б, который авторизовался ранее. При этом права у пользователя А становятся как у пользователя Б, но в админке учетных записей обновляется время входа у пользователя А.
Надеюсь я внятно расписал, а то ситуация дикая. Возможно проблема связана с кэшированием прокси сервера, но в любом случае клиент не должен так лажать.

И да проблема наблюдается к на 3.34.7 так и на 3.35.3
Дополнительно выдает ошибку по времени, скриншот прилагаю.
ЛЭРС ошибка времени.png

Добрый день!

По поводу настройки прокси-сервера в клиенте. То, что прокси используется даже если он отключен - это недоработка, которая уже поправлена в 3.36.

То, что ваш прокси-сервер кэширует ответы и выдаёт их, не зависимо от поля Authorization Bearer это проблема, скорее, прокси-сервера. У АРМ оператора нет никаких методов для того, чтобы достоверно отличить кэшированный прокси-сервером ответ от реального ответа сервера.

Единственное, что мы попытаемся сделать - выставить в АРМ оператора заголовок CacheCache-Control: no-store, чтобы сообщить серверу, что АРМ оператора не хочет получать кэшированные данные. Насколько это поможет зависит от того, учитывает ли ваш прокси этот заголовок.

Второй вариант решения проблемы более радикальный - настроить HTTPS на сервере и включить его принудительно. Тогда прокси-серверы не смогут кэшировать ответы.

Что ж подождем стабильной версии 3.36

Но я бы на Вашем месте задумался почему получив “не свой” пакет данных клиент получает чужие права. Ведь получается, что можно перехватить трафик, а потом подставить чужой блок данных тем самым получить права админа. Правда кому это нужно? Но все же.

Ну выполнить запрос, изменяющий данные на сервере, с чужими правами без чужого JWT невозможно. Уж его-то прокси-сервер не должен закэшировать и открыть другим пользователям, так как это параметры запроса к серверу, а не ответа.

Фактически, вы получили подобие атаки “Человек посередине”. От неё не был застрахован и старый протокол обмена. Единственное отличие это то, что он был не HTTP и прокси-серверы его кэшировать не умели. Однако, злоумышленник вполне мог перехватить трафик и подменить или украсть данные.

На порядки сложнее провести такую атаку в случае если обмен между сервером и клиентом зашифрован, а подлинность сервера проверена с помощью удостоверений от третьей стороны. Чтобы радикально решить вашу проблему вы можете настроить обмен с сервером ЛЭРС УЧЁТ через обратный прокси, и зашифровать его с помощью HTTPS. Я уже оставлял ссылку на инструкцию как это сделать.