Вопрос или проблема
Firesheep привлек внимание к проблеме небезопасного обмена куками.
Как можно убедиться, что все обмены куками происходят только через SSL-защищенное соединение с сервером при общении с веб-пользователем?
Наш сценарий таков: веб-приложение написано на ASP.NET 4.0 и размещено на Windows Server 2008 R2 с IIS 7.5, если это сузит круг вопросов.
Вы можете использовать app.config, чтобы заставить это; формат (в секции <system.web>)
<httpCookies domain="String"
httpOnlyCookies="true|false"
requireSSL="true|false" />
так что вы действительно хотите, по крайней мере
<httpCookies requireSSL='true'/>
Но желательно также включить httpOnlyCookies, если только вы не используете какой-то действительно хитрый JavaScript.
Самый безопасный способ защитить ваш сайт от Firesheep (и связанных атак):
-
Перейдите на сайт с защитой SSL: Перенесите весь ваш сайт на HTTPS и отключите весь доступ по HTTP. Другими словами, защитите весь сайт с помощью SSL. Вот еще несколько ресурсов по этому вопросу: как защититься от Firesheep, плюсы и минусы глобального SSL, почему SSL защищает от Firesheep.
-
Устанавливайте флаг SECURE для всех куков: Всякий раз, когда сервер устанавливает куку, обеспечьте установку флага SECURE на куку. Флаг SECURE говорит браузеру пользователя отправлять эту куку только через SSL-защищенные (HTTPS) соединения; браузер никогда не будет отправлять куку с установленным флагом SECURE по незашифрованному (HTTP) соединению. Самый простой шаг — установить этот флаг на каждую куку, используемую вашим сайтом.
Также я рекомендую некоторые дополнительные шаги:
- Будьте осторожны с контентом третьих сторон: Виджеты, библиотеки и контент третьих сторон могут быть риском для безопасности. Если вы включаете JavaScript от третьих сторон (например, через
<SCRIPT SRC=...>), я рекомендую убедиться, что они ссылаются на HTTPS-URL; в противном случае вы подвергаете безопасность вашего сайта активным атакам. (Смотрите также Часто задаваемые вопросы Джеремайи Гроссмана о виджетах третьих сторон.) Чтобы избежать перегрузки ваших пользователей предупреждениями о смешанном контенте, убедитесь, что все содержимое, включая сторонние изображения и библиотеки, также доставляется через HTTPS.
Некоторые могут утверждать, что вышеизложенное — излишек. В некоторых случаях может быть возможно защититься от Firesheep, используя SSL только на части сайта. Однако это требует осторожности и детального знания и сложнее в правильной настройке. Учитывая, что вам приходится задавать этот вопрос здесь, я лично рекомендую начать с глобального SSL; у вас больше шансов сделать это правильно.
Как реализовать это в IIS: Я не эксперт в IIS, поэтому не могу дать вам окончательный рецепт о том, как реализовать эти шаги в IIS. Однако эта ссылка на включение SSL на IIS может быть вам полезна. Похоже, вы можете щелкнуть правой кнопкой мыши по корневому сайту, выбрать Свойства, нажать на вкладку Безопасность каталога, затем в Защищенные коммуникации нажать Изменить и включить Требовать безопасный канал (SSL). Я не знаю, как сконфигурировать IIS для автоматической установки флага SECURE на все куки. Для миграции существующего сайта я рекомендую настроить переадресацию так, чтобы каждый, кто посещает HTTP-страницу, перенаправлялся на HTTPS. Следующие ссылки могут помочь с этим (не проверено): переадресация на HTTPS, три метода переадресации на HTTPS. Если вы мигрируете существующий сайт, вам также необходимо изменить все ссылки и ссылки на ваш сайт с http: URL-адресов на https: URL-адреса. Я не уверен, как настроить ASP.NET для установки флага SECURE на все куки, но, думаю, вы можете добавить cookieRequireSSL="true" или <httpCookies requireSSL="true"> в ваш Web.config; это важно сделать, и особенно важно, если у вас включен HTTP или если у вас есть какого-либо рода переадресация с HTTP-страниц на HTTPS-страницы. Наконец, существует много материалов, опубликованных по оптимизации производительности для HTTPS.
Я наткнулся на эту тему, когда решал проблему сам. Решение, которое я нашел, заключается в том, что пути к кукам чувствительны к регистру. Вот связанный вопрос.
https://stackoverflow.com/questions/399982/why-are-cookie-paths-case-sensitive
Мое решение заключалось в переадресации с главной страницы на правильный путь. Обязательно следите за возможными циклами переадресации.
url.com/VirtualDirectory/default.aspx ->
//что теперь даст правильный путь url.com/virtualdirectory/default.aspx
response.redirect(“~/default.aspx”);
Я установил куку с флагом secure через защищенное соединение HTTPS на своем локальном компьютере для разработки. Когда я вызываю защищенный маршрутизатор аутентификации, который требует куку, через незашифрованное соединение (HTTP), браузер тем не менее добавляет куку с флагом secure. Это потому, что я тестирую это на локальном соединении?
Ответ или решение
Чтобы обеспечить отправку всех cookie только по защищенному SSL-соединению при использовании ASP.NET на сервере IIS 7.5, необходимо выполнить несколько ключевых шагов. Вот подробное руководство:
1. Включение SSL на вашем сайте
Настройка SSL в IIS
- Откройте IIS Manager и выберите ваш сайт.
- Щелкните правой кнопкой мыши на корень сайта, выберите Свойства.
- Перейдите на вкладку Безопасность каталога и в разделе Безопасная связь нажмите кнопку Изменить.
- Установите флажок Требовать защищенный канал (SSL). Это заставит ваш сайт использовать HTTPS для всех запросов.
2. Символическое управление куками
В Web.config вашего приложения добавьте следующие строки в секцию <system.web>:
<system.web>
<httpCookies requireSSL="true" httpOnlyCookies="true" />
</system.web>requireSSL="true"— заставляет сервер выставлять флагSecureдля всех куки, что обеспечивает их передачу только по SSL-соединению.httpOnlyCookies="true"— защищает куки от доступа через JavaScript, что снижает риск атак.
3. Настройка флага Secure для куки
Если у вас есть кастомные куки, убедитесь, что при их создании выставляется флаг Secure. Например:
HttpCookie myCookie = new HttpCookie("MyCookie", "cookieValue");
myCookie.Secure = true; // Устанавливаем флаг Secure для куки
Response.Cookies.Add(myCookie);4. Перенаправление с HTTP на HTTPS
Для того чтобы обеспечить безопасный доступ ко всем частям сайта, рекомендуется настроить перенаправление всех HTTP-запросов на HTTPS. Для этого можете использовать модуль URL Rewrite в IIS или добавить следующий код в Global.asax.cs:
protected void Application_BeginRequest(object sender, EventArgs e)
{
if (!Context.Request.IsSecureConnection)
{
string url = "https://" + Context.Request.Url.Host + Context.Request.RawUrl;
Response.Redirect(url);
}
}5. Использование только HTTPS для стороннего контента
Если ваше приложение использует сторонние скрипты и библиотеки, убедитесь, что они загружаются по HTTPS, чтобы избежать угрозы безопасности и смешанного контента.
6. Проверка конфигурации
После всех изменений рекомендуется провести тестирование:
- Попробуйте получить доступ к вашему сайту через HTTP и проверьте, что происходит перенаправление на HTTPS.
- Проверьте в инструментах разработчика вашего браузера, что куки имеют флаг
Secureи передаются только через HTTPS.
Заключение
Соблюдение этих шагов обеспечит безопасную передачу куки через SSL, что очень важно для защиты ваших пользователей от таких атак, как Firesheep. Если у вас имеются дополнительные вопросы или требуется помощь с конфигурацией, не стесняйтесь обращаться к сообществу разработчиков или специализированным ресурсам по безопасности.