Url Rewriting - Это вызывает проблему безопасности?
Привет, я недавно прочитал JSP и наткнулся на его технологии, главным образом на сеанс. В сеансе я прочитал переписывание URL одного из методов, которые были выполнены для поддержания сеанса с клиентом. Но поскольку переписывание URL-адресов изменяет URL-адрес с идентификатором сеанса, он может быть виден клиенту.
Разве это не проблема безопасности? Скажем, например, если кто-то отмечает этот идентификатор сеанса отдельно от конкретного пользователя и может плохо его использовать? Или есть методы для предотвращения этих проблем?
Исправьте меня, если я ошибаюсь.
Ответы
Ответ 1
Конечно, это проблема безопасности. Если вы быстро обратите внимание на значение jsessionid, либо от кого-то другого по ошибке в общедоступном URL-адресе с копией, либо в опубликованном скриншоте с некоторым HTTP-средством отладки (Firebug), который показывает заголовки запроса/ответа и соответствующий веб-сайт поддерживает пользователей по логину, тогда вы сможете войти под одним и тем же пользователем, просто добавив cookie jsessionid к URL-адресу или заголовкам запроса. Быстро, потому что эти сеансы истекают по умолчанию после 30 минут бездействия. Это называется атакой фиксация сеанса.
Вы можете полностью отключить переписывание URL-адресов, чтобы jsessionid никогда не отображался в URL-адресе. Но вы по-прежнему чувствительны к атакам фиксации сеанса, некоторые хакеры, возможно, установили сниффер трафика HTTP в общедоступной сети или с помощью какого-либо трояна/вируса или даже использовали XSS, чтобы узнать об этих куках. Чтобы быть ясным, эта проблема безопасности не является специфичной для JSP, PHP, ASP или любого другого веб-сайта, который поддерживает логин на основе cookie-базы, так же хорошо реагирует на это.
Чтобы быть действительно безопасным в отношении логинов, пусть входной и входной трафик переходят через HTTPS вместо HTTP и делают только cookie HTTPS (безопасный).
Ответ 2
URL-адрес перезаписи cookie сеансов не рекомендуется в большинстве (если не во всех) окружениях безопасности. OWASP ASVS явно препятствует его использованию, поскольку это приводит к экспонированию идентификаторов сеанса через небезопасный носитель.
Когда URL-адрес перезаписи cookie сеанса включен, URL-адрес может быть передан (с идентификатором сеанса) на другие сайты, что приведет к раскрытию идентификатора сеанса через заголовок HTTP-Referrer. Фактически, простой запрос браузером к ресурсу, расположенному в другом домене, приведет к возможному захвату (посредством атаки Man-In-The-Middle) или фиксации сеанса; это так же хорошо, как уязвимость Cross Site Scripting на сайте.
С другой стороны, дополнительные механизмы защиты, такие как флаги HttpOnly и Secure-Cookie, внедренные в различные браузеры для защиты файлов cookie сеанса различными способами, больше не могут использоваться, когда URL-переписывание файлов cookie выполняется сайтом.
Ответ 3
Я считаю, что вы имеете в виду cookieless session. Хотя я видел, что он упоминается как "переписывание URL" в кругах Java.
Есть некоторые дополнительные проблемы с захватом сеансов (и они применяются во всех инфраструктурах веб-разработки, которые поддерживают сеансы cookieless, а не только JSP). Но захват сеанса возможен даже с помощью файлов cookie.
Вот довольно хорошая углубленная статья о MSDN о cookieless сессиях и рисках/преимуществах. Опять же, все они являются агностиками платформы.
http://msdn.microsoft.com/en-us/library/aa479314.aspx (в нижней части)
