[ Webhosting profitux.cz ]
v6ak [ programování, bezpečnost, web, php, java, ... ] (Vít Šesták)
Buzz - v6ak Twitter - v6ak

štítky

Co je špatného na magic_quotes_gpc?

Docela často vidím používání direktivy magic_quotes_gpc a spolehání se na ní. Podle mého názoru vede často ke špatně napsaným skriptům, proti SQL injekci nemusí vždy pomoci, může pomoci k HTML injekci (a tím k XSS), nemusí to být kratší a může způsobit pěkný zmatek. Proč? To můžu ukázat a vysvětlit. Zde.

Abych byl optimista, přidám například i informace, jak je možné většinou tuto věc vypnout. I na freehostingu!

Celý článek je zde.

diskuze

web
mail
comment
  1. PMaxim

    Zdravím. Nevím zda už tento článek není starší a někdo mi odpoví... Souhlasím s auterem že magic_quotes_gpc je špatný (dokonce si myslím že celý php je špatný:-)). Zajímalo by mě jak lze útočit přes "SQL injekce kvůli rozdílné znakové sadě"?. Vím o podvržení stringu ve tvaru hex..

    2.5.2008 17:14:46
    29
  2. [1] No především je potřeba si uvědomit, že znaková sada už dávno není něčím, co mapuje skupiny osmi bitů na nějaký znak, přičemž některé znaky jsou pro všechny společné.

    Dnes v praxi platí jen to poslední. Ale znak=8b platit dávno nemusí. Ani mnohdy neplatí, že znak = konstantní počet bitů.

    Obě změny mohou být zdrojem problémů, pokud se s nimi nepočítá. První kdysi způsobovala například kdysi XSS zranitelnost v GMailu - řetězec byl escapován pro utf-8 i když je zpráva v utf-7. Pochopitelně, v utf-8 je to chápáno jako úplně jiné znaky (navíc možná nevalidní), takže escapování zde není účinné.

    Dále, znaková sada utf-8 má proměnlivou délku znaku. Pro nejběžnější znaky se používá 8b, pro méně běžné 16b atd.. To, zda se ke znaku přidá další bit, rozhoduje AFAIK první bit v byte - 0 = toť vše, 1 = pokračujeme.

    Pokud bychom escapovali pro jinou znakovou sadu, například iso 8859-1, pak vícebytový znak bude považován za několik znaků. Kdyby však "uživatel" na konec řetězce napsal znak >= 128 (znak s prvním bitem 1), budeme escapovat pro např. iso-8859-1, ale s DB budeme komunikovat v UTF-8, pak po sřetězení nejspíš poslední znak splyne s nejbližším dalším, s apostrofem, čímž se "naleptá" SQL dotaz. Pokud bude uživatel do jednoho dotazu vkládat dva po sobě jdoucí řetězce, SQL injekce by měla být hračka.

    Zatím je to jen teorie, nevyzkoušel jsem.

    Pokud použiješ třeba PDO::quote nebo mysql_real_escape_string, pak by se mělo kódování pro escapování brát ze spojení a problém by neměl nastat.

    2.5.2008 20:13:00
    30
  3. Tak teď ten bot snad už dospamoval... možná tu ochranu čeká ještě drobná úprava, ale nic těžkého. Chci ale vyzkoušet, zda to bude fungovat i bez ní.

    Byla to hrůza, poprvé se mi podařilo překročit denní limit u SMS e-mailu.

    No nic, tak jdu hromadně mazat...

    15.9.2008 19:54:57
    149
  4. někdo se asi odkázal do budoucnosti 150:] někdo se asi odkázal do budoucnosti 151:] někdo se asi odkázal do budoucnosti 152:] Řekli jste si o to! Měním strukturu formláře, aby vám byla cache na nic!

    15.9.2008 20:00:08
    153
  5. Tak jsem se jich snad zbavil. Můj příspěvek [4] je už rozbitý, prtože reaguje na neexistující komentáře. Chvíli to tu tak nechám a když uvidím, že se nic nedějě, uklidím to tu po bitvě.

    15.9.2008 20:33:09
    154

Máte jiný názor než já? Spletl jsem se někde? Něco jsem zapoměl? Něco chcete doplnit? Nebo chcete jen reagovat na jiný komentář? Tak od toho to tu je diskuze!

Pravidla

Formátování

Používají se tu následující způsoby formátování:

jméno
web autora
text

Linkování

Líbí se Vám tato stránka? Zalinkujte ji!

Chcete sledovat novinky? Pokud si právě prohlížíte článek a hledáte RSS pro celý web, pak jste trošku jinde. Možná hledáte poslední změny.

Validní HTML 4.01 StrictValidní CSS 2.0Validní hlavní RSS kanálPHP 5Apache
referer: UA:CCBot/2.0 (http://commoncrawl.org/faq/) time:0.09426600 1508567053
web
mail
comment