Níže nabízím překlad z OWASP WSTG: Home > Stable > 4-Web Application Security Testing > 04-Authentication Testing > 4.4.1 Testing for Credentials Transported over an Encrypted Channel
Shrnutí
Testování transportu přihlašovacích údajů ověřuje, zda webové aplikace šifrují autentizační data během jejich přenosu. Toto šifrování brání útočníkům v převzetí účtů prostřednictvím odposlouchávání síťového provozu. Webové aplikace používají HTTPS k šifrování informací během přenosu jak mezi klientem a serverem, tak mezi serverem a klientem. Klient může odesílat nebo přijímat autentizační údaje během následujících interakcí:
- Klient odešle přihlašovací údaje k žádosti o přihlášení.
- Server odpoví na úspěšné přihlášení zasláním tokenu relace.
- Autentizovaný klient pošle token relace k žádosti o citlivé informace z webu.
- Klient pošle token na web, pokud zapomněl své heslo.
Nešifrování jakéhokoliv z těchto přihlašovacích údajů během přenosu může umožnit útočníkům, kteří používají nástroje pro odposlouchávání sítě, získat přístup k přihlašovacím údajům a možná je využít ke krádeži účtu uživatele. Útočník může odposlouchávat provoz přímo pomocí nástrojů jako Wireshark nebo podobných, nebo může nastavit proxy server k zachycení HTTP požadavků. Citlivá data by měla být šifrována během přenosu, aby se tomu zabránilo.
Skutečnost, že je provoz šifrován, neznamená nutně, že je zcela bezpečný. Zabezpečení také závisí na použitém šifrovacím algoritmu a síle klíčů, které aplikace používá. Viz Testování slabé transportní vrstvy (Testing for Weak Transport Layer Security), abyste ověřili, že šifrovací algoritmus je dostatečný.
Cíle testu
Ověřte, zda některý případ použití webu nebo aplikace způsobuje, že si server nebo klient vyměňují pověření bez šifrování.
Jak testovat
Pro testování transportu přihlašovacích údajů zachyťte provoz mezi klientem a serverem webové aplikace, která potřebuje přihlašovací údaje. Zkontrolujte přihlašovací údaje přenášené během přihlášení a během používání aplikace s platnou relací. Pro nastavení testu:
- Nastavte a spusťte nástroj pro zachycení provozu, jako například jeden z následujících:
- Vývojářské nástroje webového prohlížeče.
- Proxy server, včetně OWASP ZAP.
- Deaktivujte jakékoli funkce nebo pluginy, které způsobují, že prohlížeč preferuje HTTPS. Některé prohlížeče nebo rozšíření, jako například HTTPS Everywhere, budou bojovat proti vynucenému procházení přesměrováním HTTP požadavků na HTTPS.
Ve zachyceném provozu hledejte citlivá data, včetně následujících:
- Přístupové fráze nebo hesla, obvykle uvnitř těla zprávy.
- Tokeny, obvykle uvnitř cookies.
- Kódy pro resetování účtu nebo hesla.
U jakékoliv zprávy obsahující tato citlivá data ověřte, že výměna proběhla prostřednictvím HTTPS (a nikoli HTTP). Následující příklady ukazují zachycená data, která naznačují úspěšné nebo neúspěšné testy, kde webová aplikace je na serveru nazvaném www.example.org.
Přihlášení
Najděte adresu přihlašovací stránky a pokuste se přepnout protokol na HTTP. Například URL pro vynucené procházení by mohlo vypadat takto: http://www.example.org/login
.
Pokud je přihlašovací stránka normálně na HTTPS, zkuste odstranit „S“, abyste zjistili, zda se přihlašovací stránka načte jako HTTP.
Přihlaste se pomocí platného účtu a pokuste se vynutit použití nešifrovaného HTTP. V úspěšném testu by měl být přihlašovací požadavek na HTTPS:
Požadavek URL: https://www.example.org/j_acegi_security_check
Požadavek metoda: POST
…
Odpověď hlavičky:
HTTP/1.1 302 Found
Server: nginx/1.19.2
Date: Tue, 29 Sep 2020 00:59:04 GMT
Transfer-Encoding: chunked
Connection: keep-alive
X-Content-Type-Options: nosniff
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID.a7731d09=node01ai3by8hip0g71kh3ced41pmqf4.node0; Path=/; Secure; HttpOnly
ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=dXNlcmFiYzoxNjAyNTUwNzQ0NDU3OjFmNDlmYTZhOGI1YTZkYTYxNDIwYWVmNmM0OTI1OGFhODA3Y2ZmMjg4MDM3YjcwODdmN2I2NjMwOWIyMDU3NTc=; Path=/; Expires=Tue, 13-Oct-2020 00:59:04 GMT; Max-Age=1209600; Secure; HttpOnly
Location: https://www.example.org/
...
POST data:
j_username=userabc
j_password=My-Protected-Password-452
from=/
Submit=Sign in
Při přihlášení jsou přihlašovací údaje šifrovány díky HTTPS v URL požadavku.
Pokud server vrátí informace o cookies pro token relace, měl by také zahrnovat atribut Secure, aby zabránil klientovi v pozdějším vystavení cookie přes nešifrované kanály. Hledejte klíčové slovo Secure v hlavičce odpovědi.
Test selže, pokud jakékoli přihlášení přenáší přihlašovací údaje přes HTTP, podobně jako následující:
Požadavek URL: http://www.example.org/j_acegi_security_check
Požadavek metoda: POST
…
POST data:
j_username=userabc
j_password=My-Protected-Password-452
from=/
Submit=Sign in
V tomto neúspěšném příkladu testu:
- URL požadavku je
http://
a odhaluje nezabezpečené údaje j_username a j_password v POST datech.
V tomto případě, protože test již ukazuje POST data odhalující všechny přihlašovací údaje, nemá smysl kontrolovat odpovědní hlavičky (které by také pravděpodobně odhalily token relace nebo cookie).
Vytvoření účtu
Pro testování nešifrovaného vytváření účtu zkuste vynucené procházení na HTTP verzi stránky pro vytvoření účtu a vytvořte účet, například: http://www.example.org/securityRealm/createAccount
.
Test je úspěšný, pokud i po vynuceném procházení klient stále posílá novou žádost o vytvoření účtu přes HTTPS:
Požadavek URL: https://www.example.org/securityRealm/createAccount
Požadavek metoda: POST
…
Odpověď hlavičky:
HTTP/1.1 200 OK
Server: nginx/1.19.2
Date: Tue, 29 Sep 2020 01:11:50 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 3139
Connection: keep-alive
X-Content-Type-Options: nosniff
Set-Cookie: JSESSIONID.a7731d09=node011yew1ltrsh1x1k3m6g6b44tip8.node0; Path=/; Secure; HttpOnly
Expires: 0
Cache-Control: no-cache,no-store,must-revalidate
...
POST data:
username=user456
fullname=User 456
password1=My-Protected-Password-808
password2=My-Protected-Password-808
Submit=Create account
Podobně jako u přihlášení většina webových aplikací automaticky poskytne token relace po úspěšném vytvoření účtu. Pokud existuje Set-Cookie:
, ověřte, že má také atribut Secure.
Test selže, pokud klient pošle novou žádost o vytvoření účtu přes nešifrované HTTP:
Požadavek URL: http://www.example.org/securityRealm/createAccount
Požadavek metoda: POST
…
POST data:
username=user456
fullname=User 456
password1=My-Protected-Password-808
password2=My-Protected-Password-808
Submit=Create account
Tento formulář pro vytvoření uživatele v Jenkinsu odhalil všechny detaily nového uživatele (jméno, celé jméno a heslo) v POST datech na HTTP stránku pro vytvoření účtu.
Obnovení hesla, změna hesla nebo jiná manipulace s účtem
Podobně jako u přihlášení a vytváření účtu, pokud má webová aplikace funkce, které uživateli umožňují změnit účet nebo volat jinou službu s přihlašovacími údaji, ověřte, že všechny tyto interakce probíhají přes HTTPS. Interakce, které je třeba testovat, zahrnují:
- Formuláře, které umožňují uživatelům obnovit zapomenuté heslo nebo jiné přihlašovací údaje.
- Formuláře, které umožňují uživatelům upravit přihlašovací údaje.
- Formuláře, které vyžadují, aby se uživatel autentizoval s jiným poskytovatelem (například při zpracování plateb).
Přístup k zdrojům po přihlášení
Po přihlášení přistupujte ke všem funkcím aplikace, včetně veřejných funkcí, které nemusí vyžadovat přihlášení k přístupu. Pokuste se vynucené procházení na HTTP verzi webu, abyste zjistili, zda klient odhaluje přihlašovací údaje.
Test je úspěšný, pokud všechny interakce posílají token relace přes HTTPS, například v následujícím příkladu:
Požadavek URL: http://www.example.org/
Požadavek metoda: GET
…
Požadavek hlavičky:
GET / HTTP/1.1
Host: www.example.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
Cookie: JSESSIONID.a7731d09=node01ai3by8hip0g71kh3ced41pmqf4.node0; ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=dXNlcmFiYzoxNjAyNTUwNzQ0NDU3OjFmNDlmYTZhOGI1YTZkYTYxNDIwYWVmNmM0OTI1OGFhODA3Y2ZmMjg4MDM3YjcwODdmN2I2NjMwOWIyMDU3NTc=; screenResolution=1920x1200
Upgrade-Insecure-Requests: 1
Token relace v cookies je šifrován, protože požadavek URL je HTTPS.
Test selže, pokud prohlížeč odešle token relace přes HTTP v jakékoliv části webu, i když je nutné vynucené procházení k vyvolání tohoto případu:
Požadavek URL: http://www.example.org/
Požadavek metoda: GET
…
Požadavek hlavičky:
GET / HTTP/1.1
Host: www.example.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: language=en; welcomebanner_status=dismiss; cookieconsent_status=dismiss; screenResolution=1920x1200; JSESSIONID.c1e7b45b=node01warjbpki6icgxkn0arjbivo84.node0
Upgrade-Insecure-Requests: 1
GET požadavek odhalil token relace JSESSIONID (z prohlížeče na server) v požadavku URL http://www.example.org/
.
Náprava
Používejte HTTPS pro celý web. Implementujte HSTS a přesměrujte všechny HTTP požadavky na HTTPS. Web získá následující výhody z používání HTTPS pro všechny své funkce:
- Zabrání útočníkům v modifikaci interakcí s webovým serverem (včetně vkládání JavaScriptového malwaru prostřednictvím kompromitovaného routeru).
- Zabrání ztrátě zákazníků kvůli varováním o nezabezpečeném webu. Nové prohlížeče označují weby založené na HTTP jako nezabezpečené.
- Umožňuje snadnější psaní určitých aplikací. Například Android API potřebují přepsání pro připojení k čemukoliv přes HTTP.
Pokud je obtížné přepnout na HTTPS, upřednostněte HTTPS pro citlivé operace. Pro střednědobý horizont naplánujte převod celé aplikace na HTTPS, aby nedocházelo ke ztrátě zákazníků v důsledku kompromitace nebo varování, že HTTP je nezabezpečené. Pokud organizace dosud nenakupuje certifikáty pro HTTPS, zvažte použití Let’s Encrypt nebo jiných bezplatných certifikačních autorit na serveru.