web-app-security
Download
Report
Transcript web-app-security
Information Security Training
Web Application Security
Copyright Justin C. Klein Keane
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
Many Common Injections
SQL injection
LDAP injection
Command injection
Arbitrary script injection
Copyright Justin C. Klein Keane
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>
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
<[email protected]>