CRLF Injection ja HTTP Response Splitting-haavoittuvuus
mikä on CRLF?
kun selain lähettää pyynnön www-palvelimelle, WWW-palvelin vastaa vastauksella, joka sisältää sekä HTTP-vastausotsikot että varsinaisen verkkosivuston sisällön eli vastauselimen. HTTP-otsikot ja HTML-vastaus (verkkosivun sisältö) erotetaan toisistaan erityisellä erikoismerkkien yhdistelmällä, nimittäin vaunun paluulla ja viivasyötöllä. Lyhyesti ne tunnetaan myös nimellä CRLF.
WWW-palvelin käyttää CRLF: ää ymmärtääkseen, milloin Uusi HTTP-otsake alkaa ja toinen päättyy. CRLF voi myös kertoa verkkosovellukselle tai käyttäjälle, että uusi rivi alkaa tiedostosta tai tekstilohkosta. CRLF-merkit ovat standardi HTTP/1.1-viesti, joten sitä käyttävät minkä tahansa tyyppiset www-palvelimet, mukaan lukien Apache, Microsoftin IIS ja kaikki muut.
mikä on CRLF Injection-haavoittuvuus?
CRLF-injektiohaavoittuvuuden hyökkäyksessä hyökkääjä lisää sekä carriage return-että linefeed-merkit käyttäjän syötteeseen huijatakseen palvelinta, verkkosovellusta tai käyttäjää luulemaan, että objekti on lopetettu ja toinen on alkanut. Sellaisenaan CRLF-sekvenssit eivät ole haitallisia merkkejä, mutta niitä voidaan käyttää haitalliseen tarkoitukseen, HTTP-vastauksen jakamiseen jne.
CRLF-injektio verkkosovelluksissa
verkkosovelluksissa CRLF-pistoksella voi olla vakavia vaikutuksia riippuen siitä, mitä sovellus tekee yksittäisille kohteille. Vaikutukset voivat vaihdella tietojen luovuttamisesta koodin suorittamiseen, suora vaikutus web-sovelluksen tietoturvahaavoittuvuus. Itse asiassa CRLF injektio hyökkäys voi olla erittäin vakavia vaikutuksia web-sovellus, vaikka se ei koskaan listattu OWASP Top 10 lista. Esimerkiksi on myös mahdollista manipuloida lokitiedostoja admin-paneelissa, kuten alla olevassa esimerkissä on selitetty.
esimerkki CRLF-injektiosta lokitiedostossa
Kuvittele lokitiedosto admin-paneelissa, jossa on IP – ajan Vieraileman polun lähtövirtakuvio, kuten alla:
123.123.123.123 - 08:15 - /index.php?page=home
jos hyökkääjä pystyy pistämään CRLF-merkit HTTP-pyyntöön, hän pystyy muuttamaan lähtövirtaa ja väärentämään lokimerkinnät. Hän voi muuttaa webs-sovelluksen vastauksen joksikin seuraavanlaiseksi:
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
%0d ja %0A ovat CR: n ja LF: n url-koodattuja muotoja. Siksi lokimerkinnät näyttäisivät tältä sen jälkeen, kun hyökkääjä on lisännyt nämä merkit ja sovellus näyttää sen:
IP – Time – Visited Path
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
näin ollen käyttämällä CRLF-injektiohaavoittuvuutta hyökkääjä voi väärentää lokitiedostoon tehtyjä merkintöjä hämätäkseen omia haittaohjelmiaan. Hyökkääjä tekee kirjaimellisesti sivukaappauksia ja muokkaa vastausta. Kuvittele esimerkiksi tilanne, jossa hyökkääjällä on järjestelmänvalvojan salasana ja suoritetaan restrictedaction-parametri, jota voi käyttää vain järjestelmänvalvoja.
ongelmana on, että jos ylläpitäjä huomaa tuntemattoman IP: n käyttäneen restrictedaction-parametria, hän huomaa, että jokin on vialla. Kuitenkin, koska nyt näyttää siltä, että komennon antoi localhost (ja siksi luultavasti joku, jolla on pääsy palvelimelle, kuten admin) se ei näytä epäilyttävältä.
palvelin käsittelee koko kyselyosuuden, joka alkaa numerolla %0d%0A, yhtenä parametrina. Tämän jälkeen on toinen & parametrilla restrictedaction, jonka palvelin jäsentää toisena parametrina. Käytännössä tämä olisi sama kysely kuin:
/index.php?page=home&restrictedaction=edit
HTTP-vastauksen jakaminen
kuvaus
koska HTTP-vastauksen otsake ja sen vartalo on erotettu toisistaan CRLF-merkeillä, hyökkääjä voi yrittää pistää niitä. Crlfcrlf-yhdistelmä kertoo selaimelle, että otsikko päättyy ja runko alkaa. Se tarkoittaa, että hän pystyy nyt kirjoittamaan tietoja vastauskehon sisälle, johon html-koodi on tallennettu. Tämä voi johtaa Cross-site Scripting haavoittuvuus.
esimerkki HTTP – vasteen jakamisesta, joka johtaa XSS: ään
Kuvittele sovellus, joka asettaa mukautetun otsikon, esimerkiksi:
X-Your-Name: Bob
otsikon arvo asetetaan ”name” – nimisen get-parametrin kautta. Jos URL-koodausta ei ole ja arvo heijastuu suoraan otsikon sisään, hyökkääjän voi olla mahdollista lisätä edellä mainittu crlfcrlf-yhdistelmä kertomaan selaimelle, että pyynnön runko alkaa. Näin hän pystyy lisäämään tietoja, kuten XSS hyötykuorma, esimerkiksi:
?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>
yllä näkyy hälytysikkuna hyökätyn verkkotunnuksen yhteydessä.
HTTP Header Injection
Description
käyttämällä CRLF-injektiota hyökkääjä voi myös lisätä HTTP-otsikoita, joita voidaan käyttää suojausmekanismien, kuten selaimen XSS-suodattimen tai same-origin-Policyn, kukistamiseen. Näin hyökkääjä voi saada arkaluonteisia tietoja, kuten CSRF-poletteja. Hän voi myös asettaa evästeitä, joita voitaisiin käyttää hyväksi kirjautumalla uhri hyökkääjän tilille tai hyödyntämällä muuten hyödyntämättömiä cross-site scripting (XSS) – haavoittuvuuksia.
esimerkki HTTP-Otsikkoinjektiosta arkaluonteisten tietojen poimimiseksi
jos hyökkääjä pystyy pistämään HTTP-otsikoita, jotka aktivoivat Corsin (Cross Origin Resource Sharing), hän voi käyttää JavaScriptiä sellaisten resurssien käyttämiseen, jotka ovat muuten SOP: n (Same Origin Policy) suojaamia, mikä estää eri alkuperää olevia sivustoja pääsemästä toisiinsa.
CRLF-injektiohaavoittuvuuden vaikutukset
CRLF-injektioiden vaikutukset vaihtelevat ja sisältävät myös kaikki alueen rajat ylittävän Skriptauksen vaikutukset tietojen luovuttamiseen. Se voi myös deaktivoida tiettyjä tietoturvarajoituksia, kuten XSS-suodattimia ja samaa Origin-käytäntöä uhrin selaimissa, jättäen ne alttiiksi haitallisille hyökkäyksille.
miten estää CRLF/HTTP-Otsikkoinjektiot Web-sovelluksissa
paras estotekniikka on olla käyttämättä käyttäjien syötteitä suoraan vasteotsikoiden sisällä. Jos tämä ei ole mahdollista, käytä aina funktiota CRLF-erikoismerkkien koodaamiseen. Toinen hyvä web-sovelluksen tietoturva paras käytäntö on päivittää ohjelmointikielesi versioon, joka ei salli CR: n ja LF: n pistämistä HTTP-otsikoita määrittävien toimintojen sisään.
haavoittuvuuden luokitus ja Vakavuustaulukko
luokitus | id / severity |
---|---|
PCI v3.2 | 6.5.1 |
OWASP 2013 | A1 |
OWASP 2017 | A1 |
CWE | 93 |
CAPEC | 105 |
WASC | 24 |
HIPAA | 164.306(a), 164.308(a) |
ISO27001 | A.14.2.5 |
CVSS:3.0 |
CVSS:3.0: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
|
Netsparker | Medium |
Leave a Reply