Web14: Bezpečnostné problémy v protokole HTTP

Tento článok predstavuje niektoré bezpečnostné problémy v protokole HTTP uvedené v dvoch dokumentoch RFC 7230 a RFC 7231. Príklady v článku o konkrétnych chybách sú uvedené v OWASP.

1. Riziká zo stredných faktorov

HTTP umožňuje použitie sprostredkovateľov na odpovedanie na požiadavky prostredníctvom série pripojení. Existujú tri bežné sprostredkovateľské prvky: proxy, brána a tunel.

Žiadosť alebo odpoveď bude musieť prejsť bodmi A, B a C. Môžu pristupovať k prenášaným citlivým informáciám, ako sú osobné informácie používateľov alebo organizácií. Nedostatočná pozornosť, ktorú sprostredkovatelia venujú bezpečnosti a súkromiu, môže viesť k širokému spektru potenciálnych útokov.

Vývojári a vývojári systému by mali počas procesu návrhu systému, kódovania a nasadenia zvážiť faktory ochrany súkromia a bezpečnosti.

Používatelia si musia byť vedomí nebezpečenstva používania nedôveryhodných serverov proxy alebo brán.

2. Rozdelenie odozvy

Rozdelenie odozvy (aka CRLF injection) je populárna technika využívania webu. Útočník posiela zakódované údaje v niektorých parametroch požiadavky, ktoré sa potom dekódujú a opakujú v určitom poli hlavičky odpovede.

Ak je týmto údajom symbol predstavujúci koniec odpovede a je iniciovaná následná odpoveď, pôvodná odpoveď bude rozdelená na dve časti a obsah druhej odpovede bude kontrolovaný útočníkom. Útočník potom môže podať ďalšiu požiadavku v rámci toho istého trvalého pripojenia a oklamať príjemcu (vrátane sprostredkovateľov), aby uveril, že táto druhá odpoveď je odpoveďou na druhú požiadavku.

3. Žiadosť o pašovanie

Pašovanie požiadaviek je technika, ktorá využíva rozdiely v spracovaní požiadaviek rôznymi typmi serverov na skrytie zdanlivo neškodných požiadaviek pripojených k pôvodnej žiadosti.

Uvažujme o nasledujúcom príklade:

Predpokladajme, že požiadavka POST obsahuje v hlavičke dve polia „Dĺžka obsahu“ s dvoma rôznymi hodnotami. Niektoré servery túto požiadavku odmietnu (IIS a Apache), iné nie. Napríklad SunONE W/S 6.1 používa pole Content-length ako prvé, zatiaľ čo sunONE Proxy 3.6 používa pole Content-length ako druhé.

Za predpokladu, že SITE je DNS servera SunONE W/S, ktorý sa nachádza za serverom SunONE Proxy, na SunONE W/S sa nachádza súbor poison.html. Tu je návod, ako využiť návrh požiadaviek HTTP na základe nezrovnalostí v spracovaní medzi dvoma servermi:

[Všimnite si, že každý riadok končí znakom CRLF (“”), okrem riadku 10]

Pozrime sa, čo sa stane, keď sa požiadavka odošle W/S cez proxy server. Najprv proxy analyzuje požiadavku z riadkov 1 až 7 (modrá) a narazí na dve polia Content-Length. Ako je uvedené vyššie, bude ignorovať prvé pole a pochopí, že telo požiadavky má dĺžku 44 bajtov. Preto s údajmi z riadkov 8 až 10 zaobchádza ako s prvým telom požiadavky (od riadkov 8 až 10 sú údaje dlhé presne 44 bajtov). Proxy potom analyzuje riadky 11 až 14 (červenou farbou) ako druhú požiadavku klienta.

Teraz sa pozrime, ako W/S interpretuje vyššie uvedené údaje, keďže sú posielané z proxy. Na rozdiel od proxy serverov W/S použije prvé pole Content-Length a interpretuje ho takto: prvá požiadavka nemá telo a druhá požiadavka začína od riadku 8 (všimnite si, že W/S bude analyzovať od riadku 11 ako hodnotu poľa Bla).

Ďalej sa pozrime, ako sa odpoveď vráti klientovi. Požiadavka, ktorej W/S rozumie, je “POST /foobar.html” (z riadku 1) a “GET /poison.html” (z riadku 8), takže klientovi pošle 2 odpovede s obsahom stránky foobar. html a jed.html. Proxy chápe, že tieto 2 odpovede zodpovedajú 2 požiadavkám: "POST /foobar.html" (z riadku 1) a "GET /page_to_poison.html" (riadok 11). Proxy uloží do vyrovnávacej pamäte obsah stránky jed.html zodpovedajúci adrese URL „page_to_poison.html“ (otrávenie pamäte cache). Odtiaľ, keď klient požaduje „page_to_poison.html“, dostane obsah stránky jed.html.

4. Útok na základe cesty k súboru

Webové servery často používajú svoj lokálny súborový systém na riadenie mapovania názvov súborov v URI na skutočné zdroje na serveri. Väčšina súborových systémov nie je navrhnutá na ochranu pred škodlivými cestami k súborom. Preto sa server musí vyhýbať prístupu k dôležitým systémovým súborom.

Napríklad UNIX, Microsoft Windows a niekoľko ďalších operačných systémov používa „..“ ako prvok cesty, ktorý predstavuje adresár o úroveň vyššie ako aktuálny súbor/adresár. Bez riadnej vstupnej kontroly a autorizácie je možné pristupovať k citlivým súborom/priečinkom systému zadaním ciest smerujúcich k týmto súborom/priečinkom.

5. Typy útokov: Command Injection, Code Injection, Query Injection

[Webové servery často používajú parametre v URI ako vstup na vykonávanie systémových príkazov a databázových dotazov. Údaje prijaté v žiadosti však nemožno vždy dôverovať. Útočník môže vytvárať a upravovať komponenty v požiadavke (ako sú metódy, polia v hlavičke, telo...), vykonávať systémové príkazy, dotazovať sa v databáze...

Napríklad SQL Injection je bežný útok, pri ktorom webový server dostane parametre v URI, ktoré sú súčasťou SQL dotazu. Preto môže útočník oklamať webový server, aby vykonal nelegálne SQL dotazy, aby ukradol alebo sabotoval databázu.
Vo všeobecnosti by sa údaje odoslané používateľmi nemali používať priamo na vykonávanie operácií na serveri. Tieto údaje musia prejsť filtrami, ktoré definujú, čo je platné a čo neplatné, čím sa eliminujú nechcené údaje.

6. Odhalenie osobných údajov

Klienti často obsahujú množstvo osobných informácií vrátane informácií poskytnutých používateľom na interakciu so serverom (ako je používateľské meno, heslo, poloha, e-mailová adresa atď.) a informácie o aktivitách pri prehliadaní webu. používateľa (história, záložky, atď.). Pri implementácii je potrebné venovať pozornosť predchádzaniu bodom, ktoré môžu odhaliť tieto súkromné ​​informácie.

7. Odhalenie citlivých informácií v URI

Identifikátory URI sú podľa návrhu určené na zdieľanie so všetkými používateľmi a nie je zaručené, že budú bezpečné. Identifikátory URI sa často zobrazujú v zdrojovom kóde webovej lokality a sú uložené v záložkách bez ochranných mechanizmov. Preto nebude bezpečné, ak URI obsahuje citlivé informácie, osobné informácie atď.

Vyhnite sa používaniu metódy GET na odosielanie osobných informácií na server, pretože sa zobrazia v URI. Namiesto toho použite metódu POST.

8. Odhalenie informácií o použitom softvéri

Polia User-Agent, Via, Server v hlavičke zvyčajne poskytujú informácie o softvéri používanom odosielateľom. Teoreticky to umožňuje útočníkom ľahšie zneužiť známe zraniteľnosti v tomto softvéri.