ugrás a tartalomhoz

Htmlentities és az sql injection elleni védekezés

Anonymous · 2005. Aug. 30. (K), 17.14
Helló!

Három kérdésem lenne:

1. a HTML tagek teljes blokkolására (hogy ne jelenítse meg őket) elég-e a htmlentities (eddig elégnek bizonyult)?

2. ha bizonyos tageket engedélyezni akarok (pl. <b>, <i>), akkor azt hogyan tehetem meg? van-e erre függvény, vagy azt nekem kell megírnom?

3. hogyan lehet hatékonyan védekezni a rettegett sql injection ellen? mert a névvel, jelszóval nincs gond, de mi van pl. egy fórum hozzászólásával?
‹ Adatok betöltése külső fájlból PHP-ben Egy szám és két választott űrlapmező feldolgozása PHP-vel ›
 ■
1

cross site scriptin, sql injection

Hojtsy Gábor · 2005. Aug. 30. (K), 17.53
Két dologról van szó. Az első és második kérdés az XSS témaköre. Azok ellen a htmlspecialchars(), htmlentities() és strip_tags() függvényekkel tudsz védekezni. Az utóbbival lehet megtartani bizonyos elemeket, de mivel az attribútumokat is megtartja, JS-t minden gond nélkül be lehet ágyazni, azzal meg minden mást, úgyhogy védekezésre nem alkalmas. Az SQL injection ellen pedig az adott SQL adatbázis kezelő escape függvényével kell védekezni, pl. sqlite_escape_string(), mysql_escape_string(), pg_escape_string(), stb. Minden SQL parancs veszélyes lehet, a felhasználói név és jelszó bekérő is.
2

<Nincs cím>

Anonymous · 2005. Aug. 30. (K), 19.43
1-2.

Ok, de akkor hogyan oldjam meg, hogy bizonyos tagek megjelenjenek? Saját függyvényt kell hogy írjak? Itt a weblaboron hogyan oldják meg?

3. A felhasználó név és a jelszó esetemben azért nem lehet veszélyforrás, mert mielőtt bármilyen lekérdezést végrehajtanék, ellenőrzöm, hogy tartalmaz-e "kritikus karaktereket".
Úgyhogy marad a szöveg, amire jó lesz-e nekem ez:

if (!get_magic_quotes_gpc())
{
   $szoveg=mysql_real_escape_string($szoveg);
}

#mehet az adatbázisba rögzítés most már
Elég ez így?
3

1, 2, 3

Hojtsy Gábor · 2005. Aug. 30. (K), 20.11
Nos, a Weblaboron nem engedünk HTML-t beírni, furcsa, hogy ez nem tűnt fel :) Tehát saját leíró nyelvet csináltunk (na jó, a bbcode-ot használtuk fel), amit viszont úgy dolgozunk fel, hogy ne legyen gond. Saját függvényt kell írnod, ha a HTML tisztogatásával akarsz foglalkozni, vagy új nyelvet akarsz adni. Illetve választhatsz meglévő megoldásokat: bbcode, markdown, textile, stb.

Ami az SQL injectiont illeti, azért nem szerencsés, amit használnál, mert ha $szoveg véletlenül nem a PHP HTTP bemenetéről jön, hanem mondjuk fájlból, vagy adatbázisból, és be van kapcsolva a magic_quotes, akkor nem lesz rajta semmilyen escape, és ez nem csak betörési, hanem különben is hibalehetőség. Azt szokták csinálni, hogy a magic_quotes hatását a szkript elején visszafordítják (ha különben nem tudják kikapcsolni), és a továbbiakban minden adatot kezeletlennek tekintenek. Amit a magic_quotes csinál, az nem ekvivalens a mysql_real_escape_string() hatásával, ezért sem helyes a megközelítés.
4

Miért mysql_escape_string() és nem magic_quotes_gpc?

fberci · 2005. Aug. 30. (K), 20.29
Azt szeretném megkérdezni, hogy a mysql_escape_strint() (vagy a real_escape), miért biztonságosabb, mint a magic_quotes, ha minden adat kívülről jön?

Üdv.: fberci
7

tessék elolvasni

Hojtsy Gábor · 2005. Aug. 30. (K), 21.28
Mindkettőnek van dokumentációs lapja, látszik, hogy nem ugyanazt csinálják, a mysql_real_escape_string() sokkal konkrétabban működik a MySQL igényeire szabva, a karaktersorozat végét jelző nulla bájtokat és hasonlókat is escapeli.
5

1,2 rendben, 3...

Anonymous · 2005. Aug. 30. (K), 20.55
Ami az SQL injectiont illeti, azért nem szerencsés, amit használnál, mert ha $szoveg véletlenül nem a PHP HTTP bemenetéről jön, hanem mondjuk fájlból, vagy adatbázisból, és be van kapcsolva a magic_quotes, akkor nem lesz rajta semmilyen escape, és ez nem csak betörési, hanem különben is hibalehetőség.


Hát, ez igaz...

Így jó (jobb)?

if (get_magic_quotes_gpc())
{
   $szoveg=stripslashes($szoveg);
}

$szoveg=mysql_real_escape_string($szoveg);
6

egyáltalán nem jobb

Hojtsy Gábor · 2005. Aug. 30. (K), 21.26
Jobb, ha a $szoveg tuti, garantáltan, teljesen biztosan HTTP bemenetről jön. Különben velejéig rossz, mert az esetleges (legitim) visszapereket szépen kiszedi. Ezért szoktak magic_quotes nélkül fejleszteni, és ha mégis van, akkor a szkript elején minden beviteli változóra visszafordítják a hatását. De mintha ezt már itt sem először írnám.
8

De akkor hogyan

Anonymous · 2005. Aug. 30. (K), 21.57
Ezért szoktak magic_quotes nélkül fejleszteni, és ha mégis van, akkor a szkript elején minden beviteli változóra visszafordítják a hatását. De mintha ezt már itt sem először írnám.


Akkor ha nagyon szépen megkérlek elmondanád nekem (is), hogy hogyan is kell ezt rendesen csinálni (ha feltételezzük, hogy a magic_quotes be van kapcsolva)?
9

dispelMagicQuotes()

Hojtsy Gábor · 2005. Aug. 30. (K), 22.31
Lásd Richard Heyes dispelMagicQuotes() kódját. Figyeld meg, hogy a dispelGlobals()-ra későbbi blog bejegyzésben sokkal biztonságosabb kódot ad.