Schneier.com - Pred približno mesecem dni so na Dark Reading objavili članek o varnostnih ranljivostih, odkritih v različnih aplikacijah. Na prvem mestu je z 21,5% Cross Site Scripting (XSS exploit), sledi možnost SQL vrivanja (SQL injection) ki so ga našli v 14% aplikacij, na tretjem mestu so PHP vrivanja (9,5%), sledijo pa prekoračitve pomnilnika (buffer overflow s 7,9%.
To so seveda varnostne ranljivosti, ki so jih odkrili v aplikacijah. Michael Sutton pa si je zastavil vprašanje, koliko teh ranljivosti je dejansko mogoče najti v resničnem svetu. Osredotočil se je na SQL vrivanje in analiziral spletne strani. S pomočjo Googla je izbral 1000 spletnih strani, ki uporabljajo SQL in poiskusil izvesti nedolžno SQL vrivanje. V primeru, da je spletna stran vrnila napako, je Sutton ugotovil, da je spletna stran ranljiva, sicer pa ni.
In rezultat? Izkaže se, da je s SQL vrivanjem trenutno ranljivih kar 11,3% spletnih strani, ki uporabljajo SQL baze podatkov.
'Hekerjem' dela torej še ne bo zmanjkalo...
Novice » Varnost » Raziskava o ranljivosti spletnih strani z SQL bazami podatkov
WarpedGone ::
Hmmm, da stvar vrne napako, zame niti ni ranljivost, kvečjemu slab design.
Velik večji problem je, če ne vrne napake in izvede vrinjen SQL. Je takšne strani štel kot varne???
Velik večji problem je, če ne vrne napake in izvede vrinjen SQL. Je takšne strani štel kot varne???
Zbogom in hvala za vse ribe
jure1825 ::
Je meni se zdi tudi logično da vrne napako če probaš kaj "zlobnega" naredit, problem je če ne vrne napake pa ne vem npr vstavi v bazo kar je bilo v sql injectionu napisano.
NavadniNimda ::
Niti ne gre za slab dizajn, ampak samo za en KLIK z miško v IIS Admin MMC aplikaciji - in izpisala bi se le generična napaka ob SQL errorju (ali kerem koli drugem). Lenoba take sorte administratorjev in seveda programerjev, ki so aplikacijo pustili ležati naokoli, je neizmerna. Torej gre kljub vsemu na nek način za slab dizajn!
blackmumba ::
Če se vsak podatek pred querijem obdela s tema dvema funkcijama je to dovolj ?
function checkIncomingData($idata, $minsize, $maxsize)
{
if (
strlen($idata) < $minsize
or
strlen($idata) > $maxsize
)
{
return false;
}
else
{
return true;
}
}
function cleanIncomingData($idata)
{
$cleaned = trim($idata);
$cleaned = mysql_real_escape_string($cleaned);
return $cleaned;
}
function checkIncomingData($idata, $minsize, $maxsize)
{
if (
strlen($idata) < $minsize
or
strlen($idata) > $maxsize
)
{
return false;
}
else
{
return true;
}
}
function cleanIncomingData($idata)
{
$cleaned = trim($idata);
$cleaned = mysql_real_escape_string($cleaned);
return $cleaned;
}
neoto ::
kolikor sem imel opravka z novim php-jem, sem videl, da že same funkcije, ki jih uporabljam za vpisovanje v bazo, oz. funkcije, s katerimi zahtevam podane parametre, očistijo query raznih komentarjev, nepravilnih narekovajev... SQL injection mi tako ni uspelo izkorisiti na svoji aplikaciji. 
fatg ::
o šit, pa tko simpl je vse skupi: filter input, escape output. Par vrstic kode in nobene XSS/SQL-injection luknje več ni ...
MrM ::
Hmmm, da stvar vrne napako, zame niti ni ranljivost, kvečjemu slab design.
Ker avtor članka najbrž ni imel namena "hackati" stran, je ranljivost precej lažje ugotoviti tako, da izzoveš napako. Če stran na vhodnih podatkih npr. ne escape-a enojnih narekovajev ('), moraš vnesti le en enojni narekovaj in dobiš napako, kar pomeni, da je stran ranljiva.
Primer:
SELECT * FROM users WHERE username = 'user' AND password='''
Ta query vrne napako, ker se pojavijo trije narekovaji. Pravilno napisana aplikacija bi query zagnala takole:
SELECT * FROM users WHERE username = 'user' AND password='\''
Če bi nekdo hotel to napako izkoristiti, bi namesto narekovaja vnesel nekaj takega:
' OR '' = '
Kar bi na ranljivi aplikaciji izvedlo naslednji query:
SELECT * FROM users WHERE username = 'user' AND password='' OR '' = ''
I have always wished for a computer that would be as easy to use as my
telephone. My wish came true. I no longer know how to use my telephone.
--Bjarne Stroustrup
telephone. My wish came true. I no longer know how to use my telephone.
--Bjarne Stroustrup
sverde21 ::
@MrM: to je že res... ampak jst tudi zaradi varnosti raje poiščem uporabnika takole:
SELECT geslo FROM uporabniki WHERE uporabnik='$user' LIMIT 1; // seveda še prej escapeam stvar
in potem preverim uporabnikovo geslo takole:
V tem primeru je funkcijonalnost enaka vendar je možnost zlorabe veliko manjša, ker tudi če ne escapeaš gesla, nima veze, ker ga if stavek preverja...
Sicer se pa tudi queryja ne da prirediti tako enostavno, kot v primeru, ki si ga navedel ti z ' OR '' = '...
SELECT geslo FROM uporabniki WHERE uporabnik='$user' LIMIT 1; // seveda še prej escapeam stvar
in potem preverim uporabnikovo geslo takole:
if($row['geslo'] == $_POST['geslo']) { // navadno še tudi to vrednos escapeam ampak ubistvu ga ni treba
echo 'Uspešna prijava!';
// koda ob uspešni prijavi...
} else {
die('Napačno geslo');
}V tem primeru je funkcijonalnost enaka vendar je možnost zlorabe veliko manjša, ker tudi če ne escapeaš gesla, nima veze, ker ga if stavek preverja...
Sicer se pa tudi queryja ne da prirediti tako enostavno, kot v primeru, ki si ga navedel ti z ' OR '' = '...
<?php echo `w`; ?>
Zgodovina sprememb…
- spremenil: sverde21 ()
drola ::
Če ne escapeaš ni edini problem login, ampak je še en hujši, ker ti nekdo lahko pobriše celo bazo.
sverde21: gesla kodiraj z md5();
sverde21: gesla kodiraj z md5();
https://drola.si
MrM ::
Moj komentar je bil mišljen zgolj kot pojasnilo, kako se z iskanjem napake lahko išče ranljivost strani in ne kod povod za strokovno debato na temo varnosti v PHP skriptah. Za to imamo php-si. 
Bi pa pokomentiral tole:
Vse lepo in prav, vendar za escape-anje podatkov skrbiš ti, kot razvijalec spletne strani. Zakaj bi torej uvajal mehanizme, ki bodo skrbeli za varnost v primeru ne-escape-anih podatkov, če jih itak escape-aš.
EDIT:
Seveda. Podal sem le najenostavnejši primer.
Bi pa pokomentiral tole:
V tem primeru je funkcijonalnost enaka vendar je možnost zlorabe veliko manjša, ker tudi če ne escapeaš gesla, nima veze, ker ga if stavek preverja...
Vse lepo in prav, vendar za escape-anje podatkov skrbiš ti, kot razvijalec spletne strani. Zakaj bi torej uvajal mehanizme, ki bodo skrbeli za varnost v primeru ne-escape-anih podatkov, če jih itak escape-aš.
EDIT:
Če ne escapeaš ni edini problem login, ampak je še en hujši, ker ti nekdo lahko pobriše celo bazo.
Seveda. Podal sem le najenostavnejši primer.
I have always wished for a computer that would be as easy to use as my
telephone. My wish came true. I no longer know how to use my telephone.
--Bjarne Stroustrup
telephone. My wish came true. I no longer know how to use my telephone.
--Bjarne Stroustrup
Zgodovina sprememb…
- spremenil: MrM ()
MasterBlaster ::
Jedro vsega problema je uporaba mysql_* funkcij. Te niso varne. Bolje je uporabiti PDO, ki je na voljo od PHP 5.0, v 5.1 je pa celo omogočen privzeto.
Čeprav je pametno izvesti še kakšne druge vgodne kontrole, je taka koda varna pred sql napadi.
$db = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
$st = $db->prepare("SELECT * FROM users WHERE username = ? AND passwprd = ?");
$st->execute(array($_POST["username"], $_POST["password"]));
if($row = $st->fetch()){
}
Čeprav je pametno izvesti še kakšne druge vgodne kontrole, je taka koda varna pred sql napadi.
Tk je pa pika .
sverde21 ::
@drola: ne skrbi kodiram jst z md5(), sha1() in še čem drugim, uporabljam salte,... tako da gesla v moji bazi, tudi, če dobiš hash ne boš sesul kar tako .
Za druge primere tudi vem... jst ubistvu vse spustim čez mysqli_real_escape_string() oz. intval(), kar mi uporabnik pošlje noter, bolš preventivno, escapeat, kot pa potem jokat, ko je piše na prvi strani na veliko OWNED BY SOME BORED GUY WHO HAS NOTHING BETTER TO DO THAN DEFACE
@MasterBlaster: meni PDO ne diši najbolj, ker prvič je vključen šele v PHP 5.1 (nekateri imajo še na žalost PHP4) ... Si moram enkrat vzeti čas in dopisati moj database abstraction class in dodati PDO notri
Zakaj programerji ne escapeajo? Hja ne vem pomoje so preleni ali pa ne znajo oz. sploh ne vedo da je takšna koda nevarna... Pomoje je napaka današnjih firm, da gledajo na reference (OK tud te so pomembne) in ne na programerjevo znanje o varnem programiranju...
Zlo pogost in pomoje najnevarnejši napad je RFI (Remote File Inclusion), to je velikokrat napaka administratorjev, ki imajo register globals na ON. Z RFI lahko zelo hitro dobi napridiprav kontrolo nad celotnim strežnikom, še posebej, če strežnik ne deluje v safe mode, 1-2-3 namesti zadnja vrata preko exec() funkcije... Najbolj glupo se mi zdi, da ko sem zadnič enkrat našel to luknjo na neki strani, in kontaktiram admina in mi reče: "Ja sej bom porihtu, ko bom meu cajt...", in še 2-3 mesce po tistem, ko sem ga opozoril da ima luknjo na strani ni popravil kode . IMO skrajno neodgovorno.
Imamo še eno vrsto ranljivosti, ki je omenjena v novici in sicer XSS (Cross Site Scripting). To je idealna metoda za krajo piškotkov... najdeš mesto, kjer injectaš HTML kodo ali še bolje JavaScript in pošlješ nekomu link npr. http://www.example.com/file.php?title=%... mu rečeš da naj nekaj pogleda in v tistem se pri tebi zabeležjo njegovi piškotki
potem sledi mal urejanja cookies.txt in vdor je uspešen. Pomoje to vrsto ranljivosti veliko programerjev zanemarja, ker ni tako očitna, kot SQL Injection, kjer moraš samo paziti, da sfiltriraš spremenljivke vključene v queryju.
Pa še ena trditev, ki bi naj spremljala vsakega administratorja: "Defaults are evil."
.Za druge primere tudi vem... jst ubistvu vse spustim čez mysqli_real_escape_string() oz. intval(), kar mi uporabnik pošlje noter, bolš preventivno, escapeat, kot pa potem jokat, ko je piše na prvi strani na veliko OWNED BY SOME BORED GUY WHO HAS NOTHING BETTER TO DO THAN DEFACE
@MasterBlaster: meni PDO ne diši najbolj, ker prvič je vključen šele v PHP 5.1 (nekateri imajo še na žalost PHP4) ... Si moram enkrat vzeti čas in dopisati moj database abstraction class in dodati PDO notri
Zakaj programerji ne escapeajo? Hja ne vem pomoje so preleni ali pa ne znajo oz. sploh ne vedo da je takšna koda nevarna... Pomoje je napaka današnjih firm, da gledajo na reference (OK tud te so pomembne) in ne na programerjevo znanje o varnem programiranju...
Zlo pogost in pomoje najnevarnejši napad je RFI (Remote File Inclusion), to je velikokrat napaka administratorjev, ki imajo register globals na ON. Z RFI lahko zelo hitro dobi napridiprav kontrolo nad celotnim strežnikom, še posebej, če strežnik ne deluje v safe mode, 1-2-3 namesti zadnja vrata preko exec() funkcije... Najbolj glupo se mi zdi, da ko sem zadnič enkrat našel to luknjo na neki strani, in kontaktiram admina in mi reče: "Ja sej bom porihtu, ko bom meu cajt...", in še 2-3 mesce po tistem, ko sem ga opozoril da ima luknjo na strani ni popravil kode
. IMO skrajno neodgovorno.Imamo še eno vrsto ranljivosti, ki je omenjena v novici in sicer XSS (Cross Site Scripting). To je idealna metoda za krajo piškotkov... najdeš mesto, kjer injectaš HTML kodo ali še bolje JavaScript in pošlješ nekomu link npr. http://www.example.com/file.php?title=%... mu rečeš da naj nekaj pogleda in v tistem se pri tebi zabeležjo njegovi piškotki
potem sledi mal urejanja cookies.txt in vdor je uspešen. Pomoje to vrsto ranljivosti veliko programerjev zanemarja, ker ni tako očitna, kot SQL Injection, kjer moraš samo paziti, da sfiltriraš spremenljivke vključene v queryju.Pa še ena trditev, ki bi naj spremljala vsakega administratorja: "Defaults are evil."
<?php echo `w`; ?>
poweroff ::
sverde: a na tak način poteka session fixation? Ukradeš cookie in se logiraš notri pod njegovim sessionom?
sudo poweroff
CWIZO ::
Še nikol nisem slišal za PHP vrivanje? Kak nej bi pa to izvajal? Če bi slučajno vedel da bo programer nek string ki mu ga vrineš preko GETa oz. POSTA spustil čez eval?
hancic.info
I can't uninstall it, there seems to be some kind of "Uninstall Shield"...
I can't uninstall it, there seems to be some kind of "Uninstall Shield"...
poweroff ::
PHP include sem prevedel kot PHP vrivanje, mogoče se ti zato zdi čudno. Vrivanje sem rekel zato, ker omogoča "vrivanje" oz. vključevanje evil skript v obstoječo kodo... Čeprav, če sedaj pomislim, sem očitno zajeb***, saj bi bil boljši prevod PHP vključevanje...
Drugače gre pa za tole: PHP include primer.
Drugače gre pa za tole: PHP include primer.
sudo poweroff
CWIZO ::
Aja to. No ja nisem ne enega ne drugega izraza slišal za to. Sem pa seveda že videl da to folk dela :)
hancic.info
I can't uninstall it, there seems to be some kind of "Uninstall Shield"...
I can't uninstall it, there seems to be some kind of "Uninstall Shield"...
sverde21 ::
@Matthai: in kaj naj bi bil "session fixation"?? prvič slišim... Sicer se pa da enostavno z kopiranjem piškotka logirati, saj zato so piškotki ane, da se avtomatsko logira, načeloma se pa ne preverja oz. se ne da preverjat ali je to pravi uporabnik ali ne, to se da samo z geslom (pa še to ne vedno).
Pa tistemu, kar si ti prevedel kot PHP vrivanje se reče RFI (Remote File Inclusion) , obstaja pa tudi PHP inclusion oz. vrivanje PHP kode, ki je mogoče recimo pri kakim BBCode, kjer se uporablja RegEx z modifierjem e (nekaj več o tem si lahko preberete tukajle) na ta modifier pomoje veliko programerjev sploh ni pozornih (lahko da se motim), potem pa lahko vrivamo PHP kodo tudi takole:
Pa tistemu, kar si ti prevedel kot PHP vrivanje se reče RFI (Remote File Inclusion)
, obstaja pa tudi PHP inclusion oz. vrivanje PHP kode, ki je mogoče recimo pri kakim BBCode, kjer se uporablja RegEx z modifierjem e (nekaj več o tem si lahko preberete tukajle) na ta modifier pomoje veliko programerjev sploh ni pozornih (lahko da se motim), potem pa lahko vrivamo PHP kodo tudi takole: eval($_GET['php']);evo najbolj simple primer kako se da vrinit kakršno koli PHP kodo preko naslovne vrstice
<?php echo `w`; ?>
poweroff ::
O session fixation sem bral v zadnji številki Monitorja - priloga Sistem. Odkril jo je en Slovenec. Gre pa za to (prebral sem zelo na hitro), da heker počaka da se nekdo logira in potem on vpade v sejo in postane še on logiran.
sudo poweroff
sverde21 ::
Ne vem zgleda da bom moral Monitor malce v roke vzet ampak tole se mi sliši kot Session hijacking, odkril je pa 99% ni slovenc
<?php echo `w`; ?>
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Kako se izogniti nevarnosti SQL vrivanja?Oddelek: Novice / Varnost | 7374 (4800) | Spiko |
| » | AJPES kot najbolj transparentni državni organ javno objavil vse svoje registre (strani: 1 2 3 4 5 6 7 8 )Oddelek: Novice / Varnost | 131459 (96692) | AndrejO |
| » | Na internetu spet ilegalna dražba dostopa do napadenih spletnih straniOddelek: Novice / Varnost | 5481 (4371) | Null |
| » | Vzpostavljanje prikritih omrežij s pomočjo XSS ranljivosti in JavaScriptaOddelek: Novice / Varnost | 5628 (4337) | MrStein |