1

Web Application Security(and why it matters to YOU!)

-Remix-

By Mark Bristow and Doug WilsonMark.bristow@gmail.com

DougWilsonMoo@gmail.com

2

Your presenters today are

Doug Wilson Senior Application Engineer at SAIC

Mark Bristow Information Assurance Engineer at SRA

International

3

Why are we here?

4

A brief discussion on

What is Web Application Security?and why does it matter?

A look at the top problems on the web today

And what you can do to remediate them.

So, what is web application security?

5

Web application security is . . .

An overall process that

Starts in the initial planning stages

Continues through coding, testing, and deployment

Doesn’t finish until the lifecycle is completely finished

6

But why does this matter to me?

Overcoming Denial

No one would ever bother with my web site.

We already have “security” We use open source We use “that” vendor We keep up on patches

“So we have a firewall, an IDS, an IPS, and use SSL . . . we’re covered . . . right?”

7

No, you are probably NOT ok . . .

The web was designed as a trusted environment. It is NOT that anymore.

Web applications are still “emerging technologies” for most organizations.

The drive to stay competitive results in unrealistic expectations and unsafe practices.

8

Looking at Some Recent IT nightmares VA and other government agencies

Personally Identifiable Information (PII) for 26.5 million veterans

TJ Maxx and credit card processing 45 million credit card numbers

AOL and User Data 19 million queries from 650,000 subscribers

PaineWebber logic bomb 2000 servers, over $3.1 million just to restore

9

Web App specific numbers Symantec ISTR Jan-Jun 2007 (from September 2007)

“61 percent of all vulnerabilities disclosed were Web application vulnerabilities.”

“users . . . can no longer place their trust in well known sites.”

CIO Magazine interviews Jeremiah Grossman (5/07)

Vulnerabilities in 80% of websites analyzed Remaining 20% are mostly static sites Most C-level execs they talk to think firewalls protect against web

application attacks -- THIS IS NOT TRUE!!!

10

The bottom line? -- Liability

Liability is not only costly financially, it can damage intangibles beyond repair.

Even if you can afford to lose money, how much is your reputation worth?

Regardless of the who broke it, the liability lies with the people who create and maintain these systems and their management.

11

So, how can we fix this?

12

OWASP -- what is that?

Open Web Application Security Project

www.owasp.org

Top Ten “Guides”

Building secure web apps and services Application testing Code review

Code projects Local Chapters, meetings, and conferences

13

OWASP Top 10 – err . . . Top 5?

Cross Site Scripting (XSS)

Injection Flaws

Malicious File Execution

Insecure Direct Object Reference

Cross Site Request Forgery (CSRF)

14

Cross Site Scripting (XSS)

What is Cross Site Scripting? Occurs when an application takes user supplied data and sends it to

a web browser without validating or encoding that content

In English: Can be anywhere you echo user input

Getting the user to execute arbitrary code in their web browser

XSS is everywhere, if you don’t find it, are you doing something wrong?

15

Why is XSS so dangerous?

Compromise victim computer Can steal user’s authentication credentials Intranet Port scanning Stealing Sensitive Data Key/Mouse logging WebWorms

16

XSS Demo

17

Injection Flaws

Occurs when user supplied data is sent to an interpreter as part of a command or query

Comes in many flavors: SQL, LDAP, XPath, XSLT, HTML, XML, OS command injection, and more

18

Injection Flaws – SQL Injection

So, most people here have probably heard of . . .

SQL Injection Injecting code to modify the intent of a SQL query

What can I do with SQL Injection? Break or bypass Authentication Has the potential to expose your database data to an

attacker Attacker can potentially modify your database structure

and data

Select * from users where uname =‘’ and pw=‘’OR ‘Z’=‘Z’

19

SQL Injection Demo

20

Fixing Injection Flaws

The top two flaws are based on Injection Most of these are easily solved by following a

few simple concepts religiously, in the way that works for your environment.

Don’t trust ANYTHING that comes from the client. Ever.

1. Validate and type all input as strictly as you can.

2. Encode and control all output as strictly as you can.

21

Input Validation

Client side -- doesn’t really do anything for security, though it still has its uses

Server side – The only place where your validation provides security

Regex – Your new best friend

22

Mechanics of good Validation

White listing – Pass only when content contains only known good input

Black Listing – Fail when a known bad is detected

Sanitization – “Clean” data before using it based on Black or White List

23

Sanitization Issues Lets sanitize the name field against script injection

String name = request.getParameter( "name" ); name.replaceALL(“script”, “”); out.println(name);

Test cases Name = “<script>alert(‘I pwnt j00’);</script>” Result: <>alert(‘I pwnt j00’);</> Name = “<scrscriptipt>alert(‘I pwnt j00’);</scrscriptipt>” Result: <script>alert(‘I pwnt j00’);</script>

Sometimes this is a necessary evil

24

Output Encoding

Output should be encoded to match the delivery medium

If it will be HTML, HTML encode. Ex: < becomes &lt;

HTML Entity encoding will stop 99% of XSS attacks

25

Implementing Input Validation

We are going to implement a white list validation for the username field

What charecters are allowed in usernames? A-Z upper and lower case Integers

What regular expression matches this criteria [a-zA-Z0-9]

How would we implement it in PHP if (preg_match('/[^a-zA-Z0-9]/', $username)){ *FAIL* }

26

Implementing Input Validation

27

Now, back to our top 10 . . . or 5 . . .

28

Malicious File Execution

Occurs when developers use user input directly in file or stream functions, or improperly trust uploaded content

Can lead to rootkit installs and server compromise

Many sites allow you to upload images or documents. The demo site allows you to submit reports.

If this report submission is unfiltered you may be able to upload code to the website

29

Malicious File Execution Demo

30

Insecure Direct Object Reference A direct object reference occurs when a developer

exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter.

Resource authorization checks should be conducted when the resouce is requested

Common Examples User ID on query string: showAccount.php?id=2345 Session ID on query String: index.php?

PHP_SESSID=51h3nrstvi0mm60k2j179iqtg6 Directory Traversal

31

Directory Traversal Demo

32

Fixing Object Access Flaws

Don’t trust ANYTHING that comes from the client. Ever. Validate and type all input as strictly as you can. Encode and control all output as strictly as you can.

Do you sense a trend here?

Perform authorization checks every time a resource is requested

33

Cross Site Request Forgery (CSRF) When an attacker forces a victim’s browser to submit a

request the victim did not intend to submit Also known as a “One click attack”, session riding or

XSRF Exploits pre-established trust relationship (session) to

force authorization High remediation costs Malicious requests and legitimate requests are

indistinguishable. Originally dates to 1998 but is just becoming well

understood

34

CSRF DEMO

35

Fixing CSRF CSRF is often labeled as “unfixable,” it’s inherent in how

the web works. But you can take steps to help.

Problems and safeguards Data returned as javascript (Gmail) -- fixed by while(); loop Digg article -- fix: secret tokens (a.k.a. Nonces) Amazon One-Click -- fix: Password re-entered

Fixes work -- unless you combine with XSS. Then the rules change, and some standard fixes go out the window (like secret tokens)

36

The rest of the OWASP Top 10

Information Leakage Error messages provide vital tools to an attacker

Broken Session Management Insecure Cryptographic Storage Insecure Communications

SSL is a web attacker’s best friend

Failure to restrict URL access What happens when I request an admin page directly

without logging in first?

37

The AJAX question Does AJAX and other similar technologies make for

“worse” application security? What about web services?

Asynchronous applications and web services aren’t innately more “insecure,” but greatly increase complexity and attack surface.

Both Asynchronous and Web Service style applications have the potential to reintroduce a lot of old problems.

Minimalist approach is best

38

Is the Sky Falling?

The sky is NOT falling! All of the vulnerabilities mentioned here can be fixed Developer education and a robust software security

program can help mitigate these issues Educate yourselves Educate your customers

39

How do I get started?

LEARN! What threats are out there and how they apply to your organization?

Classify what data is most important to your organization

Identify all of your web applications and assign them criticalities based on business needs and data classification

Perform vulnerability assessments to determine how big the problem is

“Bake security in” to your SDLC

40

Resources Sites

http://www.owasp.org http://www.webappsec.org/ http://ha.ckers.org http://www.sans-ssi.org/

Books How to Break Web Software Hacking Exposed : Web Applications XSS ATTACKS

Training Certified Ethical Hacker (CEH) Foundstone Ultimate Web Hacking SANS Training

Securing Critical Web Applications and Web Services (Aspect Security)

Writing Secure Web Applications: Developer Training

41

Questions?

stop by onelittlewindow.org