Defaults.Exposed › Поправки › HSTS (Strict-Transport-Security)

Как да поправите HSTS (Strict-Transport-Security)

HSTS е едноредова инструкция, изпращана от уебсайта ви към всеки браузър: 'завинаги се свързвай с мен само по сигурна, криптирана връзка — никога по незащитената.' Без нея, катинарът може тихо да бъде отнет при споделена WiFi мрежа и самото първо посещение на сайта е изложено.

Заключение за вашия бизнес: Наличието на HTTPS (катинара) не е равнозначно на налагането му. Без HSTS, нападател в същата WiFi мрежа като клиента ви може тихо да деградира връзката до незащитен HTTP — прихващайки данни за влизане, номера на карти и данни от формуляри, докато клиентът не вижда нищо нередно. SSL сертификатът, за който вероятно плащате, е заобиколен. Поправката е безплатна и отнема около 15 минути за когото управлява сайта ви.

Какво може да ви струва това

• Клиенти на кафе, хотелска, летищна или конферентна WiFi могат да им бъде тихо деградирана връзката към сайта ви и данните им да се четат — без никакво предупреждение на екрана им.
• Платихте за HTTPS и имате катинар, но без HSTS нападателите могат просто да го заобиколят; сертификатът дава фалшиво усещане за сигурност.
• Самото първо посещение на сайта ви (преди пренасочване към HTTPS) е слабото място, таргетирано от нападателите — HSTS го затваря за всяко следващо посещение.
• Въпросник за сигурност, формуляр за кибер-застраховка или контролен списък на корпоративен купувач маркира 'без HSTS' и спира сделката докато не е поправено.
• Задайте стойността грешно (твърде кратко) и получавате най-лошото и от двете: изглежда конфигурирано, но осигурява почти никаква реална защита.

Защо има значение. HTTPS защитава връзката, след като е криптирана — но не принуждава браузърите да го използват. Нападателите експлоатират онази пропаст с 'SSL stripping': при всяка споделена мрежа тихо задържат посетителя на незащитен HTTP, четейки всичко. HSTS казва на браузъра да откаже незащитен HTTP за домейна ви изцяло, за дълго, така че пропастта се затваря след първото посещение. Той е единствен отговорен заглавен ред, безплатен за добавяне, и по нашата методология носи реални точки, тъй като липсваща или прекалено кратка стойност оставя всеки посетител на публична WiFi изложен.

Как да го поправите, стъпка по стъпка

1. Сервирайте валиден HTTPS първо. HSTS има смисъл само след като сайтът зарежда правилно по HTTPS с валиден сертификат.
2. Добавете заглавния ред. Изпращайте Strict-Transport-Security: max-age=31536000; includeSubDomains при HTTPS отговори.
3. Започнете с по-кратък max-age. При несигурност, започнете с по-малка стойност, потвърдете, че поддомейните все още работят, след това вдигнете до година.
4. Помислете за preload. След стабилизиране с includeSubDomains, добавете preload и изпратете в списъка за preload на браузъра.
5. Верифицирайте, че е проработило. Проверете отново, за да потвърдите, че заглавният ред е налице при HTTPS отговори.

Какво представлява на прост език

Почти сигурно имате HTTPS — малкият катинар в лентата на браузъра. Добре. Но ето частта, за която почти никой не е информиран: наличието на HTTPS не е равнозначно на налагането му.

HTTPS прави дадена връзка криптирана след като браузърът реши да го използва. HSTS — съкращение от HTTP Strict Transport Security — е инструкцията, карайки браузъра винаги да го използва. Той е единствен, невидим ред, изпращан от уебсайта ви към всеки посетител, казвайки на практика:

„Занапред, за моя домейн, говори с мен само по сигурна връзка. Никога по незащитената. Дори не опитвай.”

Браузърът запомня това и го прилага за толкова, колкото му кажете — обикновено година. След първото сигурно посещение на посетителя, браузърът му просто ще откаже зареждане на сайта ви по незащитен, некриптиран HTTP, дори нещо да се опита да го принуди.

Без HSTS, онова правило „винаги използвай сигурната версия” не съществува — и нападателите знаят точно как да експлоатират пропастта.

Какво може да ви струва това

Това са реалистични ежедневни сценарии. Никога не назоваваме реален бизнес; това са илюстрации на начина, по който се използва пропастта.

1. Касата в кафенето. Клиент отваря магазина ви на кафе WiFi и отива да плати. Нападател в същата мрежа изпълнява безплатен, добре известен инструмент, задържащ клиента на незащитен HTTP вместо HTTPS. Клиентът вижда нормален сайт — без предупреждение, без счупен катинар на видното място — и въвежда данните за картата. Нападателят чете всеки натискан клавиш. SSL сертификатът не е направил нищо, защото връзката никога не е получила шанс да стане сигурна.

2. Пътуващият служител. Персонален служител влиза в административния панел или уеб-пощата ви от хотел или летище. Същият трик за деградиране улавя потребителското наименование и паролата им. Сега нападателят има достъп до бизнеса ви — не защото политиката ви за пароли е слаба, а защото страницата за влизане е достъпна по незащитен HTTP.

3. Сделката, спряла. По-голям клиент ви изпраща стандартния им въпросник за сигурност преди подписване. Един ред пита: „Налага ли уебсайтът ви HTTPS чрез HSTS?” IT контактът трябва да отговори „не” и процесът по обществените поръчки спира, докато не поправите безплатна, 15-минутна настройка, изглеждаща сега като червен флаг пред купувач.

4. Проверката за кибер-застраховане или съответствие. Сканирането на застраховател или одитор, разглеждащ позицията ви по защита на данните, маркира липсващия заглавен ред. Криптирането на лични данни е изрично очакване под правилата за защита на данните (GDPR Член 32) и „имаме сертификат, но не го налагаме” е слаба позиция.

5. Фалшивото усещане за сигурност. Плащате за SSL, катинарът се показва и всички приемат, че сайтът е сигурен. До голяма степен е — докато клиент не е в споделена мрежа, което е именно моментът, когато е най-уязвим и най-малко вероятно да забележи нещо нередно.

Общата нишка: цената не е абстрактна. Това са реалните данни за карта или влизане на клиента, уловени в най-лошия възможен момент, без никаква аларма.

Какво всъщност е

Когато браузърът заявява страница от уебсайта ви, сървърът изпраща страницата плюс невидими „заглавни редове” — допълнителни инструкции, четени от браузъра, но невидими за посетителя. HSTS е един от тях:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Три части имат значение:

• max-age — колко дълго (в секунди) браузърът трябва да помни да налага HTTPS. 31536000 е една година. Това е сърцевината му: прекалено кратко и едва помага.
• includeSubDomains — разширява правилото към всеки поддомейн (shop., app., mail. и т.н.), не само основния адрес.
• preload — записва домейна ви в основен списък, вграден в браузърите, така че защитата се прилага дори при самото първо заявяване на посетителя, преди изобщо да са виждали сайта ви.

Защо „първото посещение” е важно

HSTS има едно присъщо ограничение: браузърът спазва правилото само след като е виждал заглавния ред поне веднъж. Така самото първо свързване на посетителя е все пак малко прозорче на изложеност. Две неща го стесняват: пренасочване от HTTP към HTTPS (което ги отвежда бързо към сигурната версия) и preload (което премахва прозорето изцяло). Затова пълната настройка сдвоява HSTS с правилно пренасочване.

Как изглежда „добро” — и как се оценява

Проверката ни чете активния ви заглавен ред и оценява max-age:

Така заглавен ред, съществуващ, но зададен на няколко минути, се третира като неуспех — изглежда конфигурирано, но не върши работата. Целете се за година. Проверката отбелязва и дали includeSubDomains и preload са налице.

Как да го поправите (безплатно, ~15 минути)

Дайте тази секция на когото управлява уебсайта ви — IT специалиста, уеб разработчика или поддръжката на хостинга. Поправката е безплатна. Един заглавен ред или превключвател в платформата. Нищо за купуване.

Едно важно правило за наредба първо: HSTS е лепкав — след активиране, браузърите ще откажат незащитен HTTP за домейна ви за целия max-age. Затова потвърдете, че HTTPS работи правилно на основния сайт и всеки поддомейн преди широкото активиране. Безопасният маршрут е: тест с кратка стойност → потвърждаване, че нищо не се чупи → вдигане до година.

Стъпка 1 — Уверете се, че HTTPS вече работи навсякъде

Посетете сайта и ключовите поддомейни по https:// и потвърдете, че зареждат чисто с валиден сертификат. Потвърдете и, че незащитените http:// заявки пренасочват към https://. (Ако не го правят, поправете HTTP към HTTPS пренасочването първо — HSTS приема, че е на място.)

Стъпка 2 — Добавете заглавния ред (изберете платформата)

Cloudflare (или подобен CDN): Това е най-лесното. Отидете на SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) и го активирайте. Задайте Max-Age на 6 месеца или 12 месеца и активирайте „Apply HSTS policy to subdomains” след като сте сигурни, че всички поддомейни са на HTTPS.

Nginx: добавете вътре в блока server за HTTPS:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Apache: уверете се, че mod_headers е активиран, след това добавете в HTTPS виртуалния хост:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Microsoft IIS: добавете в web.config вътре в <customHeaders>:

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />

Бележка за Google Workspace / Microsoft 365: те управляват имейла ви, а не хостинга на уебсайта — HSTS се задава там, където действително се намира публичният ви уебсайт (CDN-ът, уеб сървърът или конструкторът на сайтове), а не в административните конзоли на Workspace/365. Ако сайтът е на конструктор като Squarespace, Wix или Shopify, HSTS обикновено се обработва вместо вас; проверете SSL/security настройките им ако проверката ни го маркира.

Стъпка 3 — Тест с малка стойност, после ангажиране

Започнете с max-age=300 (5 минути). Потвърдете, че сайтът все още зарежда перфектно навсякъде. После вдигнете до max-age=31536000 (година). Това е настройката с пълни точки.

Стъпка 4 (незадължително, златен стандарт) — preload

След като сте уверени и сте изпълнявали едногодишен заглавен ред с includeSubDomains известно време, можете да изпратите домейна в hstspreload.org за вграждане в браузъри. Това затваря прозорето при първо посещение изцяло. Третирайте го като обмислен ангажимент — отстраняването на домейн от списъка е бавно.

Чести грешки

• Задаване на max-age прекалено кратко. Стойност от няколко минути или часа изглежда конфигурирана, но осигурява почти никаква защита — и проверката ни третира всичко под ден като неуспех. Използвайте година.
• Включване на includeSubDomains преди поддомейните да са готови за HTTPS. Ако поддомейн не е изцяло на HTTPS, лепкавото правило може да го направи недостъпен за посетителите. Прехвърлете всеки поддомейн на HTTPS първо.
• Добавяне на HSTS, но без HTTP към HTTPS пренасочване. HSTS приема, че посетителите достигат сигурната версия; без пренасочване, първото посещение е излишно изложено. Поправете и двете заедно.
• Прескачане направо към preload „за пълнота.” Preload е труден за отмяна. Спечелете го постепенно след стабилен едногодишен заглавен ред — не го бързайте.
• Приемане, че катинарът означава, че сте покрити. Катинарът и HSTS са различни неща. Можете да имате перфектен сертификат и все пак да не минавате тази проверка.

ЧЗВ