Безопасное использование файлов cookie и смешанного использования https/http

Ответ 1

Решение, которое вы предлагаете, похоже, что это сработает, если вы не возражаете против неавторизованных людей, которые могут просматривать незащищенную (http) часть сайта, "как если бы они вошли в систему", т.е. пока http-часть сайта не содержит никакой конфиденциальной информации, и единственное различие между зарегистрированными и не зарегистрированными пользователями является чем-то безвредным в заголовке.

Причина, по которой он не используется очень часто, может быть одним из:

• Этот сценарий может быть не очень распространенным. Обычно, если вы будете достаточно осторожны, чтобы обеспечить безопасность своего сайта, вы ограничили бы сеанс входа в систему только этой защищенной частью или сделали бы весь сайт всегда использующим HTTPS (например, Paypal).
• Существуют существующие ранее существующие решения, которые могут быть более безопасными, например, регистрироваться у кого-то в форме входа в систему HTTPS и поддерживать этот сеанс при передаче их обратно в HTTP. OpenID пример. Также подумайте, что flickr или gmail: их страница на странице всегда HTTPS, но после начала сеанса вы переходите к HTTP, сохраняя безопасный сеанс.

Обновление (август 2014 г.)

С тех пор как я написал это еще в 2009 году, практика подключения к экрану входа в систему безопасного доступа, но возврат к HTTP после входа в систему практически исчезла.

Накладные расходы на использование HTTPS по всему периметру больше не рассматриваются. Новый протокол SPDY, впервые внедренный Google (теперь развитый в HTTP/2), поддерживается кросс-браузером и основными веб-серверами и повышает скорость HTTPS.

И, наконец, конфиденциальность считается более важной, чем когда-либо, даже для действий, которые не имеют решающего значения для аутентификации, таких как написание комментариев, загрузка фотографий и т.д.

Google даже недавно заявил, что сайты, которые являются HTTPS-only, начнут приносить пользу в рейтингах поисковых систем.

Ответ 2

С точки зрения безопасности вы никогда не должны доверять никакому контенту, отправленному по незащищенному соединению. Поэтому, имея в виду, тогда безопасно использовать cookie, отправленный по незашифрованному соединению, только если стоимость кражи или неправильного использования этого файла cookie равна нулю.

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

Если у вас есть данные, которые не соответствуют этим обобщениям, тогда не стесняйтесь делать это, как вам угодно.

Ответ 3

Передача файлов cookie через HTTP по-прежнему беспокоит меня. Я думаю, что описанная вами техника является единственным разумным способом защиты куки файлов, позволяя зарегистрированным пользователям просматривать страницы HTTP, как если бы они вошли в систему. Однако я редко видел, что это реализовано.

Почему сайты не используют такую ​​настройку и имеют безопасные куки?

Я думаю, что основной причиной отсутствия усыновления является управление рисками:

• Кражи токенов сеанса с помощью подслушивания намного сложнее, чем, например, межсайтовый скриптинг (при условии наличия уязвимости). Вам необходим доступ к сети (например, LAN пользователя или интернет-провайдер). Таким образом, в соответствии с основанной на рисками приоритизацией разработчики должны сначала решать проблемы XSS, потому что они обеспечивают гораздо большую поверхность атаки (вероятность атаки намного выше).
• То же самое верно для исправления CSRF и UI (так называемый щелчок).
• Если влияние бизнеса на взломанные сессии очень велико (например, хранение кредитных карт для последующего использования в интернет-магазине), вам может быть лучше ограничить весь ваш сайт HTTPS.

Еще одна причина может быть связана с удобством использования. С вашей предлагаемой схемой вы эффективно управляете двумя параллельными сеансами для одного пользователя. Это достаточно просто до тех пор, пока зарегистрированный флаг является единственным состоянием, сохраненным в небезопасной сессии. Если вы также можете изменить настройки, такие как язык и страну, в рамках обеих сессий, это может стать беспорядочным (реализовать или использовать).

Есть ли лучший способ достичь того же?

Из Руководство для хакеров для веб-приложений:

Если HTTP файлы cookie используются для передачи токенов, их следует помечать как secure, чтобы браузер пользователя никогда не передавал их по HTTP. Если это возможно, HTTPS следует использовать для каждой страницы приложения, включая статический контент, такой как страницы справки, изображения и т.д.

Серьезно, чтобы весь сайт использовал HTTPS. Несколько лет назад это было бы невозможно, главным образом из-за того, что CDN не обеспечивали поддержку HTTPS. Однако сегодня речь идет главным образом о балансировании расходов на разработку и эксплуатацию.

Ответ 4

Я полностью понимаю, что рекомендуемая практика - просто принудительно использовать SSL на всем сайте. Тем не менее, есть, безусловно, уникальные случаи, когда возможность выбора и выбора между HTTP и HTTPS может пригодиться.

Я столкнулся с подобным сценарием, как @Dsavid Gardner. Моя компания использует стороннего поставщика для управления нашей частью магазина нашего сайта, и этот магазин находится в субдомене " https://store.mysite.com". У нас есть видеоконтент на 15 лет, и наш нынешний поставщик видеоуслуг ломается, когда видео встроено в SSL. (Я предполагаю, что он втягивает ресурсы из доменов HTTP, но эта другая проблема на другой день)

Конечно, я мог бы приобрести SSL и пройти процесс отладки двух сторонних поставщиков, а также выполнить поиск и замену на всей нашей базе данных (или hhtaccess, но я отвлекся), чтобы исправить любые ссылки на ресурсы HTTP, чтобы иметь возможность иметь сообщение в заголовке, говорим "Добро пожаловать" YourName ", но это просто похоже на излишний.

Здесь простое решение Javascript, с которым я столкнулся, устанавливает обходной, небезопасный файл cookie, основанный на безопасных файлах cookie, которые уже установлены.

Сначала Я захватил некоторые функции cookie javascript. Идите дальше и поместите этот код в безопасную часть вашего сайта:

function readCookie(name) {
    var nameEQ = name + "=";
    var ca = document.cookie.split(';');
    for(var i=0;i < ca.length;i++) {
        var c = ca[i];
        while (c.charAt(0)===' ') { 
            c = c.substring(1,c.length);
        }
        if (c.indexOf(nameEQ) === 0) {
            return c.substring(nameEQ.length,c.length);
        }
    }
    return null;
 }
 function setCookie(cname, cvalue, exdays) {
    var d = new Date();
    d.setTime(d.getTime() + (exdays*24*60*60*1000));
    var expires = "expires="+d.toUTCString();

    /* Note, the W3 documents where I got this code didn't include the
    option to set the domain. I added this and it allows the cookie 
    to be shared across sub-domains. Be sure not to add "www" */
    document.cookie = cname + "=" + cvalue + "; " + expires + "; domain=.yourdomain.com";
 }
 /*Now we check our cookies on our secure server to find out if the user is
 logged in or not. In my case, the First Name is stored as a cookie. */
 var firstNameCookie = readCookie("the-secure-cookie-name");
 //
 if(!firstNameCookie){
    /* If the cookie doesn't exist, then the person isn't logged in. Add 
    conditional logic here if you'd like (such as deleting any current 
    logged in cookies from the HTTP portion of the site) */
 }
 else {
    /* otherwise, we have a successful login. By grabbing the cookie via 
    this javascript resting on the secure server, we haven't compromised our 
    security. However, if we set a cookie with javascript right now, it 
    won't be a secure cookie by default and we'll have access to it with 
    HTTP on the subdomain */
    setCookie("HTTPfirstName", firstNameCookie, 1.5);
 }

 */The clients first name is now accessible across subdomains in the cookie
  entitled "HTTPfirstName" */

В этом случае единственное, что мы просочились на наш HTTP-сервер, - это имя клиента. Однако, если вы хотите еще больше безопасности, вы можете установить параметры своего сервера, чтобы разрешить доступ к определенным файлам cookie (т.е. "firstNameCookie" ) по HTTP-запросу и добавляет дополнительный уровень защиты. Вы можете узнать, как это сделать здесь

Конечно, это не самое идеальное решение. В будущем я планирую внедрить SSL-сайт, но с простой функцией javascript, чтобы заменить его, тем не менее, приятно иметь.