Category Archives: Bugfixy

SQL injection a jiná zvěrstva

Obrátil se na mne klient s prosbou o pomoc při dokončení a rozjetí jejich fungl nového informačního webu. Web jim komerčně (to je v tomto kontextu důležité) programoval nějaký, pravděpodobně nezávislý, vývojář. Web je dokončený (prezenční i administrační část) a požadavkem byla pomoc při revizi současného řešení, optimalizaci, správě reklamních pozic a podobné rutinní záležitosti. Původní vývojář prý totiž ke konci projevoval jistou neochotu a nespolehlivost při řešení poptávaných zadání.

Nutno podotknout, že klient je v tomto směru pole neorané. Jeho představa, že si zaplatí vytvoření webu a je prakticky vše hotovo byla roztomile naivní. Abych rozvedl tu představu: klient si myslel, že lidi tam přijdou sami, že obsah webu se snese z nebe a celé to bude samo od sebe generovat velké zisky. I když na tom posledním něco  je: web ještě není produkční, ale reklamní pozice josu již do jedné rozprodány.

S tímto vědomím jsem vstupoval v jednání, vyžádal si podrobnější informace o projektu a podíval se dané aplikaci na zoubek.

A nyní přijde pointa:

  • do administrace jsem se přihlásil nejprimitivnější formou SQL INJECTION, tedy: ‘ OR 1=1 —
  • laborováním s číselnými paramertry v URL jsem dokázal na straně databáze provádět parádní kouzla
  • při chybě v SQL dotazu se tento i s popisem chyby od mysql serveru naférovku vypsal
  • pri testování XSS a vložení kusu JavaScriptu do kontaktního formuláře jsem rozhodil celou administraci
  • hesla adminů v administraci se vypisovala čistě plaintextově
  • … o tom, že v HTML byla hromada chyb a web nesplňoval ani základní SEO praktiky se asi nemá pod tíhou skutečností výše cenu zmiňovat …

Nutno říct, že uvedené problémy byly jen první čtyři checky, jenž mě z fleku napadly, a všechny dopadly pozitivně resp. negativně.

Byl jsem silně v šoku. Web na první pohled vypadá profesionálně. Moderní layout, stavba HTML na první pohled nevypadala špatně .. s layoutem administrace (celé se to tváří jako Windows Vista) si někdo taky silně vyhrál. A pak tohle. Já to nechápu. Jak si někdo za takto odvedenou práci může brát peníze? A taky si říkám, jakou roli v tomto ohledu asi hrál fakt, že klient dané problematice rozumí na úrovni nula? Že by prodané pozlátko shnilé uvnitř?

Na závěr dvě poznámky:

  1. Vývojář klientovi za úplatu poskytuje také hostingové služby. Když vidím jak vypadá aplikace, je otázkou, jak je na tom zabezpečení hostingu. Ještě jsem to nezkoušel.
  2. Hledání chyb na cizích webech mně baví 🙂

Dodatek (aneb co mně velmi, velmi pobavilo):

"The requested URL /admin/virtualsecurity.php was not found on this server."

Zádrhel u DNSSEC s vlastním NSSETem

V polovině února tohoto roku jsem si u active24 zaregistroval doménu mujpro.cz (golfový trenér). Ihned po registraci jsem (tak jako u všech ostatních) přenastavil u domény NSSET na naše nska. Aktualizoval jsem konfiguraci bindu, otočil a za pár hodin vše vesele fungovalo.

Po měsící vývoje jsem zveřejnil betu vyvíjené aplikace úzké skupině testovacích uživatelů. Jako feedback se ke mě dostala informace o částečné nedostupnosti aplikace. V některých případech se uživatel vůbec nedostal na obsah dané prezentace, v jiných se mu nezobrazila žádná grafika (veškerou grafiku umisťuju na doménu třetího řádu) a v těch ostatních vše fungovalo korektně.

Z počátku jsem tomuto problému nepřikládal velkou váhu. Neměl jsem žádné known issue které by s touto nedostupností korespondovalo.  Jiné domény se zcela stejným nastavením mi fungovaly korektně. Testoval jsem korektní dostupnost prezentace z několika strojů (i s pomocí jiných uživatelů a lokalit). A také jsem se nechal ovlivnit faktem, že popsaný feedback přišel ze strany více či méne BFU.

Na záležitost jsem skoro zapoměl, když jsem jednoho dne prezentoval web na veřejné WIFI v kavárně Savoy jednomu z klientů. A ejhle. O reálné existenci problému jsem se přesvedčil osobně.

Problém byl v překladu DNSka. Ping byl zcela mrtvý – nepodařilo se mu přeložit hostname. Zjištění pro mě šokující. Hlavně jsem v první chvíli nechápal, proč se toto dějě selektivně jen na straně určitých providerů. Obrátil jsem se tedy na registrátora (active24) s podrobným popisem problému.

Reakce byla vysvětlující a poučná:

Problémy může způsobovat aktivní KEYSet na doméně. Ve chvíli kdy jste doménu převáděl na vlastní DNS již byla podepsána naším KEYSetem a ten na ní zůstal aktivní. Ve chvíli kdy je na doméně aktivní zabezpečení DNSSEC a zároveň na autoritativních nameserverech není příslušný klíč, budou nameservery poskytovatelů, kteří se k této technologii chovají korektně, považovat DNS odpovědi za podstrčené a komunikaci přeruší.

Pomocí autorizovaného požadavku jsem nechal z domény odstranit KEYSet a vše již funguje jak má. Solved.

Chyby, chybky a chybičky

Určitě to znáte. Vytvoříte funkční systém (jasně, že až po několika měsících ladění) a tento systém bez jediného problému běží třeba rok, dva i více. A po tomto bezproblémovém období nastává ta chvíle…

Z nenadání se objeví chyba.

Naprosto nelogická, bez žádného externího přičinění. Nutno říci, že takovéto problémy mají velmi zapeklitý charakter a špatně se hledají.

Pokud pominu otravnost těchto chyb, hodiny nervy drásání při jejich hledání a peněz které tímto přijdou nazmar (ano, občas se tyto chyby týkají i reklamních systémů…) mají něco do sebe.

Ony tyto chyby jsou obvykle velmi důsledné a vzniknou shodou velmi zajímavých náhod. Při jejich zkoumání se člově také více ponoří do daného systému a lépe pochopí dosud nepochopené. A někdy objeví i takové věci, které rozhodně nečekal :-).

Začnu si tyto “kousky” sbírat a podělím se s tím, co jsem nasbíral. Už čekám, odkud na mne opět nějaká vykoukne.