Copyright Justin C. Klein Keane <[email protected]>
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 <-----------> Server
Copyright Justin C. Klein Keane <[email protected]>
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?