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. 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? ) Java. Script 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: Apache My. SQL Linux 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>
My. SQL Because PHP is compiled, run, and discarded a database is required for persistence. My. SQL is a daemonized service running on Linux Open source, cross platform, modern RDBMS My. SQL 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 Java. Script is the most common way to perform client side calculations Java. Script 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 Keane Copyright Justin C. Klein <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 Be. EF - 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/ W 3 AF - http: //w 3 af. 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 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 Java. Script/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 3 rd 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 Doesn't cover defensive techniques How do you audit closed source? Privacy issues are another can of worms Third party services (cloud) have problems too. Questions? Copyright Justin C. Klein Keane <jukeane@sas. upenn. edu>
Скачать презентацию Information Security Training Web Application Security Copyright Justin
e5fd469c2bd48e93a26a70e2129d9507.ppt