Kontrola bezpečnosti serveru Na volné noze
Školení, která pořádám 
Provozovatel serveru Na volné noze mě požádal o provedení bezpečnostní kontroly jeho serveru. Pro provedení testu jsem neměl k dispozici zdrojové kódy aplikace ani konfiguraci serveru ale jen veřejné rozhraní serveru a administrační rozhraní pro běžné uživatele. K testu jsem nevyužil žádné automatizační nástroje, ale udělal jsem ho ručně a zaměřil jsem se na místa, ve kterých se nejčastěji chybuje. Nyní k výsledkům testu:
- OK Vyhledávání
- Znaky se zvláštním významem v HTML se ve vstupním políčku ošetří a v titulku stránky odstraní. Stránka tedy není náchylná ke XSS. Jedinou výtku mám ke znaku apostrof, který se v titulku zobrazí jako
'. Formulář podle všeho není náchylný ani k SQL Injection. - OK Adresy stránek
- Adresy stránek nejeví známky toho, že by se manipulací s nimi dala aplikace přesvědčit k vložení nedůvěryhodného souboru.
- OK Prezentace
- Text prezentace zadává přímo správce serveru, takže přestože obsahuje bohaté formátování, neměla by hrozit žádná rizika. E-mailová adresa je do stránky vypsaná pomocí entit, což je dostatečná obrana proti primitivní e-mailovým harvesterům.
- OK Odběr novinek
- Tvar e-mailové adresy se kontroluje (stejně jako u ostatních formulářů, které s e-mailem pracují). Přihlášení k odběru nevyžaduje potvrzení, ale uživatel dostane zprávu, pomocí které se může ihned odhlásit. Odhlášení je dvoukrokové – první krok si vyžádá potvrzení uživatele, což mu odešle zprávu obsahující odkaz na druhý krok, který je chráněn tokenem. Jak mi provozovatel objasnil, je to tak proto, aby se běžné zprávy daly přeposílat bez obavy, že by příjemce mohl původního odběratele odhlásit.
- OK Identita uživatele
- Identita uživatele se udržuje pomocí session identifikátoru přenášeného v cookie s příznakem
HttpOnly. Tento identifikátor se mění při každém požadavku, což je víc než dostatečná obrana proti útoku Session Fixation. Kromě session identifikátoru se ověřuje také hlavičkaUser-Agenta nejspíš i další údaje, což minimalizuje riziko útoku Session Hijacking. Trvalé přihlášení se ukládá do zašifrované cookie, která zdá se obsahuje přímo identitu uživatele. Osobně bych se klonil spíše k použití náhodného identifikátoru, který by byl s uživatelem spárován na straně serveru. - OK Přihlášení
- Pro přihlášení je vyžadováno zadání ID, které si asi běžný uživatel nebude pamatovat. Klonil bych se k povolení e-mailu nebo veřejného identifikátoru.
- OK Heslo
- Server uživatelům generuje bezpečná hesla, která jim odesílá e-mailem. Tato hesla jsou prakticky nezapamatovatelná, takže to nutí uživatele si heslo někam uložit (buď si ho nechat v doručené poště, což není právě bezpečné, nebo použít software pro ukládání hesel). Osobně bych se klonil k možnosti dát uživatelům možnost nastavit si vlastní heslo, samozřejmě s ověřením jeho síly.
- OK Zapomenuté heslo
- Na serveru se ukládá nejspíš jen otisk hesla, protože jeho zapomenutí způsobí vygenerování nového hesla. Odeslaný e-mail s tímto heslem obsahuje odkaz, pomocí kterého lze nové heslo aktivovat – když to uživatel neudělá, tak zůstane platit staré heslo. Doporučil bych ještě přidání odkazu pro deaktivaci nového hesla pro případ, že zapomenutí hesla deklaroval útočník, který má možnost odposlechu e-mailů uživatele (e-mail se posílá nešifrovaně). Tím by se alespoň zkrátil čas, který má útočník k dispozici na získání nového hesla.
- OK HTTPS
- Velmi kladně hodnotím, že celá administrace používá protokol HTTPS s důvěryhodným certifikátem. Velké servery někdy používají protokol HTTPS jen pro přihlášení, protože šifrování je náročné na výkon, ale to je polovičaté řešení. Veřejná část prezentace používá vždy protokol HTTP, což není úplně ideální, protože některé části prezentace obsahují citlivé informace jako třeba číslo účtu, které uživatel potřebuje získat důvěryhodným způsobem (v tomto případě není podstatné šifrování, ale potvrzení identity serveru).
- OK Administrační formuláře
- Stránky si v URL přenáší ID uživatele, kterého se změna týká. Toto ID se ale kontroluje jak při zobrazení formuláře, tak při jeho odeslání, takže se uživatel nemůže vydávat za někoho jiného. ID se v URL přenáší kvůli superuživatelům, kteří mají právo manipulovat s cizími účty.
- chyba Administrační formuláře
- Formuláře nejsou zabezpečeny proti CSRF. Formuláře sice obsahují skryté formulářové pole
checksum, to je ale jen otisk původní verze dat, který slouží k zabránění přepisu dat. S přihlédnutím k tomu, že server umožňuje trvalé přihlášení a existují superuživatelé, tak se jedná o velmi vážnou hrozbu. - OK Přidání obrázku
- Typ souboru se určuje podle koncovky, nikoliv podle typu deklarovaného klientem nebo podle obsahu souboru. Stejnou logiku používá i webový server, který soubor následně odesílá.
- chyba Galerie
- Název obrázku se na dvou místech vypisuje ošetřený proti XSS, ale na jednom místě nikoliv. To svědčí o tom, že výstupní ošetření dat není prováděno automaticky a bylo by dobré zkontrolovat všechny výstupy nebo přejít na automatické ošetřování.
- OK Smazání galerie
- Pro potvrzení smazání galerie a některé další operace se používá běžný odkaz, což má několik nepříjemných důsledků – odkaz se může dostat do výsledků vyhledávání a uživatel si ho může omylem vložit do oblíbených položek, po provedení operace se navíc stránka nepřesměruje, takže její obnovení provede operaci znovu. Vzhledem k použití parametrů
vyprsiaoverenise tyto negativní důsledky prakticky neutralizují, i tak bych ale doporučil pro provádění operací používat zásadně metodu POST. - OK Doklady
- Doklady ve formátu PDF se stahují z adresy, která obsahuje pravděpodobně náhodný identifikátor. Přestože tedy stažení dokladu nevyžaduje přihlášení uživatele, je stažení dokladu bezpečné (za předpokladu, že URL dokladu neunikne). Osobně bych se klonil spíše k povolení stažení dokladu jen přihlášeným uživatelům.
- OK Hosting
- Server zdá se není provozován na sdíleném hostingu, takže by útočník neměl mít šanci získat na stejném stroji účet.
Tuto zprávu zveřejňuji se souhlasem provozovatele serveru a poté, co byly opraveny nalezené chyby. Pokud máte zájem o provedení podobné kontroly na svém serveru, tak mne prosím kontaktujte. Test jsem prováděl v omezeném čase a pokud jsem někde zjistil správné ošetření některé chyby, tak jsem se na ni už dále nezaměřoval. Důslednější kontrola by vyžadovala buď více času nebo použití automatizačního nástroje.
Přijďte si o tomto tématu popovídat na školení Bezpečnost PHP aplikací.
Diskuse
Jan Pejša:
Chtěl bych se zeptat, jestli při kontrole bezpečnosti vycházíte z nějakého "Testing Guide" (mám na mysli například OWASP Testing Guide) a pokud ano, tak z jakého.
Jan Pejša: Naith:
Dobrý den, za jakých podmínek provádíte test bezpečnosti? Děkuji.
Jakub Vrána 
:
Záleží to na velikosti serveru a množství chyb. Test zhruba v tomto rozsahu bych mohl nabídnout za 2000 Kč.
Jakub Vrána : Naith:
Děkuji za informaci.Hologos:
Měl byste si to přejmenoval na Adminer :)Citace z vašeho profilu na portálu NaVolneNoze.cz:
"Řada vlastních aktivit a projektů jako MySMS, Matfyz.cz či phpMinAdmin nominovaný na nejlepší nový projekt v anketě prestižního serveru SourceForge.net"
Robert Vlach:
Díky za report, opravil jsem to :-)
Martin Kravec:
Mimochodom, su niekde na nete vypisane rychlosti PHP funkcii alebo ako by som to zistil ? Zalezi rychlost funkcie od serveru ?
pojízdná kočka:
Smím se zeptat, jaké jsou zvyklosti implementace dočasného hesla (bez zneplatnění toho starého)?Já to jednou dělala a vyřešila jsem to tak, že jsem do tabulky uživatelů přidala (kromě jména, hesla, ...) i dočasné heslo a datum, kdy skončí jeho platnost.
Při požadavku pro poslání nového hesla jsem vygenerovala náhodné heslo, uložila ho do patřičného políčka u záznamu uživatele (kterého jsem nalezla podle zadaného uživatelského jména) a jako čas vypršení jsem nastavila NOW() + INTERVAL 30 MINUTE.
Zpracování přihlášení pak pochopitelně zohlednil i kontrolu dočasného hesla (a toho, zda-li je ještě aktuální).
-----
1) co by se tomuto řešení dalo vytknout?
2) jaké jsou možnosti zaslání hesla, když někdo odposlouchává odesílaný mail? (popř. jak/pomocí čeho se dá mail poslat šifrovaně a jaké jsou vůbec šance zapomnětlivého uživatele versus útočníka dostat se k nově vygenerovanému heslu s použitím různých takových způsobů…)
Jakub Vrána :
Já to dělám stejně, jen platnost tokenu (v tvé terminologii dočasné heslo) nastavuji na 1 den, protože třeba tvých 30 minut může být např. kvůli greylistingu nedostatečných.
Součástí e-mailu by měl být i odkaz pro zrušení žádosti – pro případ, že o heslo požádal útočník, nebo si na něj uživatel mezitím vzpomněl.
Když je ta možnost, tak lze token poslat i SMS, což je obvykle bezpečnější. SMS lze poslat i pomocí placené webové služby s HTTPS rozhraním.
Šifrovat e-maily je bohužel problematické, protože by nám uživatel musel dát svůj certifikát. Žádné jejich centrální úložiště neexistuje, ale pro GPG se dá použít např. http://www.gpg.cz/.
Jakub Vrána : Petr Konůpek:
Docela mě zaujala ta myšlenka s deaktivací hesla. Přiznávám se, že jsem to zatím ještě nikde neviděl.
Zato je docela dobrá věc, když aktivační stránka nějakým rozumným způsobem odkazuje na změnu hesla, protože sposta návštěvníků pak často zbytečně pátrá, kde si ho mohou změnit...
Dále bych pak asi kontroloval i nějakou bezpečnost hesel. Dobrá jsou taková ta JavaScriptová udělátka, co Vám říkají, zda-li je vaše heslo bezpečně (či nebezpečné :))
Jakub Vrána :
Já uživatelům zapomenuté heslo negeneruji. Vygeneruji jen token, pomocí kterého si ho můžou sami nastavit.
Jakub Vrána : Petr Konůpek:
A nebo tak :D
Emkei:
pristup do administrace nemam, pouze do verejne casti prezentace, presto tech nedostatku vzhledavam vice. lze odhalit stromova struktura serveru (/home/www/navolnenoze.cz/public_html/www/), ktera naopak naznacuje, ze se na nem nachazi vice webu. navic, pokud ti kontrola uploadu obrazku zalozena na suffixu souboru prijde v poradku, tak jsi blazen, nebot neni aktivovana direktiva magic_quotes_gpc a lze tak v komunikaci se serverem pouzivat null byte (dalsi nedostatek). docela by me zajimalo, jake chyby jsi neodhalil v samotne administraci, kazdopadne pokud jsi jim ten audit delal zdarma, tak to chapu...
Emkei: Jakub Vrána :
Myslel jsem, že význam koncovky souboru už jsi pochopil. Trpělivě jsem ti to vysvětloval už před rokem: http://www.lupa.cz/clanky/nebezpecne-webhosting…/234534/vlakno/.
PHP při použití nulového bajtu například v původním názvu poslaného souboru udělá to, že část za nulovým bajtem ořízne. To ničemu nevadí a s magic_quotes_gpc to nijak nesouvisí.
Vyvaruj se prosím urážení mě i dalších účastníků diskuse účastníků diskuse výrazy jako „blázen“. Když něco nechápeš, tak to ještě neznamená, že jsou lidé v tvém okolí blázni.
Jakub Vrána : Emkei:
sam jsi v reportu napsal, ze se soubor NEidentifikuje na zaklade jeho obsahu, nybrz pouze koncovky, tudiz je tebou zmineny thread naprosto irelevantni a na serveru se jedna o chybu, kdy ma utocnik moznost za asistence nulloveho bytu uploadovat na server soubor s libovolnou priponou a obsahem (dpoln si vzdelani - google.com: upload null byte).
direktiva magic_quotes_gpc nijak nesouvisi s null bytem v nazvu uploadovaneho souboru? to si ze me delas legraci, ze? kdyz uz jsi tu tak krasne vysvetlil, jak pracuje null byte, tak si zjisti, co s nim pri uploadu udela tato direktiva. ...pry nijak nesouvisi, to me podrz, ja se te tve prednasky o bezpecnosti vazne snad nekdy budu muset zucastnit, at si zlepsim naladu :)))
tebe, a uz vubec nikoho jineho v teto diskuzi, jsem nijak neurazil, tak cti, co pisu a nevymyslej si vlastni hloupe teorie...
Emkei: Jakub Vrána :
Jak podle vnějšího projevu nejspíš funguje upload obrázku na serveru Na volné noze:
1. Koncovka původního názvu souboru se porovná s whitelistem.
2. Pokud je tato koncovka ve whitelistu, tak se obrázek nahraje pod ID obrázku s touto připojenou koncovkou.
3. Obrázky následně servíruje webový server, který způsob jejich zpracování určuje opět podle koncovky.
Nulový bajt ani magic_quotes_gpc s tím nemá co do činění, protože koncovka porovnaná v kroku 1 se použije v kroku 2 a 3. Zkoumání souboru podle obsahu nebo deklarovaného MIME typu by naproti tomu bylo k ničemu, protože bod 3 se rozhoduje čistě podle koncovky.
Na školení jsi samozřejmě srdečně zván. Podle tvého vystupování to vypadá, že máš načtené nějaké útoky, ale nerozumíš jejich principu. Školení se zaměřuje na jejich praktickou prezentaci, takže by ti opravdu mohlo prospět.
A znovu říkám – vyvaruj se jakýchkoliv invektiv, v posledním příspěvku konkrétně „doplň si vzdělání“. Tohle je diskuse pro slušné lidi.
Jakub Vrána : Emkei:
to jsi ale v reportu neuvedl, tam jsi pouze napsal, cituji "Typ souboru se určuje podle koncovky, nikoliv podle typu deklarovaného klientem nebo podle obsahu souboru", coz povazujes za OK, jenze kdyby to tak opravdu bylo, jednalo by se o vaznou bezpecnostni chybu ... a pak se divis, ze te lide, co se penetracnimi testy zabyvaji, povazuji za šaška.
nekdy se na tvem skoleni ukazu a udelam ti PR clanek. principum utoku rozumim velice dobre a ver mi, ze bys me NICEMU novemu nenaucil. delat serveru navolnenoze.cz bezpecnostni audit ja, urcite by pouze u jednoho XSS a CSRF nezustalo :)
zadna invektiva ve svych prispevcich nevidim, zminena veta byla pouhe doporuceni, tak nebud tak stahovacny...
Emkei: Jakub Vrána :
Ale on se typ souboru skutečně určuje podle koncovky. Diskusní příspěvek není v rozporu s článkem, pouze ho rozebírá více do hloubky. Možná sis myslel, že se koncovka porovnává jinak než jak se pak používá, ale po pravdě řečeno by to ani nijak snadno nešlo, protože PHP zbytek názvu souboru za nulovým bajtem ořezává. A dělá to už přes sedm let: http://svn.php.net/viewvc/php/php-src/trunk/…=log#rev65287
Jakub Vrána : Emkei:
tak ted uz vazne nevim, jestli me provokujes, nebo si jen nerozumime :) pokud by ten upload byl napsany pouze tak, jak jsi uvedl v reportu, pak by jej bylo mozne zneuzit za pomoci null byte k uploadu cehokoliv, nejen obrazku, viz hned prvni link na googlu http://www.google.cz/search?hl=cs&q=upload+…&aq=f&oq= nebo si to proste zkus...
Emkei: 
v6ak:
To, co popsal v komentáři, je OK, že? A co popsal ve článku OK není, že?
Z toho logicky vyplývá, že tyto dvě informace musí být v rozporu.
Já ovšem ten rozpor nemůžu najít. Která dvě tvrzení si odporují?
v6ak: Emkei:
v rozporu to neni, doplnuje se to, ale je to stejne absurdni, jako kdybys do reportu napsal, ze povazujes za OK pritomnost citlivych firemnich dokumentu na webovem serveru. pak by ti nekdo oponoval, ze to v poradku rozhodne neni a ty bys v komentari doplnil, ze jsi se zapomnel zminit o tom, ze ty dokumenty jsou sifrovane.
Emkei: Jakub Vrána :
Víš co, přestaň teoretizovat a napiš, jak by měl vypadat kód, který by splňoval požadavek „Typ souboru se určuje podle koncovky“ a byl zranitelný. K tomu uveď, jaký požadavek by se mu měl poslat. Aby bylo jasné, co mám na mysli, tak uvedu dvě ukázky kontroly podle MIME typu a podle obsahu:
<?php
if ($_FILES["obrazek"]["type"] == "image/jpeg") {
move_uploaded_file($_FILES["obrazek"]["tmp_name"], "data/" . $_FILES["obrazek"]["name"]);
}
?>
K provedení útoku si uživatel ve svém prohlížeči nastaví MIME typ image/jpeg např. pro koncovku .php a pošle soubor s touto koncovkou.
<?php
if (getimagesize($_FILES["obrazek"]["tmp_name"])) {
move_uploaded_file($_FILES["obrazek"]["tmp_name"], "data/" . $_FILES["obrazek"]["name"]);
}
?>
K provedení útoku uživatel pošle PHP skript s koncovkou .php, který začíná třeba textem GIF123.
Jakub Vrána : Emkei:
tvoje lenost je neuveritelna, proc jsi nenavstivil google, jak jsem te nabadal? nasledujici script by mel vpustit na server pouze soubory s priponou .jpg, diky null byte tomu tak vsak neni a utocnik muze nahrat soubor s libovolnou priponou:
<?php
if (strtolower(substr($HTTP_POST_FILES['obrazek']['name'], -4, 4)) == ".jpg") {
$path= "upload/".urldecode($HTTP_POST_FILES['obrazek']['name']);
if($ufile != none) {
if(move_uploaded_file($HTTP_POST_FILES['obrazek']['tmp_name'], $path))
echo "Obrazek byl uspesne nahran na server";
else
echo "Obrazek se nepodarilo nahrat na server";
}
} else
echo "Neplatny format obrazku";
?>
utocnikovi nyni staci nahrat napr. soubor hack.php%00.jpg a hadej, co se ulozi do slozky upload? soubor s nazvem hack.php! mam ti jeste vytvorit video-navod, nebo ti to uz konecne dojde? chtel bych videt hlupaky, co ti za to tvoje bezpecnostni skoleni plati bezmala 5 000,- Kc. venuj se dal php a neprodavej lidem falesny pocit bezpeci v podobe amaterskych bezpecnostnich auditu...
Emkei: Jakub Vrána :
A teď ještě čtenářům objasni, proč by skript měl volat <?php urldecode($HTTP_POST_FILES['obrazek']['name']) ?> a jak tě napadlo, že to dělá server Na volné noze. A jak sis to spojil s výrokem „Typ souboru se určuje podle koncovky“ použitým v článku.
Je to asi stejný nesmysl jako kdybys tady uvedl skript, který nejprve ověří koncovku a potom z názvu souboru vezme jen prvních 12 znaků.
Jakub Vrána : Emkei:
protoze i s tim se v praxi setkas, viz google. skutecnost, ze ty osobne utok na file upload pomoci null byte neznas, jeste neznamena, ze neexistuje, staci se podivat kolem sebe prostrednictvim jakehokoliv fulltextoveho vyhledavace: upload null byte.
ja nikde netvrdil, ze to tak dela upload na serveru navolnenoze.cz. napsal jsem, ze to tak dela upload, ktery jsi popsal ve svem reportu.
a jak jsem si to spojil s vyrokem "Typ souboru se určuje podle koncovky"? protoze jednoduse podminka if uvedena v mem kodu dela presne to, co zminena veta popisuje, veri koncovce souboru, co na tom nechapes?
s tim tvym "nesmyslem", jak onomu utoku rikas, se potyka nemale mnozstvi lidi, tak se pres vsechnu svoji aroganci zkus jednou podivat kolem sebe...
Emkei: Jakub Vrána :
Podívej se na svůj skript pořádně. Kdyby podmínka v prvním řádku kódu kontrolovala třeba obsah souboru, zabránilo by to nějak útoku? Ne. Problém totiž není v podmínce, ale v tom, co jí následuje, konkrétně v chybném použití funkce urldecode().
Je na tom vidět, že sis zcela mylně odvodil, že kontrola podle koncovky souboru znamená náchylnost k útoku s nulovým bajtem a že tedy problému nerozumíš.
Manipuluješ s tím, že když napíšu „Typ souboru se určuje podle koncovky“, tak to znamená „název souboru se následně poškodí, takže je kontrola neúčinná“. To je očividný nesmysl.
Jakub Vrána : Emkei:
co to placas za nesmysly? samozrejme, ze kdyby se kontroloval obsah souboru, tak by to utoku zabranilo. rozsir uvedeny kod o nasledujici radek a sam se muzes presvedcit:
if (!getimagesize($HTTP_POST_FILES['obrazek']['tmp_name'])) die("Neplatny format obrazku");
ten, kdo danemu utoku nerozumi, jsi tady ocividne ty, a nejen utoku...
s nicim nemanipuluji, chces snad rici, ze podminka
if ($priponaSouboru == ".jpg") { ...
neurcuje typ souboru podle koncovky a neodpovida tak tvrzeni "Typ souboru se určuje podle koncovky"? to preci vidi i hlupak, nechapu, proc ty ne...
Emkei: Jakub Vrána :
Přečti si znovu http://php.vrana.cz/kontrola-bezpecnosti-….php#d-8858: „K provedení útoku uživatel pošle PHP skript s koncovkou .php, který začíná třeba textem GIF123.“
Zkus se opravdu zamyslet nad tím, co by se stalo, kdyby jsi odstranil chybně použitý urldecode() – problém je totiž v něm, ne v podmínce.
Jakub Vrána : Emkei:
no to je opravdu neprekonatelny problem napsat si vlastni algoritmus na detekci obrazku podle obsahu, kdyz k tomu php nenabizi vhodnou funkci.
ja moc dobre vim, co tu chybu zpusobuje, jen se ti tu cely den snazim vysvetlit, ze nejde o zadny nesmysl, jak tady neustale pises, ale beznou chybu, ktera EXISTUJE, prestoze ji mistr sveta jako ty nezna...
Emkei: Jakub Vrána :
Pleteš se ve dvou věcech:
1. Obrázek může být po všech stránkách správný, ale přesto může obsahovat spustitelný PHP kód (třeba v EXIF komentáři).
2. Zda webový server zpracuje soubor jako PHP skript, se rozhoduje na základě jeho koncovky. Takže je úplně jedno, co je uvnitř souboru, důležitá je koncovka. Pokud jsou tedy nahrané soubory v adresáři dostupném z webu, tak musí mít správnou koncovku. Kontrola podle koncovky je v tomto případě tedy jediná možná.
Jakub Vrána : Emkei:
ad 1: i kdyz je kod napsany v EXIF nebo primo v tele obrazku, neni problem PHP kod detekovat nebo jednoduse sahnout po jinem typu ochrany. snazis se prevest rec od null byte? :)
ad 2: copak ja nekde tvrdim, ze to funguje jinak?
Emkei: Jakub Vrána :
1. Napsal jsi „vlastni algoritmus na detekci obrazku podle obsahu“. Já jsem ti jen vysvětlil, že takový algoritmus by byl k ničemu.
Problém tebou popsaného útoku už jsem ti doufám vysvětlil (naposledy uvedu, že spočívá v chybném použití funkce urldecode(), nikoliv v kontrole souboru podle koncovky).
2. Ano tvrdíš, konkrétně např. v příspěvku http://php.vrana.cz/kontrola-bezpecnosti-….php#d-8884.
Bohužel si zcela odmítáš připustit realitu a další diskuse tedy ztrácí smysl. Já ti dokola trpělivě vysvětluji tvé omyly, ale ty to vůbec nedokážeš vnímat.
Jakub Vrána : Emkei:
ad1: kolikrat ti mam rikat, ze podstatu mnou popsaneho utoku vysvetlit nepotrebuji, vim velice dobre, co chybu zpusobuje. nikde jsem te nezadal o vysvetleni, pouze o pochopeni toho, ze dany utok existuje v realnem zivote!
ad2: muzes me prosim citovat, kde v uvedenem prispevku tvrdim, ze se webovy server rozhoduje, zda PHP script zpracuje, na zaklade jeho obsahu?
Emkei: Jakub Vrána :
2. „kdyby se kontroloval obsah souboru, tak by to utoku zabranilo“. To je nesmysl.
Jakub Vrána : Emkei:
neni, napr. kontrola obsahu souboru pomoci algoritmu na detekci PHP kodu by utoku zabranila. navic ta veta nerika nic o tom, ze se PHP soubor zpracovava na zaklade jeho obsahu, jak jsi me obvinil.
Emkei: Jakub Vrána :
Jasně jsi uvedl kód, který považuješ za kontrolu obsahu a který by podle tvého tvrzení útoku zabránil: <?php if (!getimagesize($HTTP_POST_FILES['obrazek']['tmp_name'])) die("Neplatny format obrazku"); ?>. Ve skutečnosti by mu nezabránil.
Podle toho, jak upřednostňuješ kontrolu obsahu před kontrolou koncovky, to vypadá, že si myslíš, že se stejně chová i webový server (on se tak dá i nastavit, ale neznám nikoho, kdo by to dělal). Pokud si to nemyslíš, tak je to jen dobře.
Když se webový server rozhoduje podle koncovky, musíme se rozhodovat stejně. Kontrola obsahu sama o sobě (bez kontroly koncovky) je cesta do pekel, protože by vedla k vytvoření blacklistu zakázaných obratů. Můžeš pro zajímavost uvést kód, kterým bys kontroloval, zda obrázek neobsahuje PHP kód?
Jakub Vrána : Emkei:
ano, to byl chybny usudek, ktery te ovsem neopravnuje k tomu, vymyslet lzi v tom smyslu, ze verim ve zpracovani PHP souboru na zaklade jejich obsahu.
ja zadny algoritmus neuprednostnuji, naopak jsem jasne uvedl "...nebo jednoduse sahnout po jinem typu ochrany", tak si prestan vymyslet.
s tim s tebo vyjimecne souhlasim, ze kontrola sama o sobe (bez kontroly koncovky) je cesta do pekel, ty to ale prezentujes tak, jako kdybych ja nekde tvrdil opak, coz neni pravda.
jeden z nejsnazsich zpusobu, co me napada, je vypnout direktivu short_open_tag a detekovat stringy <?php a obmeny language="php", kazdopadne to by bylo nutne overit vicero testy...
Emkei: v6ak:
Samozřejmě, že to PHP tam lze detekovat. Ale co když náhodou se to objeví v obrázku? (V případě shorttagu jsou to dva byty a vyskytne se to náhodně průměrně v jednom z 65536 případů, na což stačí 65537 bytů, tedy 64kB + 1B by stačil, aby se v tom vyskytly tyto dva znaky průměrně jednou.) Vysvětlovat to uživateli by bylo dost trapné (i když bezpečné). Navíc by bylo potřeba kontrolovat např. i HTML kvůli XSS.
v6ak: WuDo:
A nebo tyto byty z obrázku vystřihovat a dávat místo nich růžovou ;-) Aby bylo jasně vidět, kde to nebezpečí bylo....ale trochu vážně... kdybychom ale nahradily bytovou podobu "php" = 706870 (v hexa) za 706869... tak by si toho asi nikdo nevšiml v obrázcích (podobné pro "<" = 3C změnit na 3d a pod.)
Pokud bychom se bavili o absolutním bezpečí a uživatelské neotravovanosti... nevím však u jak velkých souborů by to bylo ještě únosné...
Proto otázka: Je to proveditelné (byl to jen můj zbloudilý nápad)?
Jakub Vrána :
Všechny formáty obrázků používané na webu data komprimují. Takže odstranění nechtěných konstrukcí by bylo velmi složité.
Důležité je si uvědomit, že webové servery (a následně i prohlížeče) pracují se soubory podle jeho typu. Takže konstrukce nebezpečné v PHP jsou uvnitř obrázků zcela neškodné a není nejmenší důvod se jimi znepokojovat. Tedy samozřejmě za předpokladu, že zajistíme správný typ souboru.
Jakub Vrána : Emkei:
"...a není nejmenší důvod se jimi znepokojovat"?! ja znam zatracene dobry duvod, proc by na tuto moznost lide naopak myslet meli, rika se ji LFI - Local File Inclusion, tak je nemystifikuj...
Emkei: Juan:
Z následující věty mám pocit, že test na LFI a RFI Jakub provedl:"Adresy stránek nejeví známky toho, že by se manipulací s nimi dala aplikace přesvědčit k vložení nedůvěryhodného souboru."
Nebo ty snad předpokládáš, že by někdo v PHP kódu includoval obrázek? To by byla stejně utopistická a uměle vyrobená chyba jako v tvém prvním příkladě.
Emkei:
to je urcite fajn, ze (podle Jakuba) neni mozne na auditovanem serveru provest utok LFI/RFI, nedava mu to ale nejmensi pravo mast ctenare tim, ze nemaji nejmensi duvod znepokojovat se PHP kodem v obrazcich. duvod znepokojovat se maji, a to dost velky...
ano, predpokladam, ze by nekdo v PHP kodu includoval obrazek, viz vsechny aplikace obsahujici konstrukci include("./$_GET['page']");
ta (podle tebe utopisticka a umele vyrobena) chyba je totiz jednou z nejrozsirenejsich zranitelnosti na Internetu, tak proc reagujes na veci, kterym ocividne nerozumis?
Emkei: Juan:
Konstrukce include("./$_GET['page']"); je častá, velice nebezpečná a samozřejmě utopistická není, to naprosto souhlasím. Jenže právě proti ní Jakub kontrolu podle mě provedl:"Adresy stránek nejeví známky toho, že by se manipulací s nimi dala aplikace přesvědčit k vložení nedůvěryhodného souboru."
Utopistické by bylo předpokládat, že se někde v kódu objevuje inkludování např. avatarů, které si uživatelé sami mohou uploadovat na server.
v6ak:
Já bych to uzavřel takto:
Otázka: Je nutné se zabývat přítomností PHP kódu v obrázku se správnou příponou?
Odpovědi:
* Pokud programuji, jsem alespoň trošku přemýšlející programátor a mám na serveru "běžné podmínky"*, pak je to naprostá zbytečnost.
* Pokud kontroluju aplikaci po nějakém naprostém blbci (nebo po někom, o němž to můžu z nějakého důvodu předpokládat), pak to skutečně smysl má. Pak má ale i smysl zjistit, zda náhodou někdo nezapnul zpracování PHP pro *.jpeg apod. (Ano, v případě penetračních testů skutečně má smysl předpokládat o programátorovi všechny možnosti: i to nejhorší i to nejlepší. To nejlepší ale s tím, že i mistr tesař se někdy utne.)
*) Pokud bych mohl, rád bych se zde vyhnul definici, trošku pomůže druhý bod odpovědi.
v6ak: pojízdná kočka:
Já bych si počkala na ten (slibovaný) článek ;-)Tam to určitě bude nějak přehledně shrnuto.
David Grudl:
Mohl bych se zeptat, jaký význam má v kódu řádek if($ufile != none) { ?
David Grudl: Emkei:
promenne jsem umyslne pred odeslanim komentare zmenil tak, aby korespondovaly s jiz zverejnenymi kody Jakuba a byly tak pro ctenare lepe pochopitelne, tato mi ocividne unikla, chytrym ctenarum to urcite doslo.
Emkei: Martin:
Emkei, z celeho diskuse (a to ji ctu opravdu poctive celou) mi prijde, ze jsi tak trochu blbec.
Jakub Bouček:
Jestli chápu dobře, tak pouhým odstraněním urldecode() by celý problém s null byte zmizel. Je nějaký důvod pro použití této funkce na tomto místě - nebo obecně v tomto kusu kódu?
Musím říci, že uvedený kód mě dost zmátl v tom, která data jak přicházejí zakódována (měl jsem za to, že v běžných situacích do PHP vstupují data v "čisté" formě a ještě jsem si to teď zkusil a je to tak).
Potom bych tedy řekl, že funkce urldecode() je zde umístěna zcela nesmyslně a právě ona způsobuje ohrožení v souvislosti s názvem souboru obsahujícím "%00" (psáno přesně takto, jikoliv jako bajt 0x00).
Chápu problém správně?
Jakub Bouček: Jakub Vrána :
Je to přesně tak. Použití funkce urldecode() je stejný nesmysl jako by bylo třeba zavolání <?php substr($_FILES['obrazek']['name'], 0, 12) ?> na stejném místě.
Jakub Vrána : Pavel Kral:
CLOVEK kterej pise uz nejakou dobu takovejhle nesmysl v zivote nevyplodi..to napises tak ty..mas mozna nacteno o bezpecnosti webu ale v zivote si nic nenapsal..ja jsem si kuprikladu napsal Objekt StringOperator ktera ma krome jinych funkci statickou funkci isImage(); ktera uz se postara o to jestli jde opravdu o obrazek..a kazdy kdo pise uz nejakou dobu ma spousty knihoven nebo pouziva framework..a nejakej takovejhle proceduralni script..Kde zijes?!..fakt jen v teorii
Enlil:
správně je "vztahovačný", pane chytrý :-)
Enlil: pojízdná kočka:
Přečetla jsem si to vlákno na Lupě a docela síla.. :-)emkei: Proč jste nakonec nepřijal tu sázku?
Emkei:
ja tu sazku prijal, ale vyzyvatel uz se neozval (proc asi :)
Emkei: Jakub Vrána :
Sázku jsem nabídl pouze já, což je veřejně zdokumentované: http://www.lupa.cz/clanky/nebezpecne-webhostingy-…/vlakno/#o234680. Ty jsi sázku nepřijal ani veřejně ani soukromě e-mailem. Nikdy jsi veřejně ani soukromě neprojevil zájem o účast na kterémkoliv termínu. Přestaň prosím kromě urážení ještě lhát.
Jakub Vrána : pojízdná kočka:
Tady - http://www.lupa.cz/clanky/nebezpecne-webhostingy-3/nazory/235800/ - se píše poněkud něco jiného ;-)pojízdná kočka:
(toto byla reakce na Emkei) Emkei:
nabidky jsem dostal celkem dve, jedna se tykala auditu weboveho serveru, ktery jeho majitel povazoval za nedobytny a clanek zesmesnoval. nabidku jsem tedy pres mail prijal, slibene autentizacni udaje, ktere vyzyvatel slibil vecer poslat, jsem vsak uz nikdy nevidel a po danem cloveku se slehla zem.
druha nabidka zaznela od Jakuba Vrany, tu jsem neprijal z toho duvodu, ze je jednoduse nerealizovatelna. silne pochybuji, ze tak arogantni clovek, jakym Kuba jednoznacne je, by dokazal priznat, ze mi jeho skoleni naprosto nic nedalo a nakonec by to skoncilo tak, ze bych tech pet tisic musel stuj co stuj zaplatit.
Emkei: Jakub Vrána :
Proto jsem po tobě chtěl, ať před školením alespoň v bodech sepíšeš své současné znalosti. Sice se do toho vejde třeba i to, že nějaký útok znáš, ale nerozumíš mu (jak předvádíš třeba v této diskusi), ale to nevadí. Já nemám problém ti dát školení zadarmo, důležitější pro mě je, že se třeba něco dozvíš a přestaneš šířit bludy (jako třeba „neni aktivovana direktiva magic_quotes_gpc a lze tak v komunikaci se serverem pouzivat null byte“).
Jakub Vrána : Emkei:
jak bych asi mohl sepsat vsechno? stacilo by zapomenout jedinou vec a uz bys mi neuveril, ze jsem ji znal. a dat ti kompletni seznam veskerych utoku, ktere znam? to verim, ze bys pak po me tech 5 000 uz ani nechtel. tohle jednoduse nebylo realizovatelne, at se snazis sebevic. v teto diskuzi jsem naopak predvedl, ze tech utokum znam vic nez ty, pokud jsi si nestacil vsimnout.
muzes mi vysvetlit, co na mem vyroku o direktive magic_quotes_gpc bylo chybne, kdyz se tim neustale ohanis? je-li aktivovana, escapuje veskere null bytes a nadale s nimi tudiz neni pracovano jako s metaznaky, byt by je utocnik ve sve komunikaci se serverem podsouval. pouc me, v dokumentaci php to maji ocividne spatne...
Emkei: Jakub Vrána :
V této diskusi jsi předvedl pouze to, že jsi četl o útocích, jejichž podstatě nerozumíš.
Na školení se opravdu nemusíš bát přijít – jeho obsah je veřejně popsán, takže když mi dáš seznam svých znalostí, který bude tento obsah pokrývat, tak po tobě školení nebudu chtít zaplatit. Motivací pro mě skutečně je to, abys problematice porozuměl.
Zapnutí magic_quotes_gpc u aplikace, která data posílaná do databáze správně ošetřuje (to znamená buď vázáním proměnných nebo ošetřovací funkcí databáze), je k ničemu. Zapnutí magic_quotes_gpc by tebou popsanému útoku navíc nijak nezabránilo, protože z venku žádný nulový bajt nepřijde.
Co se dokumentace PHP týče, tak jsem jejím oficiálním spoluautorem, takže jsi pravděpodobně jen špatně pochopil něco, co jsme do ní napsali.
Jakub Vrána : Emkei:
na testovanem serveru jsem nasel vic chyb nez ty, aniz bych mel pristup do administrace, predlozil jsem ti ukazkovy priklad vyuziti null byte v uploadu a podle tebe jen o utocich ctu a nerozumim jim? jsi k smichu...
tvoje starost o me vzdelani je opravdu slechetna, kazdopadne me stale vic a vic presvedcujes o tom, ze mi nemas co nabidnout.
aha, takze tve tvrzeni, ze direktiva magic_quotes_gpc nema s nullovym bytem nic spolecneho stoji na faktu, ze je aplikace pracujici s uzivatelskymi daty spravne napsana a toto si dokaze ohlidat sama?! proc my ty bezpecnostni audity vubec delame, kdyz jsou vsechny aplikace tak dokonale a dokazi si null byte podle tebe ohlidat samy...?
ja obsah dokumentace pochopil velice dobre, dokonce jsem ji volne citoval, kdyz jsem o direktive magic_quotes_gpc psal, proto mi tvoje argumenty prijdou usmevne.
Emkei: Jakub Vrána :
Zde v diskusi jsi nepopsal žádný problém serveru Na volné noze. Ukázka dosvědčila to, že sis omylem spojil dvě nesouvisející věci (kontrola podle koncovky a chybné použití funkce urldecode).
Problém SQL injection, kterému magic_quotes_gpc dokáže za určitých podmínek zabránit, jsem kontroloval na různých místech a podle všeho k němu aplikace náchylná není. To, že je magic_quotes_gpc vypnuté tudíž rozhodně není chyba.
Jakub Vrána : Emkei:
opravdu? a co treba odhaleni stromove struktury serveru a upozorneni na mozne vyuziti null byte pri uploadu souboru na server, nebot ty jsi ten test ocividne neprovedl. ale to jsi ani nemohl, kdyz jsi ostatne ani netusil, ze neco takoveho na internetu existuje.
to je fajn argument, SQL Injection neni na serveru mozna, nebot Jakubovi se na nem zadnou nalezt nepodarilo. tvi zakaznici ti musi asi hodne verit, ja bych si to na triko nevzal...
Emkei: Jakub Vrána :
Popiš prosím, jaký problém serveru jsi odhalil.
1. Zjistil jsi umístění souborů na webu, což jsi ale k ničemu nevyužil.
2. Popsal jsi problém s nulovým bajtem, kterým server netrpí.
K tomu, abych mohl dát ohledně SQL injection za server ruku do ohně, tak bych potřeboval na test více času nebo zdrojové kódy. Vědomí zapnutého magic_quotes_gpc by mi naproti tomu nepomohlo, protože i v tom případě je řada situací, kdy je tento útok možný.
Jakub Vrána : Emkei:
ad 1: skutecnost, ze ty uvedene informace nedokazes vyuzit, jeste neznamena, ze se nejedna o chybu. o chybu se jedna a pokud neveris mne, zeptej se nekoho tretiho, kdo bezpecnostni audity nabizi.
ad 2: alespon jsem te naucil neco noveho a priste, az narazis na upload, ktery bude odpovidat tvemu popisu v reportu, uvedeny test provedes.
takze ty ses majitelu onoho serveru ani nezeptal, zda aplikace metaznaky nejakym zpusobem osetruje, kdyz uz maji direktivu magic_quotes_pgc vypnutou? to by melo byt u black boxu samozrejmosti...
Emkei: Jakub Vrána :
1. Tvrdil jsem, že znalost umístění souborů nedokážeš na nic využít ty. Pokud ano, tak popiš na co (můžeš to poslat i soukromě provozovateli serveru).
2. Jsem rád, že máš dobrý pocit. Já zase doufám, že jsi pochopil, v čem spočívá podstata tebou popsaného problému a že to nijak nesouvisí s kontrolou koncovky souboru. Kdyby se soubor kontroloval jinak, tak hrozí stejný problém. Podle mě ale tebou popsanou chybu udělá jen popleta, který nerozumí principům ošetřování dat.
Test byl domluven tak, že nedostanu přístup ani ke zdrojovým kódům ani k nastavení.
Jakub Vrána : Emkei:
jak vis, co dokazu a co ne? provozovateli uz jsem mail psal, uvedl jsem, jak chybu opravit, nikoliv jak zneuzit, takove informace nejsou soucasti zadneho seriozniho pentestu.
rovnez jsem rad, ze mas dobry pocit, ze mam dobry pocit :) podstatu problemu jsem pochopil uz davno, v tom svoje pricineni nehledej. tech popletu je na internetu dost a i kdyby byl jen jediny, neni to padnym duvodem k tomu, proc pri penetracnich testech i tento typ utoku nevyzkouset.
skutecnost, ze jste byli domluveni chovat se k serveru jako utocnik, neznamena, ze se stejne mas chovat i k majitelum. prestoze pristup ke zdrojovym kodum nemas, soucasti kvalitniho reportu takove varovani byt musi a at ti, kdo pristup ke kodu maji, vyvodi patricny zaver.
Emkei: pojízdná kočka:
tedy.. to teda koukám, jak se diskuse rozjela :)Jako nezúčastněnou čumilku pociťuju jako škodu, že se toto vlákno v podstatě 'zadrhlo' na provozovateli toho serveru, který by to mohl rozřešit, ale který nejspíš na tuto diskuzi nezabloudí a nevyjádří se, zda-li EmKeiův mail měl nebo neměl patřičný užitek...
Jakub Vrána :
Robert Vlach byl na dovolené, ale myslím, že až se k tomu dostane, tak se s námi jistě podělí.
Jakub Vrána : Emkei:
v tom mailu jsem mu odkaz na tuto diskuzi zasilal, takze mimo "hru" urcite neni...
Emkei: v6ak:
Btw bylo by možné do požadavku vecpat něco jako:
name=../foo.png
? (Directory traversal) Neznám protokol http tak podrobně, abych to mohl jednoduše zkusit nebo potvrdit nebo vyvrátit. Další věc by byla, jak s tím náloží různé verze PHP.
v6ak: Jakub Vrána :
Ano, některé prohlížeče pokud vím dokonce posílaly plnou cestu k souboru. PHP si z toho do klíče "name" převezme jen název souboru.
Jakub Vrána : pojízdná kočka:
Jakub: Například ten nulový bajt v názvu uploadovaného souboru/obrázku - o tom jsem nevěděla.Smím se tedy zeptat, jak by se mělo proti nebezpečí uploadu maligního souboru obecně postupovat...
* když obrázky ukládám do souboru pod původním názvem
* když obrázky ukládám do souboru pod změněným názvem (např. ID souvisejícího záznamu)
* když obrázky ukládám do databáze (včetně obsahu)
?
Tak nějak jsem pochopila, že skript může "zasáhnout" na dvou místech - při 'přijímání' souboru a jeho ukládání, a při jeho použití/výpisu do HTML; a že by kontrola v obou případech měla být konsistentní tak, aby se spuštění maligního souboru zamezilo buď v 1. nebo 2. fázi.
Potěší mě odpověď, ale možná by to stálo i za samostatný článek, což by mě potěšilo ještě víc :-)
Jakub Vrána :
Článek napíšu.
Jakub Vrána : pojízdná kočka:
Fajn. Ale už je měsíc fuč a článek nikde. Nezapomněl jsi na něj? ;-)pojízdná kočka:
P.S. Koukám - dost toho je v článku "Ukládání souborů od uživatele", ale hack s nulovým bajtem tam není. Emkei:
protoze podle Jakuba hack s nullovym bytem neexistuje. co nezna, to neexistuje...
Emkei: Jakub Vrána :
Opravdu nechápeš, že problém, který jsi popsal, spočívá v chybném použití funkce urldecode()? Stejně jako by byla chyba na daném místě použít třeba funkci substr(). V útoku http://php.vrana.cz/kontrola-bezpecnosti-….php#d-8864 se nulový bajt nakonec ani neposlal, kód ho chybným použitím nějaké funkce sám vytvořil.
Jakub Vrána : Jakub Vrána :
Skutečně, další článek tedy již psát nebudu. Kód, který je v článku uveden, samozřejmě funkci urldecode() chybně nepoužívá. A nulový bajt poslaný přímo v datech ošetřuje samo PHP už od verze 4.1.1.
Jakub Vrána : Emkei:
...a proto si vsichni ti lide, co timto problemem na internetu trpi, vse pouze vymysleli a pravdu ma (jako ostatne vzdy) Jakub Vrana.
Emkei: Jakub Vrána :
Ale já přece netvrdím, že problém neexistuje. Pouze jsem ti doufám pomohl pochopit, v čem spočívá. Tedy v tvém příkladě ne v kontrole souboru podle koncovky, ale v chybném použití funkce urldecode(). Stejným problémem by bylo třeba použití funkce substr().
Tvrdím pouze to, že tímto problémem netrpí server Na volné noze. Takže když o něm u tohoto článku píšeš v souvislosti s tím, že server kontroluje typ souboru podle koncovky, tak nechápeš, v čem problém spočívá.
Jakub Vrána : Emkei:
ty si ze me strilis, ze ano? napsal jsi, ze uvedeny utok je NESMYSL! fajn, ted uz jsi alespon priznal, ze existuje, ale tvrdis, ze jsi mi pomohl pochopit, v cem spociva. ale ja to mily Kubo vedel hned od zacatku, to jenom ty jsi zmenil taktiku z nazoru, ze jsem si nejaky utok vymyslel na to, ze jsem nepochopil, v cem onen utok spociva...
ja take netvrdim (a nikdy jsem netvrdil), ze danym utokem trpi server navolnenoze.cz, nybrz server, ktery jsi popsal ve svem reportu. tam jsi totiz nic o dodatecnych opatrenich zminenych v komentarich nenapsal.
Emkei: Jakub Vrána :
Uveď prosím, kde jsem útok označil za nesmysl. Možná myslíš příspěvek http://php.vrana.cz/kontrola-bezpecnosti-….php#d-8871, kde se ale použití slova „nesmysl“ vztahovalo na použití funkce urldecode(). A to nesmyslné skutečně je.
Zjevně jsi nechápal (a zdá se, že to nechápeš doteď), v čem útok spočívá, protože sis ho spojil s kontrolou souboru podle koncovky. To ale není problém tebou popsaného útoku, problém je chybné použití funkce urldecode().
Z toho plynou všechny tvé následující omyly. Z výroku „Typ souboru se určuje podle koncovky“ sis odvodil „jistě se pak chybně aplikuje nějaká funkce, jak jsem to někde viděl“.
Jakub Vrána : Emkei:
prispevek http://php.vrana.cz/kontrola-bezpecnosti-….php#d-8858 dokazuje, ze jsi utok na upload pomoci null byte vubec neznal.
zde http://php.vrana.cz/kontrola-bezpecnosti-….php#d-8871 jsi oznacil utok za neco stejne nerealistickeho a smesneho, jako zkracovani na 12 znaku. stejne to ale neni! zatimco utok pomoci null byte existuje pomerne hojne, zkracovani na n znaku nikoliv.
klidne se to snaz uhrat na to, ze jsi dany utok znal nebo ze jsem ho diky tve ochote dokazal pochopit ja, ctenari si to zajiste preberou sami...
Emkei: 
tiso:
Tebou odkazované príspevky vôbec nedokazujú to, čo tvrdíš.
tiso: Robert Vlach:
Přátelé zdravím :-) Dneska v noci jsem se vrátil z prosluněných Alp, takže přispívám do diskuse alespoň krátce se zpožděním:
Nejprve k technické stránce věci. Jak již vyplynulo z diskuse, upload na serveru www.navolnenoze.cz je proti null byte útoku imunní. Co se týče druhého zmiňovaného problému, tedy odhalení adresářové struktury serveru, ta by byla asi zneužitelná na sdíleném webhostingu s mnoha účty (není to sice náš případ, ale mezeru jsem i přesto zacelil).
Závěrem ještě k osobní rovině sporu. Jakub Vrána se zabývá primárně bezpečností, zatímco Martin Klubal alias Emkei se specializuje na její překonávání formou legálních penetračních testů. Svým způsobem stojí oba na opačných stranách přístupu k zabezpečení webových serverů. Jistá řevnivost by tedy byla pochopitelná a pro nás jakožto širší čtenářskou veřejnost přínosná. Objeví-li se ovšem v diskusi snahy protivníka ponížit výrazivem a nikoli platnými argumenty, získávám jako nezaujatý pozorovatel pocit, že strana, která se k takovým prostředkům uchyluje, postrádá jiné pádné argumenty (krátký přehled chybných argumentů např. viz http://tinyurl.com/argumentace). Subjektivně se mi zdá, že Martin zachází v užití chybných argumentů dosti daleko a to jej pak v očích potencionálních klientů poškozuje více, než si možná sám uvědomuje. Jakub se oproti tomu alespoň snaží diskusi držet v rovině věcné, což si asi žádá dost sebekontroly. Cením si toho, že Jakub i Martin své zkušenosti publikují, takové odborníky potřebujeme jako sůl. Mohu-li si však dovolit malou radu závěrem, doporučil bych Martinovi vyjadřovat se jako profesionál a více vážit slova. Je to důležitou součástí budování dobrého jména v oboru ;)
David Grudl:
Jak penetrují mladí chlapci http://phpfashion.com/jak-penetruji-mladi-chlapci
David Grudl: pojízdná kočka:
citováno z článku: "...Pokud budete uploadovat soubor nazvaný třeba 70%absinth.jpg, na straně serveru byste dostali 70«sinth.jpg."Wow! A co soubor nazvaný například "obrazek.php%00.jpg" ?
dRaGen:
Pokud jsem to správně pochopil, tak php %00 nezná a vše co je za ním ořízne (včetně něj). Tudíž se to nedostane už přes tu první podmínku. A urldecode z %00 udělá znak který nelze vykreslit, protože prvních 31 znaků ASCII kod tabulky nejsou vykreslitelné.Je to tak nebo se pletu ? :-)
Jakub Vrána :
<?php urldecode("%00") ?> vytvoří nulový bajt, který má výsostní postavení (v jazyce C ukončuje řetězce). Když se např. pokusíme vytvořit soubor s nulovým bajtem v názvu, tak se název souboru za nulovým bajtem uřízne.
Jakub Vrána : Michal Čížek:
Jsa pouhým marketérem, pisálkem a analytikem, nemohu posoudit argumenty oponentů v odborné rovině. Neznám také osobně ani jednoho z nich a nemám tedy důvod někomu stranit z osobních důvodů. Jist jsem si ale jedním: Jakub argumentuje věcně, trpělivě a nekonfliktně, Emkei jako namyšlený, sebestředný hlupák. Vzpamatujte se příteli a nedělejte si větší ostudu, než je nutné. Po Vašem výstupu v této diskuzi bych si od Vás nekoupil nejen audit ale ani cokoli jiného. Od Jakuba ano. A to dokonce i v případě, že byste měl nakrásně pravdu Vy. Emkei:
to zde vsichni vidite pouze moje narazky a ty Jakubovy nikdo? vrele diky za "objektivnost".
http://phpfashion.com/jak-penetruji-mladi-chlapci#comment-14131
Emkei: pojízdná kočka:
1) Uveď odkaz na někoho jiného, kdo v diskuzi na této stránce použil nevhodné narážky.2) Uveď odkaz na Jakubovy příspěvky v této diskuzi, které by byly za hranicí slušného chování.
Pavel Kral:
Takovy chytroliny jako Emkei mam nejradsi.hafo kecu z knizek a praxe urcite zadna.to cist po ranu tak je zkazenej celej den..a ten kus kodu co tam emkei napsal to ma bejt joke?..http_post_files?to se nepouziva snad uz 10let..docela se divim jakube ze mu vubec dovolis sem neco psat..obdivuju te!!Pavel Kral:
Jaj koukam ze david grundl napsal emkeiovi celej clanek:)..jen do nej do lamy:)Lamicz:
Emkei: Proc se hadas, kdyz to porad nechapou? Nebudu se hadat, ale konat. Dej si www.navolnenoze.cz a hackni jim to. Vzdyt je to jednoduchy ;) Dokaz, ze Jakub nema pravdu a Ty mas, ze opravdu zapomnel v auditu zapomenutou chybu. Pak nikdo nerekne ani pul slova.collateg:
Protože na to nemá, všechno, co píše, je snůška nesmyslů, narážek,gramatických chyb a textu bez čárek a háčků. Jakub a David jsou mistři, které ale lama ani nepozná.Ales Repka:
Emkeie je mi opravdu lito, nedokazat pochopit tak trivialni vec kterou mu navic Jakub naserviroval na stribrnem podnose je opravdu smutna zalezitost.Diskuse je zrušena z důvodu spamu.
© 2005-2024 