Szerző Téma: Script injection, XSS, SQL injection - avagy hogyan védjük weboldalainkat  (Megtekintve 2051 alkalommal)

Nem elérhető Fantasy™

  • Intermediate
  • **
  • Thank You
  • -Given: 53
  • -Receive: 41
  • Hozzászólások: 163
  • Segített: 17
Ezt az írást elsősorban webfejlesztőknek ajánlom figyelmébe, akik szeretnék weboldalaikat komolyabban levédeni hekkerek vagy botok ellen.

A címben szereplő 3 kifejezés valószínűleg a legelterjedtebb támadási formák manapság weboldalak ellen. Egy valamirevaló webprogramozó minimum ezek ellen kőkeményen védekezik, és akkor a Greasymonkey hack-ekről és társaikról még nem is beszélünk.

Az XSS, azaz Cross-site-scripting például kiválóan alkalmas Phising-ra (magyarul adathalászatra, de egy ügyes hekker szinte akármire fel tudja használni, gondolok itt a sütilopástól kezdve a személyes adatok logolásáig és a CSRF-ig mindenre). Itt egy példa nem perzisztens XSS támadásra:

Vannak olyan oldalak, ahol egy felhasználónak szánt üzenetet, ERROR_MESSAGE-t, vagy SUCCESSFUL_MESSAGE-t a programozó GET-es változókban utaztat, pl: http://tedomained.hu/feltoltes.php?mess=Sikeres%20feltoltes!

Ezt általában egy az egyben kiírják a programozók a weboldalra, nem figyelve a biztonságra, hiszen mi van akkor ha átírom a GET-es változót, valahogy így: http://tedomained.hu/feltoltes.php?mess=<script>alert(1);</script> ?

Ekkor a böngésző simán az arcunkba tolja az alert ablakot, tehát találtunk egy módszert, hogyan juttassunk ártó szándékú javascriptet egy más által birtokolt weboldal forráskódjába. A legjobb védekezés az, ha elkerüljük az URL-ekben szállított stringeket, inkább használjunk azonosító integereket (pl 1,2,3 stb), aminek mindegyikéhez tartozik egy felhasználói üzenet, majd egy switch-el döntjük el, melyik üzenetet kapja a juzer, és már be is foltoztuk a biztonsági rést. Ha mégis ragaszkodunk az URL-ben szállított stringekhez, akkor viszont kiírásnál ügyeljünk rá, hogy egy strip_tags-et, vagy egy htmlentities-t engedjünk rá előtte.

A Script injection hasonlít kicsit az XSS-re, azzal a külömbséggel, hogy ez már gyengébb adatbiztonsági ismereteket feltételez a weboldal programozójáról. Arról van szó, hogy egy felhasználó által megadott input mezőbe ha HTML,JavaScript, vagy egyéb a böngésző által lefordítható kódot injektálunk, és ez kiírásra kerül magunknak (vagy ami még rosszabb: más felhasználóknak), akkor szintén az a helyzet áll fenn, hogy más által írt weboldalba simán ártó szándékú kódot varázsolhatunk. Egy social networknél például kifejezetten gáz lenne egy ilyen jellegű hiba ;).

Védekezés: szintén strip tags, vagy htmlentities, lehetőleg már adatbázisba írás előtt.

Az SQL injection főként keresésnél, vagy jelszómódosításnál tud kifejezetten veszélyes lenni (valójában talán a legveszélyesebb mind közül). Maradva a social network példánál, képzeljük el a jelszómódosító FORM-ot, és azt, hogy mi megy a háttérben:

Van 2 input mező, mindkettőbe ugyanazt a jelszót kell beírni, és ha egyeznek, a szerver oldali script kicseréli az adatbázisban a jelszót, majd küld egy message-t, hogy "sikeres jelszócsere". Nézzük meg, hogyan néz ki ez az PHP-SQL utasítás:
mysql_query("UPDATE felhasznalok SET jelszo='uj_jelszo' WHERE nev='RobbeR'");
Ebben ugye a WHERE feltétel mondja meg az adatbázisnak, hogy csak abban a sorban cserélje a jelszót, ahol a név='RobbeR'. (vagy 'id=[0-9]*', attól függ, mi a UNIQUE mező az adatbázisban). De mi van akkor, ha én jelszónak ezt adom meg: jelszo'--   ... Ekkor ez lesz a lekérdezésből:
mysql_query("UPDATE felhasznalok SET jelszo='jelszo'--' WHERE nev='RobbeR'");
Ehhez tudni kell, hogy SQL-ben a megjegyzés a '--' után írandó, tehát ez a string 2 részre szedi az utasítást:
UPDATE felhasznalok SET jelszo='jelszo' és --' WHERE nev='RobbeR'
ahol a 2. rész ugyebár megjegyzés, így valójában csak az első rész lesz értelmezve az adatbázison. Ebben meg már nincs benne a feltétel, így nem csak azt az egy sort írja át, hanem az összes sort a `felhasznalok` táblában. Ha ezt egy social network-ön alkalmazzák sikeresen, akkor ezután mindenkinek 'jelszo' lesz a jelszava, függetlenül attól hogy eddig is az volt-e, vagy nem. Ez azért elég gáz tud lenni, ha pl nincs mentve az adatbázis...

Védekezés: mysql_real_escape_string, ami escapeli az összes ' vagy " karaktert, illetőleg a \ karaktereket is.

Sok sikert a fejlesztésben, remélem azért valaki elolvassa ezt, és hasznosnak találja majd;)


******.htaccess****** Update 2018.09.20  ;)

# Fájl hozzáférés tiltás

<files wp-config.php>

order allow,deny

deny from all

</files>



# Blokkolja az include fájlokat

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^wp-admin/includes/ - [F,L]

RewriteRule !^wp-includes/ - [S=3]

RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]

RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]

RewriteRule ^wp-includes/theme-compat/ - [F,L]

</IfModule>



# Blokkolja a gyanús kéréseket

RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG) [NC]

RewriteRule ^(.*)$ - [F,L]

RewriteCond %{REQUEST_URI} (timthumb\.php|phpthumb\.php|thumb\.php|thumbs\.php) [NC]

RewriteRule . - [S=1]



# Blokkolja a gyanús felhasználói kéréseket

RewriteCond %{HTTP_USER_AGENT} (libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR]

RewriteCond %{HTTP_USER_AGENT} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]

RewriteCond %{HTTP_USER_AGENT} (;|<|>|'|"|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|wget|python|nikto|curl|scan|java|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]

RewriteCond %{THE_REQUEST} \?\ HTTP/ [NC,OR]

RewriteCond %{THE_REQUEST} \/\*\ HTTP/ [NC,OR]

RewriteCond %{THE_REQUEST} etc/passwd [NC,OR]

RewriteCond %{THE_REQUEST} cgi-bin [NC,OR]

RewriteCond %{THE_REQUEST} (%0A|%0D) [NC,OR]



# Blokkolja a Mysql Injectálásokat, Base64, RFI, stb.

RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]

RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]

RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC,OR]

RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC,OR]

RewriteCond %{QUERY_STRING} (\.\./|\.\.) [OR]

RewriteCond %{QUERY_STRING} ftp\: [NC,OR]

RewriteCond %{QUERY_STRING} http\: [NC,OR]

RewriteCond %{QUERY_STRING} https\: [NC,OR]

RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]

RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} ^(.*)/bdweb/(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} (<|%3C)([^i]*i)+frame.*(>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]

RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*\([^)]*\) [NC,OR]

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]

RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>).* [NC,OR]

RewriteCond %{QUERY_STRING} (NULL|OUTFILE|LOAD_FILE) [OR]

RewriteCond %{QUERY_STRING} (\./|\../|\.../)+(motd|etc|bin) [NC,OR]

RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]

RewriteCond %{QUERY_STRING} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]

RewriteCond %{QUERY_STRING} concat[^\(]*\( [NC,OR]

RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]

RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC,OR]

RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]

RewriteCond %{QUERY_STRING} (sp_executesql) [NC]

RewriteRule ^(.*)$ - [F,L]



RewriteCond %{HTTPS} off

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}


     

 ::) ::) ::) ::) ::)
« Utoljára szerkesztve: 2018-09-20, 00:42:18 írta Fantasy™ »