HTTP Request Salakuljetushyökkäys, sen välttäminen ja vaarat

Kun käyttäjät selaavat Internetiä ja suorittavat erilaisia ​​tehtäviä, olemme alttiina hyökkäyksille. Kyberrikolliset etsivät haavoittuvuuksia ja puutteita käyttöjärjestelmistämme hyötyäkseen. Siksi päivitetty käyttöjärjestelmä ja hyvä virustentorjunta on aina hyvä lähtökohta puolustautumisemme perustalle. Internetin käyttäjät eivät kuitenkaan ole ainoa kyberrikollisten kohde. He tekevät myös hyökkäyksiä verkkopalvelimeen, a palomuuri, välityspalvelin ja paljon muuta. Tänään puhumme eräänlaisesta hyökkäyksestä, joka vaikuttaa jälkimmäiseen. Tässä opetusohjelmassa aiomme puhua mistä HTTP-pyynnön salakuljetus on ja selitämme myös, miksi se on niin vaarallista.

HTTP-pyynnön salakuljetushyökkäys

Mitä tämä hyökkäys tekee ja sen vaarat

We voi määrittää HTTP Request Smuggling -hyökkäyksen sellaisena, joka hyödyntää analyysin eroavaisuuksia, kun yksi tai useampi HTTP-laite/entiteetti on käyttäjän ja verkkopalvelimen välisessä tietovirrassa. Olemme törmänneet tekniikkaan, joka häiritsee tapaa, jolla verkkosivusto käsittelee HTTP-pyyntövirtoja, jotka vastaanotetaan yhdeltä tai useammalta käyttäjältä.

Nämä haavoittuvuudet ovat usein luonteeltaan kriittisiä, jolloin kyberrikolliset voivat ohittaa turvatarkastukset, saada luvattoman pääsyn yksityisiin tietoihin ja jopa vaarantaa sovelluksen muut käyttäjät suoraan. Tämä laiton HTTP-pyyntöjen liikenne mahdollistaa erilaisia ​​hyökkäyksiä, kuten välimuistin myrkytyksiä, istuntojen kaappauksia ja myös kykyä ohittaa verkkosovellusten palomuurisuojaus.

Tämä HTTP Request Smuggling -hyökkäys voi vaikuttaa erilaisiin tietokoneisiin ja palveluihin:

  • Web-palvelin.
  • Palomuuri.
  • Välityspalvelin.

Mitä tulee alkuperään, se juontaa juurensa vuoteen 2005, jolloin ryhmä Watchfiren tutkijoita, mukaan lukien Klein, Ronen Heled, Chaim Linhart ja Steve Orrin, osoitti tämän hyökkäyksen. Viime vuosina on kuitenkin tehty useita parannuksia, jotka laajentavat hyökkäyspinta-alaa ja mahdollistavat maksimaalisen pääsyn sisäisiin API-liittymiin ja välimuistin myrkytyksen.

Kuinka tämä hyökkäys tapahtuu

Verkkosovellukset käyttävät nykyään usein HTTP-palvelinmerkkijonoja käyttäjien ja lopullisen sovelluslogiikan välillä. Tällä tavalla käyttäjät lähettävät pyynnöt etupalvelimelle, ja sitten etupääpalvelin lähettää pyynnöt yhdelle tai useammalle taustapalvelimelle. On huomattava, että tämä arkkitehtuuri on yleistymässä ja joissain tapauksissa väistämätön, kuten pilvipohjaisissa sovelluksissa.

Kun etupalvelin lähettää HTTP-pyynnöt edelleen taustapalvelimelle, se lähettää yleensä useita pyyntöjä saman taustaverkkoyhteyden kautta. Tämä tehdään, koska se on tehokkaampi ja tarjoaa paremman suorituskyvyn. Toimintatapa on yksinkertainen, ensin lähetetään HTTP-pyynnöt peräkkäin. Vastaanottava palvelin jäsentää sitten kunkin HTTP-pyynnön otsikot määrittääkseen, mihin yksi pyyntö päättyy ja milloin seuraava alkaa.

Erittäin tärkeä näkökohta on, että etu- ja taustajärjestelmät täytyy sopia pyyntöjen rajoista . Tämä on olennaista, koska muutoin kyberrikollinen voisi lähettää moniselitteisen pyynnön etu- ja taustajärjestelmille ja he voivat ymmärtää sen eri tavalla.

Tässä hyökkääjä saa taustapalvelimen tulkitsemaan osan käyttöliittymäpyynnöstään seuraavan pyynnön alkajaksi. Sitten tapahtuu, että se edeltää seuraavaa pyyntöä, mikä aiheuttaa häiriöitä tapaan, jolla sovellus käsittelee pyynnön. Kohtaamme HTTP Request Smuggling -hyökkäyksen, ja sillä voi olla tuhoisia seurauksia kyseisen palvelimen omistajalle.

Miksi nämä hyökkäykset tapahtuvat

Suuri osa HTTP-pyyntöjen salakuljetuksen haavoittuvuuksista ilmenee, koska HTTP-määritykset tarjoavat kaksi eri tapaa määrittää, mihin pyyntö päättyy. Otsikko on yksinkertainen, se määrittää viestin rungon pituuden tavuina. Tätä voidaan käyttää osoittamaan, että viestin runko käyttää osakoodausta. Tämä tarkoittaa, että viestin runko sisältää yhden tai useamman datan. Jotkut suojausjärjestelmänvalvojat eivät tiedä, että HTTP-pyynnöissä voidaan käyttää lohkosalausta, mikä on ongelma.

Jos et tiedä, HTTP tarjoaa kaksi eri menetelmää HTTP-viestien pituuden määrittämiseen. On myös huomattava, että yksi viesti voi käyttää molempia menetelmiä samanaikaisesti, jolloin ne olisivat ristiriidassa keskenään. HTTP-protokolla yrittää ratkaista tämän ongelman ilmoittamalla, että jos sekä Content-Length- että Transfer-Encoding-otsikot ovat olemassa, Content-Length-otsikkoa ei tule käyttää. Tämä kaava saattaa riittää välttämään epäselvyyksiä, kun meillä on vain yksi aktiivinen palvelin, mutta ei, kun meillä on kaksi tai useampia ketjutettuja palvelimia.

Siksi, jos etu- ja taustapalvelimet käyttäytyvät eri tavalla Transfer-Encoding-tyyppiseen otsikkoon nähden, joka on mahdollisesti hämärtynyt, ne saattavat olla eri mieltä peräkkäisten pyyntöjen välisistä rajoista. Tämä voi johtaa haavoittuvuuksiin ja HTTP Request Smuggling -hyökkäykseen.

Kuinka estää tämä vaarallinen hyökkäys

HTTP-pyyntöjen salakuljetushyökkäykset sisältävät sekä Content-Length- että Transfer-Encoding-otsikon sijoittamisen samaan HTTP-pyyntöön ja niiden käsittelemisen siten, että etu- ja taustapalvelimet käsittelevät pyynnön eri tavalla.

Klein, jonka mainitsimme aiemmin, kehottaa normalisoimaan välityspalvelimista lähtevät HTTP-pyynnöt ja korostaa tarvetta kestävälle ja avoimen lähdekoodin verkkosovellusten palomuuriratkaisulle, joka pystyy käsittelemään tämäntyyppisiä hyökkäyksiä. Tämän ongelman ratkaisemiseksi Klein on julkaissut C ++ -pohjaisen projektin, joka varmistaa, että kaikki saapuvat HTTP-pyynnöt ovat täysin kelvollisia, yhteensopivia ja yksiselitteisiä. Tämä teos on julkaistu GitHubissa ja voit tarkistaa sen tätä .

Toisaalta joitain muita asioita, joita voisimme tehdä välttääksemme HTTP Request Smuggling -hyökkäyksen, ovat seuraavat:

  • Poista taustayhteyksien uudelleenkäyttö käytöstä, jotta jokainen taustapyyntö lähetetään erillisen verkkoyhteyden kautta.
  • Käytä HTTP / 2 -protokollaa taustayhteyksiin, koska tämä protokolla välttää epäselvyyden pyyntöjen välisissä rajoissa.
  • Täsmälleen samaa ja identtistä verkkopalvelinohjelmistoa tulee käyttää etu- ja taustapalvelimissa. Tämä varmistaa, että he sopivat pyyntöjen välisistä rajoista.

Kuten olet nähnyt, HTTP Request Smuggling -hyökkäys on erittäin tärkeä vakavuutensa vuoksi, se on melko vaarallinen, mutta meillä on erilaisia ​​​​tapoja estää tämä hyökkäys ja lieventää sitä oikein.