Copyright Justin C. Klein Keane Information Security Training Web Application Security

Copyright Justin C. Klein Keane <[email protected]>

Information Security Training

Web Application Security


The Web is Simple

Hyper Text Transfer Protocol (HTTP) Designed to allow remote document retrieval Simple client server model:

Client <-----------> Server


The Reality

Web application security is massively complex Difficult for specialist security practitioners

Impossible for developers Constantly evolving field

HTML 5, Web 2.0, AJAX, etc., etc.


Typical Web App Stack

Browser (client) HTTP over TCP/IP Server

Operating system Web server Scripting language Database or persistence layer


Just the Client

Many different clients, all implementing differently (Chrome, IE, Fire Fox, Safari, etc.)

HTML is simply display (or is it?) JavaScript allows for client side programming Files can be uploaded and downloaded Plug-in's allow for rich media display Java allows for dynamic client side mini progs AJAX and multiple HTML sources in any page And on and on...


Fertile Ground

Web app sec is massively complex in reality Security researchers specialize in specific

portions of the stack Protocols and specs exist but aren't

implemented uniformly Even platforms are changing

Think mobile, tablets, embedded systems, etc.


What's Worse...

Web is becoming the default content and application delivery mechanism

Most mobile apps can be done in the browser Even power companies want to put smart grid

on the internet Firewalls become irrelevant as everything flows

over port 80


Implications

Like TCP/IP, the web wasn't designed for the way it is being used

Hypertext transfer != online banking The protocol has been expanded:

State has been introduced Client platform has been extended Servers contain extremely complex logic Security is thrown in here somewhere....


Where do we start?

How can you begin to attack the problem of web application security?

As always: With abstractions and models


LAMP Stack

Looking only at the server: Linux Apache MySQL PHP

Not only is this model common, it is easy to set up in a lab environment

Security exists at every level of the stack Sadly, so does vulnerability


Linux

OS forms the foundation of the web application Enforces per user access restrictions Manages interactions between AMP Handles socket & port assignments Manages access to CPU, disk, and RAM Can be thought of as the “inner ring” of web

application security


Apache

Widely used, cross platform, open source web browsers

Listens on port 80 and handles requests from the outside world

Adjudicates requests to files or off to PHP Enforces it's own access restrictions Runs as a user on Linux Has massive configuration possibilities


PHP

Dynamic scripting language When Apache receives a request to a PHP file:

Compiles the file Delivers the output (usually HTML)

PHP has it's own configuration settings PHP is a full featured, object oriented, language

that looks very similar to Java PHP scripts only “live” for one Apache call


MySQL

Because PHP is compiled, run, and discarded a database is required for persistence.

MySQL is a daemonized service running on Linux

Open source, cross platform, modern RDBMS MySQL has it's own permission model


Server? Hello, this is Client

How does the server know “who” each client is? Cookies were an early addition to HTTP Files stored on clients Automatically delivered along with requests to

associated domains Domain independence is a key concept


Client? This is Server,DO YOUR OWN WORK!

Lots of presentation operations happen at the browser level

JavaScript is the most common way to perform client side calculations

JavaScript can: Dynamically adjust display elements Perform complex calculations Can give immediate user feedback Can make presentation more engaging


We Are Legion

“Client” is no longer singular Browsers now implement tabs Segregation of session is a critical security

component May not communicate across domains Retain “tab” isolation and integrity

But everyone wants a piece of you... Facebook login leaks all sorts of info


DOMination

Each web page can be broken down by the client

Document Object Model (DOM) Turns the web page rendered by the client into

an object Allows dynamic identification and modification

of each page DOM security is also critical!


Clearly

Complexity is the enemy of security Given all this complexity it is reasonable to

assume:

Security vulnerabilities are rampant


Vulnerability Classification

Two widely accepted classifications: OWASP Top 10

Open Web Application Security Project Http://www.owasp.org Each year classifies top 10 “worst” vulnerabilities

WASC Web Application Security Consortium Classified over 30 attacks and over a dozen

weaknesses Useful in categorizing findings and guiding

evaluation/testing

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

http://www.owasp.org/

http://projects.webappsec.org/w/page/13246978/Threat%20Classification


Vulnerability Tracking

OSVDB Open Source Vulnerability Database

CVE Common Vulnerability Enumerator Assigned by Mitre (http://cve.mitre.org)

NVD National Vulnerability Database Supported by NIST, DHS and US-CERT

http://osvdb.org/

https://cve.mitre.org/

http://cve.mitre.org/

https://nvd.nist.gov/


Exploitation

BeEF - http://beefproject.com/ Metasploit – http://www.metasploit.com Exploit DB - http://www.exploit-db.com/ Packet Storm -

http://packetstormsecurity.org/files/tags/exploit/ SLQMap - http://sqlmap.org/ W3AF - http://w3af.sourceforge.net/ And on, and on....


Vulnerabilities

Web apps suffer a broad range of vulnerabilities Injection Cross Site Request Forgery Program redirection (includes) Information disclosure Open redirects Authentication Problems Insecure crypto


Injection

Injection hinges on data encoding Developer intends data to be handled in one

way and attacker crafts data to be handled another way

Unexpected encoding escapes context Example

Data intended to be encoded as an integer, attacker changes data so that it is a string


Many Common Injections

SQL injection LDAP injection Command injection Arbitrary script injection


SQL Injection

Developer interpolates user supplied data into a SQL query

Attacker manipulates input so as to escape encapsulation and rewrite SQL

SELECT id from user

WHERE username = '$foo' and password = '$bar'

becomes:SELECT id FROM user

WHERE username = 'admin' and password='secret' or 1='1'


Command Injection

Developer utilizes user accessible to execute a command at the command line

$retval = exec('echo “$line” >> logfile.txt');

becomes:$retval = exec('echo “”; rm -rf *; echo “” >>

logfile.txt');


Arbitrary Script Injection

Changing the HTML of a page This is also referred to as Cross Site Scripting,

or XSS for short Attacker can manipulate input to write arbitrary

HTML on a page Generally Javascript, iframe tags or third party

extensions (Flash, Java, etc.) are injected Three types: stored, reflected, and DOM


Stored XSS

Malicious input is saved in the database Also referred to as “persistent XSS” Malicious input is served to all site visitors Can also be accomplished via SQL injection Often used for client side attacks by referencing

objects/pages that try to exploit browsers or browser plugins


Reflected XSS

User must be tricked into supplying malicious input to the site

Often used for trust exploitation and phishing Requires the attacker to interact with the target Much more difficult to detect


DOM Based

Complex vulnerability, least common Involves manipulating pieces of the Document

Object Model (how JavaScript/CSS address pieces of the page)

Client side rendering changes appearance and/or functionality of the resulting HTML


XSS is Everywhere

XSS is by far the most prevalent web app vulnerability

XSS is often misunderstood because the proof of concept (pop-up) doesn't demonstrate true attacker capability

XSS can lead to reputational damage, denial of service, and chained exploit

XSS can be used against site administrators


Why XSS is Hard

Extremely difficult to automate tests for XSS Often times XSS defense can be bypassed in

clever ways Developers should strive to use 3rd party

libraries that are collaboratively maintained


XSRF

Cross site request forgery is a trust exploit The server trusts (wrongly) the browser request

of users b/c authentication cookies are supplied Attacker forces the users browser to take action

on their behalf Clever way to take over web applications (Whiteboard demo)


Program Redirection

Dynamic web apps reference files in order to cut down on code reuse

Often times applications will reference remote files (such as RSS feeds)

Can be a source for attack, if sources can be manipulated


Example

Developer uses URL variables to determine page display

“About Us” page URL – index.php?page=about

Uses the following code:include('inc/' . $_GET['page'] . '.php');

Should include the 'inc/about.php' page Malicious redirection could occur:index.php?page=../../../etc/passwd%00

This attack uses null byte injection


RFI vs. LFI

Remote File Include vulnerabilities allow attacker to include remote code that is executed locally (on the server)

Local File Include can allow an attacker to: hijack program flow expose protected functionality include arbitrary filesystem files


Information Disclosure

Leaking sensitive information about the server, configuration, application or database

Error messages are a common exposure Login failure messages can help brute force

attacks Configuration files or backups of files could be

exposed via web browser Plain text exposure of source code The list is nearly infinite


Open Redirects

Often sites will include functionality to track users “clicking off” the site

Exploits this “log and forward” feature to redirect users

Can be used for trust exploitation, phishing, etc. Can also be used for black hat SEO


Authentication Vulnerabilities

Authentication bypass Attackers can get at resources that are

supposed to be access controlled Extremely application and context specific

Session management flaws Attacker can hijack other users sessions

Insufficient anti-automation Application doesn't provide brute force controls


Insecure Crypto

Applications do not properly apply cryptography (or omit it altogether)

Passwords should never be stored in clear text SSL needs to be properly implemented Sensitive data should be protected and

encrypted at rest


Logic Flaws

Logic flaws are a complex, application specific, vulnerability

Failure of the application to adhere to stated security functionality

Example: Site users can change a parameter and see user details for other users


If you thought all this was bad

Web 2.0 has greatly exacerbated web application security issues

State does not exist on the web, so programmers have had to fake it

End user applications extend beyond the browser


AJAX

Asynchronous Javascript And XML Allows applications to communicate back and

forth from client to server “behind the scenes” Often developers don't realize attackers can

access AJAX resources and fail to protect them XML can come from untrusted sources XML could include information disclosure flaws


Browser Plugins

Third party plugins like Flash, Java applets, PDF readers, etc. can provide another vector for attack

Each has their own security context and concerns

For instance, Javascript can be embedded in Flash, which could bypass other application protections


Conclusion

This is just scratching the surface Privacy issues are another can of worms Doesn't cover defensive techniques How do you audit closed source? Third party services (cloud) have problems

too.

Questions?

Documents

Copyright Justin C. Klein Keane Information Security Training Web Application Security