C, PHP, VB, .NET

В редица предишни статии написах как винаги целия трафик трябва да минава през HTTPS с валиден сертификат от trusted authority, разбира се ако искаме да предотвратим MITM атаките. Това най-лесно се постигаше с .htaccess файл със следния код:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Също така (като по-лош вариант) можехме лесно да го направим и в самия PHP скрипт, като поставим следния код преди стартирането на сесията (т.е. съвсем в началото на скрипта):

if ($_SERVER['HTTPS'] != "on") {
   $url = "https://";
   $url .= $_SERVER['SERVER_NAME'];
   $url .= $_SERVER['REQUEST_URI'];
   header("Location: $url");
   return;
}

Всичко това гарантира, че нашия сървър няма да допусне изпращане на информация по некриптиран канал. Така ако потребителя стриктно следи за наличието на „катинарчето“ в своя браузър, всичко ще бъде наред. Ключовата дума тук e „ако“. Може ли тази защита да бъде прескочена ако потребителя е невнимателен и не следи дали адреса му започва с https? Отговорът е, че може – чрез SSLStrip!

Схемата на SSLStrip е класическа MITM атака, в която хакера подменя трафика на потребителя. Ключовото тук е, че потребителя ще получава информацията си по HTTP канал, докато хакера ще си комуникира със сървъра по HTTPS (което нашия сървър би трябвало да го задължава да прави).

Потребител <-http-> Хакер <-https-> Сървър

Последователността на атаката е следната:

1. Потребителят иска да отвори httpS://securewebsite.dom
2. Хакерът му връща отговор за пренасочване към http://securewebsite.dom
3. Потребителят изпраща заявка за отваряне на http://securewebsite.dom
4. Хакерът отваря httpS://securewebsite.dom и получава уеб страницата от сървъра
5. Хакерът изпраща получената уеб страница по http до потребителя
6. Потребителят изпраща POST заявка (примерно име и парола) отново по http, която хакера получава
7. Хакерът си записва съдържанието на POST заявката и го препраща към сървъра по httpS
8. Сървърът връща отговор, който хакера отново препраща към потребителя по http и т.н.

Виждате, че от гледна точка на сървъра всичко е нормално и е спазено. От гледна точка на клиента единственият проблем е, че в адресната лента на браузъра стои http, а не https. При потребителя няма предупреждения за сигурността на връзката, които да го подсетят.

Като защита от този вид атаки, може да използвате следните две препоръки:

1. Включете HSTS (HTTP Strict Transport Security)

Идеята на HSTS е да накарате клиенския браузър да запомни, че вашия сайт използва HTTPS при първоначалното му отваряне и от там нататък да го изисква при повторни отваряния. Така ако повторното отваряне е с MITM SSLStrip атака, браузърът ще даде съобщение за проблем със сигурността. Естествено може да се досетите, че това е добра, но не 100%-ова защита, защото не покрива случаите, в които потребител отваря уебсайт за първи път и още тогава е подложен на SSLStrip атака. За тези случаи някой браузъри включват т.нар. „hsts preload list“, който ще бъде обяснен по-долу.

Включването на HSTS е много лесно. Можете да го изпратите чрез PHP:

header("Strict-Transport-Security: max-age=31536000; includeSubDomains; preload");

или директно чрез htaccess файл:

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

Относно настройките, които изпращаме:

• Max-age задава срока за валидност на това указание – в случая е 1 година. Това означава, че след първоначално отваряне на вашия сайт, браузъра на клиента ще отваря вашия сайт само и единствено през https за срок от поне тази една година. Дори да премахнете хедъра и да преминете обратно към http, клиенти, които вече са отваряли вашия сайт, няма да пожелаят да отворят вашия сайт некриптиран.
• includeSubDomains указва, че инструкцията към браузъра е валидна и за всички събдомейни
• preload е функция за Chrome, която се използва и от Firefox, IE 11, Edge и други браузъри, с която администраторите на сайта могат да добавят своя домейн в база от данни за HSTS домейни, която е „хардкодната“ в самите браузъри на клиентите (получават нови домейни при обновяване на браузъра си). За да се използва тази функция, трябва да регистрирате домейна си на https://hstspreload.appspot.com. Ако го направите, вашия домейн ще бъде „вграден“ в новите версии на браузърите на клиентите и от тук насетне дори да пуснете http трафик, те няма да го използват. Това, че изпращате ключовата дума „preload“ към клиента е само указание, но не то прави защитата – реално е задължително да включите домейна си в базата от данни от споменатия линк, ако искате да използвате функцията, а изпращане на думата preload в хедърите на заявката е просто изискване на google.

Важно: Включването на HSTS има ефект върху всички клиенти, които са отваряли сайта ви, в продължение на max-age период от време. Ако сте се регистрирали с preload, ефектът е перманентен и „излизането от играта“ е трудно.

Важно 2: За да използвате preload, трябва да използвате и includeSubDomains.

2. HTTPS only от клиентката страна

Това засяга предимно не стандартните уеб браузъри, а специализиран софтуер, който пишете, като например програмите за мобилни устройства. Идеята е да не позволявате некриптиран трафик, дори от страна на клиента. Същото е възможно и чрез разширения за стандартните браузъри, като например HTTPS Everywhere или ForceTLS, но сами разбирате, че изискването е потребителите сами да го инсталират.

Освен това може да се възползвате и от „certificate pinning“. Идеята е вашето приложение да не вярва на всички възможни подписани от CA сертификати, а само и единствено на този, който вашия уебсайт използва. Това не е защита срещу SSLStrip, а по-скоро защита срещу евентуално компрометиране на certificate store на клиента – дори тогава вашето приложение ще продължи да е защитено.