| Autor | Zpráva | ||
|---|---|---|---|
| luma64 Profil |
#1 · Zasláno: 11. 8. 2020, 19:16:22
Pozdravujem !
V prvom rade, viem že v súčasnosti sa pre zvýšenosť bezpečnosti používajú paramterizované odkazy. Takto už kódujem teraz. Mám však staré kódy, ktoré chcem overovať pri/po odovzdávaní parametra v url, kým icj neprekódujem. Je to partizánčina :). Na to som si teraz urobil tabuľkum kde sú kľúč. slová, ktoré sú neprípustné. Validujú sa s url odkazom, Vyzerá to nasledovne: Najprv prečítam url: foreach ($_GET as $name => $value)
{
//vytvorím reťazec, ktorým budem prechádzať vo validačnej funkcii
//nepovolené kľúč slová sú v tabuľke s názvom 'nepripustne'
$post_all = $post_all.' '.$value;
}Nepovolené, kľúčové slová v tabuľke 'nepripustne', sú napríklad (select, insert, delete, drop, while, *, atď ). Vytvorenú (vyskladanú) hodnotu z url posielam na validáciu do funkcie check.php $vstup_form = $post_all;
include ("check.php");Časť check.php: $stmt = $pdo->prepare("Select id, nepov_text from nepripustne where id > :id ");
$stmt->bindValue(':id', $id);
$stmt->execute();
foreach ($stmt as $row)
{
$id_nepov = $row['id_nepov'];
$nepov_text = $row['nepov_text'];
if ( (strcasecmp($nepov_text, $value) == 0) )
{
//totožné výrazy
//echo "<br><h2>V URL je nepovolený výraz '$nepov_text'</h2>";
$nepokracuj = "ANO";
$pole = $value;
break;
}
else
{
echo "<br>Tento výraz je povolený : $nepov_text";
}
}Je to správne riešenie problému, ktorým zabránim vykonaniu sql výrazu kým neprekódujem staré kódy na parametrizované ? Samozrejme, ďalším krokom je kontrola vstupných parametrov ( napr numerická hodnota). Vďaka ! Lubo |
||
| Kajman Profil |
#2 · Zasláno: 11. 8. 2020, 20:49:51
Myslím, že to není dobré řešení.
|
||
| luma64 Profil |
#3 · Zasláno: 11. 8. 2020, 21:06:42
A možem poprosiť o stručné nasmerovanie ako čím viac ošetriť starý kód kým sa ho podarí prekódovať aby spĺňal parametrizované vykonávanie sql príkazov. Napríklad už ako som uviedol, na vstupe.
|
||
| Kajman Profil |
#4 · Zasláno: 12. 8. 2020, 00:37:52
Vypnout, než se opraví.
|
||
| Keeehi Profil |
#5 · Zasláno: 12. 8. 2020, 02:32:05
luma64:
Analyzovat vstup nejde. Prakticky by sis musel napsat vlastní parser SQL jazyka aby to k něčemu vůbec možná bylo. Navíc ani pak by to nemuselo být v pohodě. Například na iOS existovala zranitelnost, která byla zapříčiněna tím, že se používaly 3 různé parsery XML. Na invalidním vstupu fungovaly dobře ale s trochu invalidním vstupem si každý poradil jinak a to zapříčinilo tu zranitelnost. Mnihem lépe udeláš, když čas co bys trávil nad řešením tohoto problému raději věnuješ do opravy těch nebezpečných míst. |
||
| mckay Profil |
#6 · Zasláno: 13. 8. 2020, 09:06:34
Záleží asi také na tom, co z těch get parametrů taháte. Plně se ztotožňuji s tím, co rádi diskutující výše, ale možná takové nenáročné řešení jak ošetřit některá aktuálně zranitelná místa by bylo používat whitelist a příhodné konverze datových typů.
Pokud víte, že parametr bude číselné ID, před konkatenací do SQL stringu na to aplikujte funkci intval(), která zajistí, že to číslo bude.
V místech kde například něco radite dle nějakého názvu, nebo podmíněně zobrazujete, porovnejte řetězec z query stringu na rovnost s Vám předem znamymi hodnotami z whitelistu. |
||
| Keeehi Profil |
#7 · Zasláno: 13. 8. 2020, 09:17:34
mckay:
To ale vyžaduje aby upravil kód na všech místech. Když už to bude upravovat na všech místech, to už to může upravit rovnou tak jak to má být. Jemu by pomohlo, kdyby existovalo nějaké magické řešení, které by se vložilo jednou na začátek, to by nějak ošetřilo hodnoty proti sql injection a bylo by hotovo. Žádné takové řešení ale neznám. |
||
| luma64 Profil |
#8 · Zasláno: 13. 8. 2020, 10:11:50
Keeehi:
Žiaľ, pri tom množstve php stránok, kým ich prekódujem, je momentálne zabezpečiť problém. Preto na úvod každej stránky predpokladám vložiť funkciu, ktorá rozloží názov url a ten porovná s nežiadúcimi sql výrazmi. Aj toto sa dá obísť. Uvedomujem si, čo som písal už v úvode, že najjednoduchšie je prejsť na kódovanie predpripravenými príkazmi. Ale súčasný stav a množstvo php stránok mi to ihneď neumožňuje. Takže toto je dôvodom patlania zabezpečenia. |
||
| luma64 Profil |
#9 · Zasláno: 15. 8. 2020, 09:57:26
Ešte by som sa vrátil k tomuto príspevku...spúšťam aplikáciu, ak prebehla autentifikácia v poriadku, dynamicky sa vytvára url , napr.
test.php?id=$id ; Ale to môže byť aj napríklad volanie stránky s obyčajným podľadom na dáta, kde sa posiela do takej stránky len dátum: pohlad.php?datum="2020-08-15"; |
||
| Keeehi Profil |
#10 · Zasláno: 15. 8. 2020, 11:30:29
luma64:
To jako pro uložení toho kdo je přihlášen nepoužíváš session? |
||
| luma64 Profil |
#11 · Zasláno: 15. 8. 2020, 11:51:32
Samozrejme, že používam. Zrejme, máš na mysli podmienku (doretaz som ju neaplikoval)
if ( session_id_uzivatela == get uzivatela z url )
{
... je to ok
}
else
{
..niekto neočakávaný
..exit
}Prípadne: if ( login_zo_session == login_z_url )
{
..rozdielne
exit
}Akurát na webe všade píšu, že aj "odchytenie" session je dosť kritické. |
||
| Keeehi Profil |
#12 · Zasláno: 15. 8. 2020, 22:52:10
luma64:
Pak je úplně zbytečné mít id i v URL, když ho máš uložené v session. Tím žádnou ochranu nepřidáš. Spolehni se na to co máš v session uložené a kontrolu url úplně vynech. „Akurát na webe všade píšu, že aj "odchytenie" session je dosť kritické.“ Tak jistě. Pokud se někomu podaří odchytit cookie se session identifikátorem, tak to problém je. Ale v takovém případě bude mít přístup k té url na kterou se ten pozadavek se session cookie posílal. Jak jsem psal teď tady výše, URL to nezachrání. Kedinou možností je nenechat tu cookie uniknout. Tedy https úplně všude a session cookie by měla mít nastavené správné flagy. - secure - any se zajistilo že se za žádných okolností neposlal přes http, ldyby se někde náhodou nějaká url adresa omylem zapomněla - HttpOnly - aby tu cookie nemohl číst javascript |
||
|
Časová prodleva: 4 roky
|
|||
0