Information Security Training
Web Application Security
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
The Web is Simple

Hyper Text Transfer Protocol (HTTP)

Designed to allow remote document retrieval

Simple client server model:
Client
<----------->
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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.
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
Typical Web App Stack

Browser (client)

HTTP over TCP/IP

Server

Operating system

Web server

Scripting language

Database or persistence layer
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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...
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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.
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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....
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
Where do we start?


How can you begin to attack the problem of
web application security?
As always:

With abstractions and models
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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!
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
Clearly


Complexity is the enemy of security
Given all this complexity it is reasonable to
assume:
Security vulnerabilities are rampant
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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....
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
Many Common Injections

SQL injection

LDAP injection

Command injection

Arbitrary script injection
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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'
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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');
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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)
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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?
Copyright Justin C. Klein Keane
<jukeane@sas.upenn.edu>