ugrás a tartalomhoz

Karakter tiltás URL-ben

Anonymous · 2006. Feb. 21. (K), 22.31
Szeretném minimásisra csökkenteni az SQL injection és más módszerekkel történő támadási kísérletek lehetőségét. A számos védekezés közül most konkrétan az URL-ről kérdeznék. A PHP elején, még mielőtt bármi történne, lefuttatok egy for ciklust, amiben leellenőrzöm a query stringet. Ha találok benne olyan karaktert, amivel SQL injection lehettséges, akkor kilépek a programból. A kérdés csak az, hogy milyen karaktereket érdemes keresni, azaz milyen karakterekkel lehettséges módosítani úgy egy linket, hogy azzal támadást lehessen intézni az oldal felé?
Összeszedtem már néhányat, csak kíváncsi lennék profik véleményére, mellesleg a feleslegeseket kigyomlálnám, ezzel is csökkentve a futási idejét (bár ez nyílván szinte nem is mérhető).
‹ MYSQL adatbázisból való kiolvasás... Naplózás megvalósítása PHP hibaüzenetekkel is ›
 ■
1

<Megint nincs cím>

-zsolti- · 2006. Feb. 21. (K), 22.58
lefuttatok egy for ciklust, amiben leellenőrzöm a query stringet
Nem kell a spanyolviaszt feltalálni, vannak erre megfelelő mysql_escape_string, mysql_real_escape_string, addslashes függvények. Használd azt a post/get/cookie adatok megvizsgálására, de normálisan konfigurált szerver esetén (magic_quotes_gpc) már eleve kevés az esély ilyen támadásokra.

Én egyébként úgy csinálom, hogy már a környezeti oszályom legelején array_map-pel bejárom a post/get/cookie szuperglobális tömböket (mysql_escape_string) így később a programban erre már nem kell figyelni, mindenhova biztonságosan jutnak el az adatok.
2

<Nincs cím>

Anonymous · 2006. Feb. 21. (K), 23.15
Nem kell a spanyolviaszt feltalálni, vannak erre megfelelő [...] függvények.

Meglehetősen komplex rendszerről van szó, és az említett függvények használatát sajnos elhanyagoltam az elején... Utólag nem kis meló lenne, ezért trükközök a query string csekkolással - tehát nem spanyol viasz feltalálásról van szó.

Esetleg egy példát tudnál mutatni, hogy hogyan is kellene felépíteni ezt az osztályt, ami lecsekkolja a szuperglobáliasaimat?
6

Array_map

-zsolti- · 2006. Feb. 22. (Sze), 00.05
Pl:
$_GET = array_map('mysql_real_escape_string', $_GET);
Vagyis a $_GET tömb minden elemére alkalmazza a mysql_real_escape_string függvényt. Igazából csak egy kis könnyítés, ezáltal ha egy ilyet futtatsz az oldal elején, később már nem kell escaplened külön-külön az sql-be kerülő adatokat.
7

<Nincs cím>

Anonymous · 2006. Feb. 23. (Cs), 11.18
Hmm. Azt hittem, ennél kicsit bonyolultabb lesz :) Megnézhettem volna a manualban is ... és akkor nem fárasztalak itt benneteket :) Mindenesetre köszönöm :)

Mialatt utánaolvastam a dolgoknak, tallátam egy ilyet:

<?php

if (!get_magic_quotes_gpc()) {

	$var = addslashes($var);

}

?>
Ennek van értelme, igaz? Mármint arra gondolok, hogy mielőtt tényleg alkalmaznám a mysql_real_escape_stringet, érdemes lecsekkolni, hogy a magic_quotes ki vagy be van-e kapcsolva...?
8

*ab*_real_escape_string()

Dualon · 2006. Feb. 23. (Cs), 11.55
Az addslashes nem egyenértékű az adatbáziskezelő függvények escape megfelelőivel! Előbbi a
', ", \, NUL
karaktereket kódolja, utóbbi a
NUL (ASCII 0), \n, \r, \, ', ", és Control-Z
karaktereket. Stringek adatbázisba vitelénél - vegyük a MySQL esetét - a mysql(i)_real_escape_string használata ajánlott.

Ha SQL Injection ellen védekezel, érdemes figyelni a karakterkódolásokra is egyes UTF-8-as esetekben. Nem véletlen a "bizonytalan" mondat: nemrég volt blogmarkban egy cikk, amiben írtak erről, de nem találom...

Az XSS támadások, cross-site scripting ellen tudtommal többé-kevésbé véd az addslashes, ráadásként én még a (, ), <, >, valamit ; karaktereket szanálnám a query stringből. (Az általam ismert egyik legjobb XSS témájú oldal ez.)

Remélem, kiegészít még valaki, ha kell; engem is érdekel a téma.

Szerk.: Igen, a magic_quotes_qpc-t mindenképp figyelni kell, hogy a már "megtisztított" stringet ne nyomd tele újra escape karakterekkel.

D.
http://e-arc.hu/
9

Korrekt

Anonymous · 2006. Feb. 23. (Cs), 12.12
Köszönöm a választ.
12

Hibás megközelítés SZVSZ

Hodicska Gergely · 2006. Már. 5. (V), 02.56
normálisan konfigurált szerver esetén (magic_quotes_gpc) már eleve kevés az esély ilyen támadásokra

Normálisan konfigurált szerver messziről elkerüli a magic_quotes használatát. Igazából semmire sem jó, a PHP egyik nagyon elhibázott húzása, nem véletlenül van mysql_real_escape_string.

Én egyébként úgy csinálom, hogy már a környezeti oszályom legelején array_map-pel bejárom a post/get/cookie szuperglobális tömböket (mysql_escape_string) így később a programban erre már nem kell figyelni, mindenhova biztonságosan jutnak el az adatok.

És mi van akkor, ha nem adatbázisba szeretnéd beszúrni a cuccot? Például levélküldés elég gyakori. Én azt a megközelítést szeretem, hogy az elején ellenőrzöm, hogy van-e magic_quotes, ha igen eliminálom, az escapelés pedig az adatbázis réteg feladata, hisz csak annak használata esetén van értelme, ráadásul így DB-függő lesz az escapelés, nem egy adott adatbáziskezelő esetében fog működni.


Felhő

u.i. Plusz ne felejtsük el, hogy a mysql_real_escape_string, illetve magaz az escapelés sem old meg minden problémát.
13

Pont ezen gondolkoztam anno

Dualon · 2006. Már. 5. (V), 04.19
Megnyugtatsz: pont azon gondolkodtam, hogy a Manual szerint a magic_quotes bekapcsolt állapota nem ajánlott, ennek megfelelően én is végigjárom a GPC (R) tömböket, és magam escape-elek később, ha kell.

Arra viszont kíváncsi lennék, mit hagy figyelmen kívül a - pl. - mysql_real_escape_string. Mire kell még figyelni?

D.
http://e-arc.hu/
14

multi query, LIKE

Hodicska Gergely · 2006. Már. 5. (V), 12.46
Például több DB API támogatja, hogy egyszerre több queryt is végrehajthatsz, de a ;-t nem tekinti az escapelő függvényük speciális karakternek, ezért pl. a következő példa támadható az escapelés ellenére is:
<?php
$_GET['id'] = "0; DELETE FROM users";
$_GET['id'] = pg_escape_string($_GET['id']);
pg_query($conn, "SELECT * FROM users WHERE id=".$_GET['id']);
?>
Erre megoldás, ha számok esetén is a paramétereket aposztróffal vesszük körbe:
<?php
$_GET['id'] = "0; DELETE FROM users";
$_GET['id'] = pg_escape_string($_GET['id']);
pg_query($conn, "SELECT * FROM users WHERE id='".$_GET['id']."'");
?>
Ebben az esetben az eredmünyül kapott query hibás lesz.

A másik eset pl.: ha LIKE-ot használunk, akkor az escapelés a % és _ karaktereket nem escapeli, ezért mi hiába az input%-ra keresünk, a felhasználó nyugodtan be`rhatja a keresés elejére a %-ot. Ezáltal a DB már nem fog tudni indexet használni, így ez alkalmas lehet DoS támadásra. Ez ellen jó lehet a addcslashes használata.


Felhő
19

Köszönöm!

Dualon · 2006. Már. 6. (H), 07.50
D.
15

Ellenőrzés nálam is van...

-zsolti- · 2006. Már. 5. (V), 13.01
...és csak ebben az esetben kerülnek escapelésre ha !get_magic_quotes_gpc(). Ha van, akkor striplashes és utána escape_string. (Levélküldéshez se engedek spec. karaktereket, és cookieba(-ból) se.)
16

Spec karakterek emailben?

Hodicska Gergely · 2006. Már. 5. (V), 14.27
Levélküldéshez se engedek spec. karaktereket

Mi köze van az SQL vezérlő karaktereknek az emailhez?
Ráadásul rossz adatot fogsz küldeni ha levélben használod az így kezelt inputot: "isn't" => "isn\'t".


Felhő
17

<Nincs cím>

-zsolti- · 2006. Már. 5. (V), 14.45
Mi köze van az SQL vezérlő karaktereknek az emailhez?

Csak erre reflektáltam (ha nem lenne érthető):
Például levélküldés elég gyakori.

Egyébként pedig mindenki úgy használja ahogy jólesik, én például így. Akinek ez nem tetszik, vagy tud jobbat, az meg máshogy, ennyi.
18

fejlődés

Hodicska Gergely · 2006. Már. 5. (V), 15.19
Egyébként pedig mindenki úgy használja ahogy jólesik, én például így. Akinek ez nem tetszik, vagy tud jobbat, az meg máshogy, ennyi.

Meg lehet menetközben finomítani a használt technikákon. ;)
Én sem ezzel a megoldással kezdtem. De persze nem kötelező.


Felhő
3

Rossz a megközelítés!

pp · 2006. Feb. 21. (K), 23.15
Nincsenek gonosz karakterek! A magic_quotes_gpc=on éppen ezt a célt szolgálja, bár nem jelent minden estre gyógyjrírt.

Fontos az is, hogy értelmes hibaüzeneteket írj ki, mert nem biztos, hogy mindenki a te szerveredet fogja támadni, lehet, hogy valami más hiba miatt próbálnak meg rossz adatokat küldeni neked.

pl.:
I'am ready
írja be a felhasználód, te meg nem írsz ki semmit, mert beírta a gonosz karaktert.

http://weblabor.hu/blog/20030826/wfszbiztonsagi

pp
4

<Nincs cím>

Anonymous · 2006. Feb. 21. (K), 23.33
Azt nem mondtam, hogy nem írok ki semmit, nyílván hiba esetén tudatom a felhasználóval, hogy mi és miért történt. Egyébként $_GET-el semmi esetre nem küldenék lyan adatot, hogy "I'am ready", szal ha ilyet találnék a query stringben, akkor élből el is küldeném melegedni, mert nyílvánvalóan nem úgy használta a programot, ahogy azt használni kell :)

A cikknek viszont nekiugrok, érdekesnek ígérkezik. Köszönöm.
5

Kereső -> GET

-zsolti- · 2006. Feb. 22. (Sze), 00.01
Miért? Keresőket pl. rendszerint GET-tel szokás elintézni, hogy könyvjelzőzhető legyen a találati oldal. És miért ne kereshetnék az O'Reilly szóra? (Más kérdés, hogy itt nem (csak) escapelni kell a stringet, hanem az entitás kódjára átalakítani, na de akkor se utasítsd el emiatt a felhasználót.)
10

<Nincs cím>

Anonymous · 2006. Feb. 25. (Szo), 14.57
Próbálgattam ezt a dolgot, de valami nem stimmel.

<?php

mysql_connect("localhost", "root", "");
mysql_select_db("test");

function mysqlbe ($src) {

	if (!get_magic_quotes_gpc()) {

		$src = mysql_real_escape_string($src);

	}

	return $src;

}

if ($_POST) {

	echo mysqlbe($_POST["input"]);

	mysql_query("INSERT INTO tabla VALUES ('". mysqlbe($_POST["input"])."')");

}

mysql_close();

// Ez megy az inputba: \x00 - \n - \r - \ - ' - " - \x1a
// Ezt írja ki: \\x00 - \\n - \\r - \\ - \' - \" - \\x1a
// És ez van az adatbázisban: \x00 - \n - \r - \ - ' - " - \x1a

?>

<form action="index.php" method="post">
  <input type="text" name="input" />
  <input type="submit" />
</form>
Ez így oké, php.ini-ben magic_quotes_gpc on és off állásán is hozzáteszi a visszaper jeleket. Egészen addig, amíg nem csak kiiratom, hanem el is küldöm az adatbázisba. Csak arra tudok gondolni, hogy maga a MySQL veszi le róla a visszapert, vagy nem tudom, nem értem... Ennek így kell működnie, vagy mit néztem el?
Szerver:
- WinXP Pro
- WAMP v1.6.1
-- Apache v2.0.55
-- PHP v5.1.2
-- MySQL v5.0.18
11

Senki?

Anonymous · 2006. Feb. 28. (K), 13.00
Valaki csak tudja, hogy ennek így kell-e működnie...? :)