Null Byte útoky

Null byte útoky na webové stránky alebo niektoré dalšie aplikácie niesu ničím novým.
Tu máme Java aplikáciu, ktorá zobrazuje obrázkový súbor určený užívateľom.
String filename = request.getParameter ( "filename");

if (filename.endsWith(".jpg")) if (filename.endsWith ( ". jpg"))
{ (
File f = new File(filename); Soubor f = new File (filename);
...
Aplikácia sa snaží zaistiť, aby funkciou boli prepustené len JPEG súbory a to kontrolou typu súboru (.jpg).Ak súbor splĺňa tieto požiadavky je odovzdaný konštruktoru java.io.File, ktorý zadaný súbor otvorí.
Rozšírená kontrola môže samozrejme prezradiť tento vstupní formulár:
secret.txt% 00.jpg
kde %oo je URL null byte kódovanie.Funkčnosť útoku sa zakladá na odlišných spôsoboch, v ktorých sú prázdne byty zvyčajne spracúvané v rodnom a riadenom kóde.V rodnom kóde je dĺžka reťazca závislá na pozícii prvého prázdneho bytu (null byte) od začiatku tohoto reťazca- nulový byt účinne skončí reťazec.V riadenom kóde objekty reťazca tvoria znakové pole, ktoré môže obsahovať prázdne byty a záznam o dĺžke reťazca.

Pri vyžšie uvedenom Java kóde String.endsWith () po našom vstupe vie, že meno súboru má 15 znakov dlhý reťazec a skontroluje posledné štyri znaky (po null byte) odpovedajú ".jpg".Avšak keď je meno súboru spracovávané pomocou java.io.File, táto operácia je napokon implementovaná medzi rodný operačný systém API, v ktorom dĺžka reťazca je určená prvým prázdnym bytom po zahájení príslušného reťazca.Teda názov spracovaného súboru nakoniec vypadá takto:
secret.txt
tým pádom je ochrana aplikácie prelomená.
Zaujímavosťou by mohlo byť, že kód v ASP.NET:
String Filename = Request.Params [ "filename"];

if (Filename.EndsWith(".jpg")) if (Filename.EndsWith ( ". jpg"))
{ (
FileStream fs = File.Open(Filename, FileMode.Open); FileStream fs = File.Open (Filename, FileMode.Open);
...
nieje zraniteľní na ten istý typ útoku.Naše zákerné vstupy by len vyvolali výnimku v podobe:
System.ArgumentException:
Znaky niesu povolené!
Pred tým, než je náš vstup odovzdaní súborovému systému API, ASP.NET, skontroluje či reťazec obsahuje akékoľvek neplatné znaky vrátane prázdných bytov, ak áno, prístup sa odoprie.Takto sa ASP.NET v tomto prípade snaží chrániť proti null byte útokom.

Null byte útoky proti LDAP

LDAP je protokol na pýtanie adresárových služieb a v rámci webových aplikácií sa najčastejšie stretávame s funkciou pre vyhľadávanie personálnych adresárov atď. Predpokladajme, že aplikácia nám umožnuje hľadať podľa názvu zamestnanca iba v marketingovom oddelení.Náš vstup je:
Matej
Žiadosť prevádza LDAP otázku s tímto filtrom:
(& (displayName = Matej) (= oddelenie marketingu))
V prípade, že LDAP filter kombinuje viacero logických podmienok, ako tu, booleovský operátor na štarte príde o zoznam podmienok a tak sa vzťahuje na všetky podmienky v tomto zozname.Preto nieje priamy logický " or 1=1" útok v SQL Injection.
Na niektorých platformách LDAP je možné dodávať dva filtre back-to-back pričom druhý filter je ignorovaný.V takejto situácii môžeme použiť následujúci zhotovení vstup k obchádzaniu zakázanej alebo obmedzenej sekcii a samozrejme zobraziť všetky položky v adresáry:
(& (displayName = *))(&( 1 = 1) (= oddelenie marketingu))
Lenže niektoré služby LDAP, obzvlášť Microsoft ADAM (Active Directory Application Mode) netolerujú otázky s dvoma filtrami.Preto ste mohli počuť, že LDAP injekcie do konjuktívnych filtrov nemôžu byť správne využité proti ADAM adresárom.

Zdroj