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

No ja radsi escapuju pri ukladani, clovek tam pak muze v pripade potreby vlozit rucne kus html.

BTW chape nekdo popis urlencode v PHP manualu, myslim ten konec o htmlentities? IMHO z urlencode vzdycky vyleze jenom
a-zA-Z0-9-_.+
ne?

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" :)

Ale v tom manualu je primo ukazka:
htmlentities(urlencode($userinput))
a ja se ptam: kdy muze z urlencode() vylizt neco, co htmlentities() zkonvertuje? IMHO nikdy, ne?

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

Ale zase, ze by meli v tom manualu takovej nesmysl?

V manuálu byl skutečně nesmysl, opravil jsem to v CVS.

Good job, chtel jsem napsat, ze by bylo vhodny "file a bug report" (a myslel pritom prave na tebe :P, ale uz je to zbytecny, so, diky..

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.

jj, ale ak server nemám vo vlastníctve a neviem donútiť vlastníka aby magic_quotes_gpc vypol, tak je to lepšie než zostávajúce 2 možnosti:
1) preprogramovať celú svoju aplikáciu, vrátane knižníc, ktoré si pestujem už roky
2) nechať to tak, a odporučiť klientovi, nech do formulárov nepíše apostrofy, úvodzovky a spätné lomítka

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 :-)

Z princípu do $_GET ani do $_COOKIES sa veľmi dlhé polia nedostanú (jedno aj druhé má obmedzenú veľkosť), takže jedine v $_POST by sa mohli vyskytnúť dáta, na ktorých by to havarovalo... Ale to by ich muselo byť DOSŤ veľa. Nedá sa odoslať taký HTTP request na PHP, ktorý by vygeneroval pole $_* so spätnými referenciami do samého seba (čím by mohli vzniknúť cykly na ktorých by došlo k stack overflow). Obvykle nePOSTujem polia s vnorením väčším než 2, ani dáta o celkovej veľkosti väčšej než pár desiatok kB, takže toto "riešenie" mi postačuje. ;-)

To není dobrý přístup. Kde berete jistotu, že vám tam někdo nepošle něco mnohem většího (nebo zamotanějšího)? Nebo ty aplikace používáte jen vy sám?

Existuje niečo ako špecifikácia, a keď sa s klientom dohodneme na tom, že to a to pole bude max takto dlhé, tak klient musí rešpektovať, že v prípade prekročenia limitov je správanie nedefinované. V podstate môžme byť ešte obaja (klient a ja) radi, že sa to sekne hneď na začiatku, a nie niekde uprostred insertovania, deletovania, či updateovania. Anyway. Formulár, do ktorého klient chce narvať viac než 100k dát (nepočítam file upload) je zrelý na rozdelenie na menšie samostatné časti.

Vy mne děsíte čím dál víc. To opravdu zabezpečujete své aplikace právními doložkami? Připadá mi to jako "ochrana" některých komerčních produktů z poslední doby. Šifrovací algoritmus je sice slaboučký, ale pokusy o jeho prolomení jsme úředně zakázali, takže je to vlastně bezpečné… :-)

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!

Ještě tam chybí zmínka o funkci htmlentities. Tedy o tom, že je by se jí měl každý velkým obloukem vyhnout.
Když se použije při generování HTML, tak ještě moc velkou škodu nenadělá. Ale občas ji někdo použije při generování XML :-(

Pokud používáte magic_quotes_gpc, pak musíte vždy pamatovat na stripslashes pokud vstup například vypisujete, ukládáte do souboru, posíláte mailem apod.
Zvlášť nepříjemný to je u formulářů, které po server-side validaci nabídnou zpátky formulář se vším co uživatel zadal, ale všechno \"vyslashovaný\".

Je to sice lepší varianta, než kdybychom měli magic_quotes_gpc vypnutý a zapoměli addslashes, ale s tímto přístupem bychom mohli zavést i automatické htmlspecialchars a rawurlencode.
Prostě prosazuji zásadu slashovat jen to co je potřeba!

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!

Myslí se tím nemíchání SQL dotazů s daty. Některé extenze (např. MySQL) to přímo nepodporují, jiné ano (např. MySQLi), existují také knihovny, které to zařídí (např. PEAR::DB). Kód pak může vypadat nějak takhle:

$stmt = $mysqli->prepare("SELECT * FROM tabulka WHERE nazev = ? OR id = ?");
$stmt->bind_param("si", $_GET["nazev"], $_GET["id"]);
$stmt->execute();

Žádné addslashes() pak není potřeba.

Hmmm, to je fajn, dik za info!