| Autor | Zpráva | ||
|---|---|---|---|
| manulka.cz Profil * |
#1 · Zasláno: 30. 11. 2009, 17:54:31
Ahoj! mám takový dotaz. Ošetření pro SQL injection se používá jen tehdy když mám v mysql_query GET, POST či SESSION?? když mám např. že id = 1 tak se to neošetřuje nijak?? a ještě v odkazu typu todle:
<form action="<?=$sekce?>.php?clanek=cl_cely&id_clanku=<?=$zaznam["id_clanku"]?>&id_sekce=<?=$_REQUEST["id_sekce"]?>" method="post"> se REQUEST taky ošetřuje nebo zas jenom v SQL příkazech?? děkuji moc, moc té ochraně nerozumím a to už hledám na webu fakt dlouho :-( takže pomohla by jakákoli pomoc či vysvětlení :-) |
||
| Chamurappi Profil |
#2 · Zasláno: 30. 11. 2009, 18:06:21
Reaguji na manulku.cz:
Je fascinující, jak se lidé učí názvy bezpečnostních děr, ale nezkoumají při tom jejich podstatu. „když mám např. že id = 1 tak se to neošetřuje nijak??“ Hrozí tam, že návštěvník vloží do SQL dotazu nebezpečný kód? „a ještě v odkazu typu todle […] se REQUEST taky ošetřuje nebo zas jenom v SQL příkazech??“ Hrozí tam nějaký útok? Když ti do parametru id_sekce vložím uvozovky a menšítko, jak bude vypadat výsledný kód? |
||
| manulka.cz Profil * |
#3 · Zasláno: 30. 11. 2009, 18:24:24
já se omlouvám za své nedostatečné info, ale tak chybami se člověk učí.
takže když přepíšu např. ten odkkaz na toto: echo "<a href=\"".$_SERVER["PHP_SELF"]."?clanek=info&id_sekce=".intval($_REQUEST["id_sekce"])."&celkem=".intval($celkem)."&od=".intval(1)."\">Začátek</a> | "; Mohlo by to tak být?? |
||
| Chamurappi Profil |
#4 · Zasláno: 1. 12. 2009, 23:51:23
Reaguji na manulku.cz:
„já se omlouvám za své nedostatečné info, ale tak chybami se člověk učí“ Bezpečnostními chybami se spíš mučí. Stačí přemýšlet — vžij se do role imaginární zlé manulky.cz a přemýšlej, jak se hacknout skrze uživatelské vstupy. „intval(1)“ Nemá smysl ošetřovat hodnoty, které nemůžou být podvrhnuté. |
||
| manulka.cz Profil * |
#5 · Zasláno: 3. 12. 2009, 11:53:16
když on je právě ten problém, že si to moc představit neumím :-( právě proto stále moc nechápu co ošetřovat a co ne. Vím, že se všude píše že má smysl ošetřovat sql příkazy, ale když mám odkaz, tak v něm se ty hodnoty taky musí ošetřit nebo tedy ne, když to nemá zde smysl, jak píšeš...
|
||
| unlucky Profil |
#6 · Zasláno: 3. 12. 2009, 14:11:26
mysql_real_escape_string
jinak hrozi, ze vam v url nekdo zada clanek.php?id=1; drop table neco; atdd |
||
| Step Profil |
#7 · Zasláno: 4. 12. 2009, 15:27:07
myslim, že je nejlepší ošetřovat tyhle věci přímo v dotazu, takhle například hrozí, že si někdo přepíše zdrojový kód (třeba v opeře to de) a změní si tam např
id_sekce='... (nevim přesně jak se dělá mysql_injection:-)) , uloží změny a data se nebudou dále ošetřovat tak si útočník může dělat co chce... já např ošetřuji i data ze <select> i když by se zdálo, že data posílaná selectem jsou bezpečná |
||
| panther Profil |
#8 · Zasláno: 4. 12. 2009, 15:30:10
Step:
„že si někdo přepíše zdrojový kód (třeba v opeře to de)“ ano, jde, ale upravený kód se neodešle na server. Tudíž je to jedno. |
||
| Chamurappi Profil |
#9 · Zasláno: 4. 12. 2009, 15:35:00
Reaguji na panthera:
Step chtěl asi říct, že všechny vstupy z formuláře jde podvrhnout a člověk programující serverovou část by jim tedy neměl důvěřovat. |
||
| Step Profil |
#10 · Zasláno: 4. 12. 2009, 15:54:49
Chamurappi:
„Step chtěl asi říct, že všechny vstupy z formuláře jde podvrhnout a člověk programující serverovou část by jim tedy neměl důvěřovat.“ Přesně tak, všechny data od uživatele jsou potenciálně nebezpečná. panther: „ano, jde, ale upravený kód se neodešle na server. Tudíž je to jedno.“ tak to už jsem nikdy nezkoumal:-) |
||
| manulka.cz Profil * |
#11 · Zasláno: 5. 12. 2009, 00:11:50
takže jestli jsem dobře pochopila. i když je REQUEST["id"] např. číslo nebo má být číslo, tak i tak se tam píše mysql_real_escape_string??
|
||
| Joker Profil |
#12 · Zasláno: 5. 12. 2009, 09:30:14
manulka.cz:
Kdybych shrnul pár obecných pravidel: - Vstupy se dělí na důvěryhodné a nedůvěryhodné - Důvěryhodné jsou hlavně ty, které si aplikace vytvoří sama (například když dám $a = 1, tak dál ve skriptu budu věřit, že tam ta jednička opravdu je) - Nedůvěryhodné je hlavně cokoliv, co přijde od uživatele, včetně skrytých políček ve formuláři a políček kontrolovaných Javascriptem (protože to všechno se dá obejít) „i když je REQUEST["id"] např. číslo nebo má být číslo, tak i tak se tam píše mysql_real_escape_string?“ Ne. "Zdůvěryhodnění" základních datových typů se dá udělat takhle: - boolean -> isset() nebo empty() (když mám $vyplneno = !empty($_GET["policko"]); tak v políčku může přijít cokoliv a $vyplneno bude jen true nebo false) - číslo -> více možností, například intval() (výsledkem jakéhokoliv nečíselného vstupu bude 0) - řetězec -> před uložením do databáze se projede mysql_real_escape_string. Samozřejmě tohle jsou jen ty nejobecnější kontroly, na konkrétní vstupy se dá aplikovat ještě spousta dalších (například můžu navíc chtít, aby řetězec neobsahoval nějaké znaky, nebo vím, že číslo musí být od 1 do 10 a podobně. To už záleží na konkrétním vstupu). |
||
| manulka.cz Profil * |
#13 · Zasláno: 6. 12. 2009, 13:58:45
diky moc za vysvetleni, tohle mi urcite moc pomohlo!! :-) takze kdyz jsem mela v tom svym kodu id_sekce=".intval($_REQUEST["id_sekce"]), tak to bylo spravne osetreni??
|
||
| Spacebar Profil |
#14 · Zasláno: 7. 12. 2009, 17:56:53
Hmm.. Když generuješ odkaz a dáváš tam data z databáze, není tam co ošetřovat (pokud už není pozdě).
Jde o to ošetřit vstup, takže třeba místo $id_clanku = $_GET["id"]; dát $id_clanku = intval($_GET["id"]; Takto to aspoň dělám já. Pokud se nejedná o číselný uživatelský vstup, použij místo intvalu funkce, jež ti zaslal Joker. |
||
| manulka.cz Profil * |
#15 · Zasláno: 7. 12. 2009, 18:58:37
oki. to me taky mohlo dojit, coz je pravda :-) a jeste posledni dotazek, kdyz budu mit kod
$vysledek = mysql_query ("select * from clanky where id_clanku = " .intval($_REQUEST["id_clanku"]). ";", $GLOBALS["link"]);tak intval je zde zbytecne nebo ho sem prave musim dat. zrejme ano ze?? |
||
| Spacebar Profil |
#16 · Zasláno: 8. 12. 2009, 14:39:10
Ano. $_REQUEST["id_clanku"] totiž obsahuje vstup od uživatele, který může potencionální hacker změnit.
|
||
|
Časová prodleva: 14 let
|
|||
0