#security #jsp #session
#Безопасность #jsp #сессия
Вопрос:
Привет, я недавно прочитал JSP и наткнулся на его технологии, в основном session. В разделе session я прочитал, что перезапись URL является одним из методов, который был выполнен для поддержания сеанса с клиентом. Но поскольку перезапись URL изменяет URL с идентификатором сеанса, и он может быть виден клиенту. Разве это не проблема безопасности? Допустим, например, если кто-либо отмечает этот идентификатор сеанса отдельно от конкретного пользователя и может использовать его неправильно? Или еще есть методы для предотвращения этого?
Поправьте меня, если я ошибаюсь.
Ответ №1:
Конечно, это проблема безопасности. Если вы быстро обратите внимание на jsessionid значение, либо из-за того, что кто-то другой ошибочно скопировал общедоступный URL-адрес, либо из-за публично опубликованного скриншота какого-либо средства отладки HTTP (Firebug), которое показывает заголовки запроса / ответа, и веб-сайт, о котором идет речь, поддерживает пользователей с помощью логина, тогда вы сможете войти под тем же пользователем, просто добавив jsessionid cookie к URL или заголовкам запроса. Быстро, потому что срок действия этих сеансов истекает по умолчанию после 30 минут бездействия. Это называется атакой с фиксацией сеанса.
Вы можете полностью отключить перезапись URL-адреса, чтобы jsessionid никогда не отображался в URL-адресе. Но вы по-прежнему чувствительны к атакам с фиксацией сеанса, какой-нибудь хакер мог установить анализатор HTTP-трафика в общедоступной сети или с помощью какого-нибудь трояна / вируса, или даже использовать XSS, чтобы узнать об этих файлах cookie. Чтобы было ясно, эта проблема безопасности не специфична для JSP, PHP, ASP или любого другого веб-сайта, который поддерживает вход в систему с помощью сеанса на основе cookiebased, также чувствителен к этому.
Чтобы быть действительно безопасным в отношении логинов, разрешите трафику входа в систему проходить через HTTPS вместо HTTP и сделайте cookie HTTPS (безопасным) только.
Комментарии:
1. Хорошо сказано, но почему это не относится конкретно к JSP?
2. JSP
HttpSessionподдерживаетсяjsessionidфайлом cookie. PHP$_SESSIONподдерживаетсяPHPSESSIDфайлом cookie. ASPSessionподдерживаетсяASPSESSIONIDфайлом cookie. Если вы сохраняете вошедшего в систему пользователя в сеансе, на самом деле не имеет значения, какой язык более чувствителен или нет. JSPjsessionidпросто чаще появляется в новостях, потому что на некоторых серверах / фреймворках Java по умолчанию включена перезапись URL-адресов.3. О, хорошо, я неправильно понял, что вы сказали, спасибо за ответ
4. То, что описывается как фиксация сеанса, на самом деле называется перехватом сеанса. Перехват означает, что злоумышленник использует идентификатор сеанса жертвы. Фиксация сеанса означает, что злоумышленник заставляет жертву использовать подготовленный сеанс злоумышленника, например, позволяя им запрашивать ссылку, содержащую идентификатор сеанса злоумышленника.
5. может кто-нибудь, пожалуйста, пролить больше света на «Вы можете полностью отключить перезапись URL-адреса, чтобы jsessionid никогда не отображался в URL»
Ответ №2:
Перезапись URL-адреса сеансовых файлов cookie не рекомендуется в большинстве (если не во всех) служб безопасности. OWASP ASVS явно не рекомендует его использование, поскольку это приводит к раскрытию идентификаторов сеанса через небезопасный носитель.
Когда включена перезапись URL-адреса сеансовых файлов cookie, URL-адрес может передаваться (с идентификатором сеанса) на другие сайты, что приводит к раскрытию идентификатора сеанса через заголовок HTTP Referrer. Фактически, простой запрос браузера к ресурсу, расположенному в другом домене, приведет к возможному перехвату (посредством атаки «Человек посередине») или фиксации сеанса; это так же хорошо, как уязвимость межсайтового скриптинга на сайте.
С другой стороны, дополнительные механизмы защиты, такие как флаги HttpOnly и Secure-Cookie, введенные в различные браузеры для защиты сессионного cookie различными способами, больше не могут использоваться, когда веб-сайт выполняет перезапись URL-файлов cookie.
Ответ №3:
Я полагаю, вы имеете в виду сеансы без приготовления. Хотя я видел, что в кругах Java это называется «перезапись url».
Существуют некоторые дополнительные проблемы с перехватом сеанса (и они применимы ко всем фреймворкам веб-разработки, которые поддерживают сеансы без приготовления, а не только JSP). Но перехват сеанса возможен даже с использованием файлов cookie.
Вот довольно хорошая подробная статья на MSDN о сеансах без использования cookies и рисках / преимуществах. Опять же, все это не зависит от платформы.
http://msdn.microsoft.com/en-us/library/aa479314.aspx (в нижней части)
Ответ №4:
Это то, к чему я пришел, проверяя спецификации OWASP для перезаписи URL-адреса, и это раскрытие информации о сеансе в URL-адресе представляет собой растущую угрозу безопасности (с 7-го места в 2007 году до 2-го в 2013 году в списке 10 лучших OWASP).
Варианты управления перезаписью URL-адреса включают :
отключение их на уровне сервера. отключение их на уровне приложения. Привлекательным вариантом является фильтр сервлетов. Фильтр оборачивает объект response альтернативной версией, которая изменяет response.encodeURL(String) и связанные с ним методы на неоперационные. (Инструмент WEB4J включает в себя такой фильтр.)