Názory k článku PHP okénko: Escapování

Z urlencode vyleze jeste bonusovy % :) Nicmene v tom manualu chteji rici to, ze se muze stat, ze query string bude *v HTML* vypadat nasledovne: ?foo=bar&amp=win, pricemz &amp muze browser pochopit jako entitu a vysledek pak bude ?foo=bar&=win. Pri pouziti htmlspecialchars() se & zmeni v & a browser to pak pochopi spravne. Opakovani je matka moudrosti a mnoho lidem to nedojde a pak tezko hledaji chybu, proto je to IMHO tam uvedeno. BTW, diky, opet sem nasel zminku o "W3C-suggested semi-colon" :)

Mas pravdu, nikdy. Ale i presto je asi dobry html*() znat :)

Autor zapomněl na jeden, IMHO nejpodstatnější, důvod, proč htmlencodovat data až před tím, než se budou zobrazovat na web. Protože mnohdy s těmi daty potřebujeme provádět i něco jiného, než je rovnou zobrazit na web, (a nebo s nimi pracujeme i z jiných klientů než z PHP) a pak bychom si zbytečně přidělávali práci s jejich zpětným dekódováním. Ze stejných důvodů by bylo záhodno, aby berličky typu magic_quotes_gpc co nejdříve zmizely v propadlišti dějin spolu s dalšími hříchy nezralého mládí, jako register_globals…

Co je az take nezrale na magic_quotes_gpc? Chapem, ze register_globals je riadna sprostost, ale "magic_quotes_gpc on" v default konfiguracii je IMHO velmi dobra vec. Je mnozstvo ludi, ktory pisu PHP a vobec uvazovat o bezpecnosti svojho diela ich ani nenapadne. Potom staci niekde najst odkaz typu:

<a href="?zmaz_id=13">Zrusit ucet</a>

a ked je tento implementovany priblizne takto:

mysql_query ("DELETE FROM ucty WHERE id = '{$_GET['zmaz_id']}'");

tak staci ako zmaz_id zadat \"13\' OR 1 OR \'a\' = \'\" a razom zmazeme celu tabulku. Samozrejme takto je to nespravne, spravne by to malo vyzerat takto:

$id_escaped = addslashes ($_GET['zmaz_id']);
mysql_query ("DELETE FROM ucty WHERE id = '$id_escaped'");

alebo dokonca pre pripad, ze by programator este nieco prehliadol (pri zlozitejsich dotazoch):

$id_escaped = addslashes ($_GET['zmaz_id']);
mysql_query ("DELETE FROM ucty WHERE id = '$id_escaped' LIMIT 1");

Lenze toto by asi nerobil skoro ziaden zaciatonik a mierne pokrocily programator v PHP.

Samozrejme, tomu komu to vadi, ten si moze nastavit HTTP server tak, aby bolo magic_quotes_gpc default off. Pripadne sa to da prenastavit aj pre jednotlive stranky (teda aspon si to myslim, neskusal som to).

Ospravedlnujem sa za to

\"13\' OR 1 OR \'a\' = \'\"

spravne to malo byt

"13' OR 1 OR 'a' = '"

To sposobil ROOT, ked som si zvolil formatovanie textu ako xHTML a stlacil som "Zobrazit nahled". Mal som tam chybu a vsetky apostrofy a uvodzovky mi to escapovalo. Rucne som vecsinu odmazal az na tieto. Toto asi trosku nahrava povodnemu autorovi prispevku ;-), ze magic_quotes_gpc by malo byt off, pretoze na druhu stranu su programatori, ktori zase zabudaju na vhodnych miestach pridat volanie stripslashes() (obak addslashes()). :-(

nebo staci:
1 or true ... a pokud to ma v uvozovkach tak treba:
' or ''='

;]

Vida, jeden z důvodů, proč je automatická konverze špatná, jste už našel sám… :-)

Jasne, staci napisat bash skriptik, ale to je taka vrstevnata ochrana... proste utocnik musi pouzit zase nieco naviac. A pokial nevidi ten PHP kod, tak musi tento trik s LIMIT 1 poznat... A naviac, ak ide o vecsiu tabulku (napr. 1000 zaznamov), utocnik si nemusi vsimnut efekt jedneho zmazania. Alebo ak ide o tu tabulku uzivatelov, tak ten efekt nepojde poznat skoro vobec, proste sa nejaky nahodny uzivatel neprihlasi.

Hřích nezralého mládí je to proto, že je to podobná berlička, která odnaučuje lidi myslet, jako bylo register_globals. Uvědomte si, že s daty, která dostanete přes get/post/cookies, potřebujete často provádět i jiné věci, než je okamžitě a bez jakéhokoli zpracování vrazit do databáze. Pokud máte zapnuté magic_quotes_gpc, budete v takových případech muset provádět zase konverzi zpět, což je hodně nešťastné. Navíc, jak už jsem zmínil, u některých databází se obejdete bez addslashes(), protože nemusíte psát data do dotazu, a opět byste prováděl zbytečnou konverzi tam a zpátky.

P.S. Jinak magic_quotes_gpc pochopitelně nelze zapnout/vypnout až ve skriptu (to už by bylo trochu pozdě).

Nie je to síce úplne to isté, čo vypnutie magic_quotes_gpc, ale ja to úspešne používam:

/**
* Odstrani lomitka z hodnot pola, v pripade potreby aj rekurzivne
*
* @param array $arr Vstupne pole
* @return array Vystupne pole
*/
function unslashArray($arr) {
foreach ($arr as $key=>$val) {
$arr[$key]=(is_array($val) ? unslashArray($val) : stripslashes($val));
}
return $arr;
}

if (get_magic_quotes_gpc()) {
$_REQUEST=unslashArray($_REQUEST);
$_GET=unslashArray($_GET);
$_POST=unslashArray($_POST);
$_COOKIE=unslashArray($_COOKIE);
}

Ve výsledku to sice bude fungovat, ale pořád zůstává neefektivní a zbytečná trasformace tam a zase zpátky.

Jo, moje funkce, kterou jsem to kdysi davno resil ja, vypadala podobne, akorat tam jeste mela ochranu proti moc velky rekurzi. Prece jenom, nebyl to peknej pohled na ty hnusny errory o stack overflow :-)

Asi by bylo vhodné poznamenat, že u některých databází není v PHP funkce addslashes() potřeba vůbec, protože příslušné PHP rozhraní umožňuje předávat data odděleně od vlastního dotazu. Takový postup je mnohem vhodnější, protože odpadají problémy se zapomenutým nebo dvojitým escapováním a snižují se bezpečnostní rizika, plynoucí z takových opomenutí.

ty vole, ses v pohode vole pod dom
ne ja su tak nazranej ja su jak dobytek
ty vole ja mizim vole tvoje stara
jezisi

jezisi kdes byl, ty ses zas vozralej jak hovado
co me na to reknes ?

DEVKO POSERU TI KOZY!

byl sem nalitej jak motyka, jak motyka, sem se stal
byl sem nalitej jak motyka, jak motyka, jak motyka
byl sem nalitej jak motyka, jak motyka, wunderbar
byl sem nalitej jak motyka, jak motyka, jak motyka

.no tak stara zadny strachy
vim do cecho vrazit prachy
kdyz nevis co z lovama
chlastej pivo s korkama
az se budes domu vracet
a budes na patnik zvracet
poznas ze je to krasnej pozitek
vozrat se jak dobytek

blijeeem

byl sem nalitej jak motyka, jak motyka, rumu par
byl sem nalitej jak motyka, jak motyka, jak motyka
byl sem nalitej jak motyka, kokakola nedobra
byl sem nalitej jak motyka, jak motyka, jak motyka

ja kazdej den jenom piju
alkoholem proste ziju
poznal sem to napoprve
ze promile mam misto krve
uz du zase bumbat slivku
dva rumy si davam k pifku
uz se tesim jak se pobavim
az to vsechno zase vydavim

byl sem nalitej jak motyka, jak motyka, interspar
byl sem nalitej jak motyka, jak motyka, jak motyka
byl sem nalitej jak motyka, kokakola satan zlo
byl sem nalitej jak motyka, jak motyka, jak motyka

musim se jit vychcat
musim se jit vychcat
sem jako houba nasatej
tak musim se jit vychcat

byl sem nalitej jak motyka, jak motyka, zplundrovan
byl sem nalitej jak motyka, jak motyka, jak motyka
byl sem nalitej jak motyka, kokakola satan zlo
byl sem nalitej jak motyka, jak motyka, jak motyka

Hlavní, že neskočíš do bazéééna!

zdravime root.cz :-)

Teda přátelé, to stím escapováním dat před ukládáním myslíte vážně? Není bezpečnějčí, elegantnější a "blbuvzdornější" použití navazování proměnných (omlouvám se překlad). Lepení vstupu do sql je kořenem všeho zla, použijte navazování proměnných. Viz. ospověď z jedné renomované databázové poradny:


oh, defending against SQL injection is trivial!!! really, it is.

Just never accept inputs from the end user that you glue into a sql
statement.

That's it -- never have something passed to you from the outside (outside YOUR
CODE) that becomes part of the query! SQL injection = thing of the past.

It is not dynamic sql that is the issue (all sql is dynamic in Oracle actually
-- even static sql in pro*c/plsql!). It is "the construction" of this sql that
is the problem.


If a user gives you inputs - they should be BOUND into the query -- not
concatenated. The second you concatenate user input into your SQL -- it is as
if you gave them the ability to pass you code and you execute that code. Plain
and simple.

Don't concatenate, but rather bind their inputs, and wah-lah, you are done.


The way to prevent it is via coding standards and design review. And -- best of
all -- at the end of the day, we achieve that nirvana that is "the applications
use binds!"

Nelze než souhlasit, ale nepsal jsem tu v podstatě to samé už 18.4. v 0:58? :-)

Ano, jinými slovy. Pokud nás bude víc, třeba je přesvědčíme. Bohužel jsem se ke svým oblíbeným webům dostal v tomto týdnu až dnes.

Ja to asi uplne nechapu... Moh by tady nekdo uvest ukazku tohodle postupu? Dik!

Hmmm, to je fajn, dik za info!