Dotaz: PHP ochrana pred SQL injection

[Peter]

Dobrý deň vám prajem.

Riešim ochranu mojej malej PHP aplikácie a pre uľahčenie programovania a aby som proste nezabudol ošetrovať každý vstup od používateľa som si dal do súboru funkcie.php (ktorý je includovaný hned na začiatku z každého iného súboru) na začiatok toto:

foreach($_GET as $K=>$V) { $_GET[$K]=Safe($V); }
foreach($_POST as $K=>$V) { $_POST[$K]=Safe($V); }
foreach($_COOKIE as $K=>$V) { $_COOKIE[$K]=Safe($V); }

function Safe($Value) { return trim(str_replace(array("'",'"',"`"),'',$Value)); }

samotná premenná v SQL dotaze je samozrejme v úvodzovkách

select ID from pouzivatel where (meno="$_POST[meno]" and heslo="$_POST[heslo]")

Pokiaľ ma moje slabé vedomosti neklamú, tak SQL injection sa robí práve cez "http vstupy" do aplikácie ($_REQUEST nepoužívam nikde) a týmto by to malo byť úplne ošetrené. Alebo sa kruto mýlim? Ak áno, na čo ešte treba myslieť?

Ak by to niekoho zaujímalo, tak znaky " ' ` odstraňujem pomocou str_replace preto, lebo som si istý, že ich používateľ nebude nikdy potrebovať.

Vopred vám veľmi pekne dakujem za odpovede a podnety.

---

---

Odpovědi

[Kit]

To vše je zbytečné a zavádějící. Dá se to udělat mnohem jednodušeji:

<?php
$db = new PDO('...');
$select = $db->prepare("SELECT id FROM pouzivatel WHERE meno=? AND heslo=?");
$select->execute(array($_POST[meno], $_POST[heslo]));

Do superglobálních proměnných $_GET, $_POST a $_COOKIE nikdy nic nezapisuj. Jsou určeny pouze pro čtení.

[Peter]

No ta aplikácia je veľmi stará, teda pdo nepoužíva, ale klasické mysql_query. Ak sa raz dokopem do toho aby som ju prekopal, tak samozrejme myslím na prepare, ale teraz to musím zatiaľ riešiť tak ako to riešim.

Z toho vyplýva: prečo je to podľa teba zbytočné a zavádzajúce? A prečo do superglobálnych premien nesmie nikdy zapisovať? Samozrejme, že chápem a akceptujem, že zložité čachre-machre so superglobálnymi premenami možu viesť a vedú k prúseru, ale čo je zlé na tomto jednoduchom zápise? Veľmi by som ocenil keby mi niekto nastienil pozadie, lebo voľajako teraz nevydím súvislosti (áno, som hlúpy, ale nikto z neba učený nespadol).

Ciže moja otázka stále platí. Pomože mi ten môj výmysel, alebo nie?

Veľmi pekne ti dakujem za pomoc a ochotu.

[Kit]

Místo funkce Safe() alespoň použij funkci mysql_real_escape_string(), která to na rozdíl od té tvé udělá dobře.

Zapisování do těchto superglobálních proměnných je plýtváním pamětí a výkonem. Navíc tím modifikuješ vstupní data, což je nežádoucí. Takový program pak mlží. Jsou to vstupní proměnné.

Tvůj výmysl ti nepomůže.

[Peter]

ten Safe samozrejme plánujem rozšíriť o dalšie testy.

Pamäte a výkonu je na túto aplikáciu až až.

Stále som sa nedozvedel prečo je modifikácia vstupných dát nežiadúca, ak viem čo robím a čo modifikujem.

A to najdôležitejšie - prečo mi ten výmysel nepomôže? Ale teraz ma zaujíma fakt čisto technické hľadisko a nie ideologické. Je mi jasné čo je podľa teba lepšie a ja s tebou plne súhlasím. Ale fakt sa teraz bavme o otázke tak ako bola položená. Ak riešim problém s riadením na aute je jasné, že najideálnejšie je kúpiť si nové auto a nebabrať sa so šrotom - ale zatiaľ to nové auto proste nie je.

Velmi pekne ti dakujem za trpezlivosť.

[Kit]

Modifikace vstupních proměnných je nežádoucí, protože tím výrazně zhoršuješ čitelnost programu. Data se ošetřují až těsně před použitím.

Už jsem ti napsal, že máš použít funkci mysql_real_escape_string(), která byla vyvinuta přesně pro tento účel a dělá to dobře. Nevynalézej kolo.

[Peter]

V poriadku - predpokladajme, že som zmenil Safe za mysql_real_escape_string. Dalej po prečítaní X diskusií na tému modifikácie superglobálnych premien na stackexchange.com mi je jasné prečo je toto riešenie nevhodné. Ale ja sa pýtam, odkliadnúc od toho, že je to nevhodné a nesprávne (čoho som si vážne vedomí a v budúcnosti to plánujem prerobiť) je toto moje aktuálne riešenie technicky funkčné? Ochráni ma to plne pred SQL injection? Ano? Nie?

Ja viem, že to musíš mať ťažké s takými exotmi ako ja, ale aj tak dakujem za ochotu.

[Aleš Janda]

Ochrání tě jenom tam, kde do SQL dotazu vkládáš proměnnou mezi uvozovky. Což možná neděláš u čísel - takže čísla chce ošetřit zvlášť. Jenže to závisí na konkrétní proměnné.

Takže je nejlepší projít ta místa, kde to vstupuje do SQL dotazu, a ošetřit to přímo tam podle kontextu.

[Filip Jirsák]

Místo funkce Safe() alespoň použij funkci mysql_real_escape_string(), která to na rozdíl od té tvé udělá dobře.

Možná. Pokud funguje úplně stejně jako parser SQL v MySQL a pokud je úplně stejně nakonfigurovaná. Stačí třeba jen se neshodnout ve vstupním kódování, a už to může být problém. Ano, je lepší použít tuhle funkci než nějakou svou samo-domo velmi přibližnou, ale já bych tu funkci rozhodně za 100% bezpečnou nepovažoval.

[Šangala]

Pomože mi ten môj výmysel, alebo nie?

Nie, Tvoj výmysel prinesie viac problémov než úžitku. Prestaň špekulovať a urob to čo je správne - mysql_real_escape_string() alebo PDO.

[Josef Kufner]

Podívej se na to, k čemu jsou magic quotes a proč už byly z PHP odstraněny.

Mršíš tím data, způsobuješ problémy s dvojitým escapováním a neřešíš data, která jsi načetl odjinud, například z databáze. Také to nefunguje, pokud chceš přijatá data použít jinde. Dále pak nepředáváš té funkci informaci o nastavení způsobu komunikace s databází, což může mít vliv na to, co je potřeba ošetřit.

Přepiš to, aby to používalo PDO a prepared statements. Beztak je to natolik děravé, že to nelze pustit do světa.

[Peter]

1.) http://forum.root.cz/index.php?topic=9790.0 (hlavne ten prý odsek)

2.) je to môj kód v ktorom sa hrabem výlučne ja, čiže viem o každej premennej úplne všetko, odkiaľ pochádza, kam ide, čo bude obsahovať, ... Mimochodom - tak v databáze predpokladám čisté dáta. Jedná sa mi o SQL injection a keby útočník dokázal vložiť dáta priamo do databázy, tak mu už je predsa jedno či aplikácia má dieru alebo nie.

3.) čo ma spôsob komunikácie spoločné s tým o čo sa mi tu jedná? Mimochodom "set character set utf8" a "set names utf8" mám default (ak ti ide o toto)

4.) mám x nových projektov kde samozrejme používam všetky nové vymoženosti - OOP, PDO, prepare, ... ale toto je jeden veľmi starý projekt ktorý používam ja a moja rodina a našiel som v ňom pár neošetrených vstupov, tak som to chcel poriešiť globálne (pričom ešte raz opakujem - keďže viem ako ten program presne pracuje a to do bodky, tak som si plne vedomí čo spôsobí ten môj výmysel). A možno sa ti to zdá zvláštne, ale ja mám aj rodinu, priateľov a prácu ktorej sa musím venovať a fakt si teraz nemienim brať dovolenku a stráviť týždeň nad prepisovaním blbostí.

5.) poslednú vetu nekomentujem, keďže je evidentné kam smeruje táto debata.

6.) neviem čo je také ťažké pochopiť jednoduchú otázku a namiesto ideologických kecov riešiť prísne technickú stránku veci. Ja mám vo zvyku už X rokov dávať každú premennú pri sql query do úvodzoviek (select X from table where ID="$_POST[ID]") a keďže predpokladám, že SQL injection sa celé točí v prvom rade okolo úvodzoviek (" ') a http vstupov ($_GET, $_POST, $_COOKIE, $_REQUEST - nepoužívam) tak predpokladám, že úplným odstránením úvodzoviek z premennej dosiahnem to čo chcem. A práve preto používam odstránenie a nie escapovanie, lebo som si plne vedomí čo by escapovanie spôsobilo. Áno, som prasa, som bastlič, som + dosaď si čo chceš + ale mňa zaujíma technické riešenie problému a nie ideologické dristy!

[Josef Kufner]

Nejsou to ideologické kecy, jsou to technické kecy.

Databáze "čistá" data neobsahuje a nikdy obsahovat nebude, neboť SQL injection tak nefunguje. Navíc se podívej ještě na cross site scripting a cross site request forgery. Jsem si celkem jist, že to tam budeš mít také.

Přepis na PDO není nijak zcestný, tak jako tak musíš projít všechny dotazy do databáze a opravit je, zda tam budeš cpát mysql_real_escape_string nebo vyměníš volání funkce vyjde nastejno, pokud si přpravíš vhodný wrapper okolo PDO, aby odpovídal starému kódu, tak to bude i znatelně jednodušší.

Tvůj zvyk s úvozovkami SQL injection neřeší, ba naopak, takto zranitelnost na SQL injection vzniká.

A ten první odkaz si rač vetnout za klobouk, vše co v této diskuzi je, je k tématu. Prostě to jen děláš blbě a bylo ti to řečeno.

[Peter]

Databáze "čistá" data neobsahuje a nikdy obsahovat nebude, neboť SQL injection tak nefunguje.

A ako teda funguje?

Navíc se podívej ještě na cross site scripting a cross site request forgery. Jsem si celkem jist, že to tam budeš mít také.

Áno, a ešte navyše k tomu som škaredý, koktavý a všeobecne nehodný používať počítač.

Přepis na PDO není nijak zcestný, tak jako tak musíš projít všechny dotazy do databáze a opravit je, zda tam budeš cpát mysql_real_escape_string nebo vyměníš volání funkce vyjde nastejno, pokud si přpravíš vhodný wrapper okolo PDO, aby odpovídal starému kódu, tak to bude i znatelně jednodušší.

Od začiatku tvrdím, že si plne uvedomujem, že toto riešenie je jediné správne a čisté a zároveň tvrdím, že to aj plánujem urobiť. Ja sa vôbec nehádam o tom, že niečo iné by malo byť jednoduchšie, lepšie a čo ja viem aké ešte. Sám v iných - nových - projektoch používam PDO s prepared, ... takže je mi ohľadom toho všetko jasné.

Tvůj zvyk s úvozovkami SQL injection neřeší, ba naopak, takto zranitelnost na SQL injection vzniká.

Ako?

A ten první odkaz si rač vetnout za klobouk, vše co v této diskuzi je, je k tématu. Prostě to jen děláš blbě a bylo ti to řečeno.

Nie, ten odkaz sedí ako "riť na šerbeľ". Krútime sa tu dookola s niečim čo mi je plne jasné, čo akceptujem, nepopieram a sám využívam. Ale na pôvodnú otázku som odpoveď stále nedostal a toto je kameň úrazu. To je až také ťažké pochopiť?

Ja som sa pýtal na jednu veľmi jednoduchú vec - ak zmažem v $_GET, $_POST, $_COOKIE úvodzovky (" ' `) aké má útočník ďalšie možnosti čo sa týka SQL injection??? Alebo jedina správna odpoveď je typu: "to ťa nemusí zaujímať, si hlupák, nemal by si používať pc, nieto ešte patlať nejake akožeprogramy"?

To ste vy géniovia fakt tak nepoužitelný v reálnom živote, že máte problém chápať jednoduché otázky?

[Lucius]

Nejsem sice genius ani se mi to nechce vymyslet, ale umim si predstavit treba nejake podstrceni subselectu apod. - tedy smazat uvozovky neni podle me ochranou proti sql injection.

[rADOn]

Josef se vyzná a místo vymýšlení narovnáváku na ohejbák bys měl pečlivě číst co ti napsal. To co jsi vymyslel je jen primitivní reimplementace magic_quotes. Jetli si myslíš že nemá pravdu, tak jen do toho – napiš Lerdorfovi ať je vrátí zpátky.

[Kit]

1. Jak ten odkaz souvisí s tématem?
2. Čistá data v databázi? Utopie.
3. Máš nastavený i jazyk? Asi ne, že?
4. Místo týdne strávíš dva. To se vyplatí!
5. Ano, směřuje k PDO.
6. Technické řešení problému jsi dostal. Teď už se bavíme jen o tom, že nejsi ochoten ho přijmout a stále hledáš alternativy. Klidně hledej dál...

[Peter]

Jak ten odkaz souvisí s tématem?

Tak, že ja sa pýtam na to ako čo najjednoduchšie, najrýchlejšie a najkrajšie zakryť zhrdzavené podbehy na aute a odpoveď je stále tá istá - kúp si nové auto.

Čistá data v databázi? Utopie.

Prečo? Keď nedovolím zapísať nejakú háveď tak je jasné, že tu hávaď nemám ani ako prečítať. A ak má útočník iný prístup k db, tak mu asi bude jedno čo ja robím v programe.

Máš nastavený i jazyk? Asi ne, že?

Teraz trošičku som mimo čo myslíš, ale ak "utf8_general_ci", tak áno

Místo týdne strávíš dva. To se vyplatí!

??? Čo prosím? Ja teraz riešim nechutný hack aby som sa minútu hnusne/nechutne zaplátal dieru tak čo potom tie 2 týždne?

Ano, směřuje k PDO.

Nie, smeruje to k urážke, lebo som si dovolil pýtať sa na otázku, na ktorú som stále nedostal odpoveď.

Technické řešení problému jsi dostal. Teď už se bavíme jen o tom, že nejsi ochoten ho přijmout a stále hledáš alternativy. Klidně hledej dál...

Technické riešenie - to správne - som ani dostať nemusel, lebo som o ňom vedel už pred položením otázky - opakujem ešte raz - ohľadom PDO je mi všetko jasné. Odpoveď na moju otázku ale proste stále jednoznačne neprišla. Čo na to povedať.

[Kit]

Neustále se ptáš, jak se máš střílet do nohy. My se ti to jen snažíme rozmluvit.

[Peter]

Pre pouzivatela GSNAK:

Tato otazka nie je ani nahodou vyriesena, toboz nie odpovedov ktoru si oznacil. Ak nie si schopny vidiet dovod preco, vysvetlovat ti to nema zmysel.