A XSS Vulnerability in Almost Every PHP Form I’ve Ever Written
I've spent a lot of time over the past few months writing an enterprise application in PHP. Despite what some people may say, I believe that PHP is as secure or insecure as the developer who is writing the code. Anyway, I'm at the point in my development lifecycle where I decided that it was ready to run an application vulnerability scanner against it. What I found was interesting and I think it's worth sharing with you all.
Let me preface this by saying that I'm the guy who gives the training to our developers on the OWASP Top 10, writing secure code, etc. I'd like to think that I have a pretty good handle on programming best practices, input validation, and HTML encoding. I built all kinds of validation into this application and thought that the vulnerability scan would come up empty. For the most part I was right, but there was one vulnerability, one flaw in particular, that found it's way into every form in my application. In fact, I realized that I've made this exact same mistake in almost every PHP form that I've ever written. Talk about a humbling experience.
So here's what happened. I created a simple page with a form where the results of that form are submitted back to the page itself for processing. Let's assume it looks something like this:
<html> <body> <?php if (isset($_REQUEST['submitted']) && $_REQUEST['submitted'] == '1') { echo "Form submitted!"; } ?> <form action="<?php echo $_SERVER['PHP_SELF']; ?>"> <input type="hidden" name="submitted" value="1" /> <input type="submit" value="Submit!" /> </form> </body> </html>
It looks fairly straightforward, right? The problem has to do with that $_SERVER['PHP_SELF'] variable. The intent here is that PHP will display the path and name of the current page so that the form knows to submit back to the same page. The problem is that $_SERVER['PHP_SELF'] can actually be manipulated by the user. Let's say as the user I change the URL from http://www.webadminblog.com/example.php to http://www.webadminblog.com/example.php"><script>alert('xss');</script>. This will end the form action part of the code and inject a javascript alert into the page. This is the very definition of cross site scripting. I can't believe that with as long as I've been writing in PHP and as long as I've been studying application security, I've never realized this. Fortunately, there are a couple of different ways to fix this. First, you could use the HTML entities or HTML special character functions to sanitize the user input like this:
htmlentities($_SERVER['PHP_SELF]);
htmlspecialchars($_SERVER['PHP_SELF]);
This fix would still allow the user to manipulate the URL, and thus, what is displayed on the page, but it would render the javascript invalid. The second way to fix this is to use the script name variable instead like this:
$_SERVER['SCRIPT_NAME'];
This fix would just echo the full path and filename of the current file. Yes, there are other ways to fix this. Yes, my code example above for the XSS exploit doesn't do anything other than display a javascript alert. I just wanted to draw attention to this issue because if it's found it's way into my code, then perhaps it's found it's way into yours as well. Happy coding!
OWASP Top 10 – 2010
This presentation was by Dave WIchers, COO of Aspect Security and an OWASP Board Member. My notes are below:
What's Changed?
- It's about Risks, not just vulnerabilities
- New title is: "The Top 10 Most Critical Web Application Security Risks"
- OWASP Top 10 Risk Rating Methodology
- Based on the OWASP Risk Rating Methodology, used to prioritize Top 10
- 2 Risks Added, 2 Dropped
- Added: A6 - Security Misconfiguration
- Was A10 in 2004 Top 10: Insecure Configuration Management
- Added: A8 - Unvalidated Redirects and Forwards
- Relatively common and VERY dangerous flaw that is not well know
- Removed: A3 - Malicious File Execution
- Primarily a PHP flaw that is dropping in prevalence
- Removed: A6 - Information Leakage and Improper Error Handling
- A very prevalent flaw, that does not introduce much risk (normally)
- Added: A6 - Security Misconfiguration
- A1- Injection: Tricking an application into including unintended commands in the data sent to an interpreter. (http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet)
- A2 - Cross Site Scripting (XSS): Raw data from attacker is sent to an innocent user's browser. For large chunks of user supplied HTML, use OWASP's AntiSamy to sanitize this HTML to make it safe. (http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)
- A3 - Broken Authentication and Session Management: Means credentials have to go with every request. Should use SSL for everything requiring authentication.
- A4 - Insecure Direct Object Reference: This is part of enforcing proper "Authorization", along with A7 - Failure to Restrict URL Access.
- A5 - Cross Site Request Forgery (CSRF): An attack where the victim's browser is tricked into issuing a command to a vulnerable web application. Vulnerability is caused by browsers automatically including user authentication data with each request. (Check out OWASP CSRFGuard, OWASP CSRFTester, http://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet)
- A6 - Security Misconfiguration: All through the network and platform. Don't forget the development environment. Think of all the places your source code goes. All credentials should change in production.
- A7 - Failure to Restrict URL Access: This is part of enforcing proper "authorization", along with A4 - Insecure Direct Object References.
- A8 - Unvalidated Redirects and Forwards: Web application redirects are very common and frequently include user supplied parameters in the destination URL. If they aren't validated, attacker can send victim to a site of their choice.
- A9 - Insecure Cryptographic Storage: Storing sensitive data insecurely. Failure to identify all sensitive data. Failure to identify all the places that this sensitive data gets stored. Failure to properly protect this data in every location.
- A10 - Insufficient Transport Layer Protection
OWASP Top 10 Risk Rating Methodology
- Attack Vector (How hard for an attacker to use this flaw - 1 (Easy), 2 (Average), 3 (Difficult))
- Weakness Prevalence (How often is it found - 1 (Widespread), 2 (Common), 3 (Uncommon))
- Weakness Detectability (How hard is it for an attacker to find the flaw - 1 (Easy), 2 (Average), 3 (Difficult))
- Technical Impact (1 (Severe), 2 (Moderate), 3 (Minor))
This is generic across the internet, not specific to any organization.
Started a new "Prevention Cheatsheet Series" that the Top 10 references (XSS, SQL Injection, Transport Layer Security, CSRF, Direct Object Reference).
What is actually being released is RC1 of the Top 10 and they are encouraging people to provide comments through the end of the year and then use that feedback to post the final Top 10 in January 2010.
Buildng and Stopping Next Generation XSS Worms – OWASP AppSec NYC 2008
I was originally planning on going upstairs for the SaaS Security presentation, but I had to come downstairs again to get my lunch and this topic seemed interesting, especially given the prevalence of cross site scripting in websites (see OWASP Top 10). The presentation was by Arshan Dabirsiaghi, the director of research at Aspect Security. He actually began by talking about Clickjacking and said that Jeremiah Grossman and RSnake gave up enough clues for him to figure out the exploit as far as Adobe flash goes and says that he'd rate the vulnerability a 7/10 in flash and an overall 10/10. Example non-weaponized exploit at http://i8jesus.com/stuff/clickjacking/test1.html using iframes and CSS. Suggested fix is to apply framebreakers to your page.
Is an XSS worm really a worm?
5 components of a worm:
- Reconnaissance - "[the worm] has to hunt out other network nodes to infect"
- Attack - "[components] used to launch an attack against an identified target system"
- Communication - "nodes in the network can talk to each other"
- Command - "nodes in the worm network can be issued operation commands"
- Intelligence - "the worm network needs to know the location of the nodes as well as characteristics about them"
Short answer: 3/5 - probably
How are XSS worms different from traditional?
- Infection model - Current model requires user interaction, worm strictly contained within web application, passive and localized, no Warhol worms (15 mins of fame).
- Payload capability - Perform any application function (money transfer, close account). XSSProxy/Attack API. Malware (yikes)
- Target shift - Internet worms can own everything both in front of and behind a firewall (island hopping).
- Penetration - Need to trick the user into spreading between sites using a 3rd party proxy.
Traits of Current XSS Worms
- Static payloads
- Passive infection strategy
- Staty on the same domain (don't say nduja)
- Uncontrolled growth
- No command and control
Current Incident Response Options
- Fix the vulnerability
- Manual purging - can only be done by experts and doesn't scale
- Database snapshot restore - effectively removes all worm data from tained columns, but forces loss of other application data
- Search & Destory - works now. Tricky in the future, but possible.
Next Gen XSS Worm Reconnaissance: A reconnaissance component will be added to the client side to find more web applications to infect. Nodes can use HTML5 Workers/Google Gears WorkerPool/<insert tomorrow's new RIA technology>. What about SOP? Old and busted: utilize 3rd party proxy (a la jikto ~2007). What attackers should be doing now: malware - no SOP! Next gen hotness: cross-site XHR, XDR, postMessage. Allows cross-site bidirectional communication. Servers must opt in, like Flash, so absolutely no security issues there (kidding)
Cross-site communication in HTML5
- postMessage(): Cross-domain communication based on strings. What do developers do with strings? JSON/eval() SiteA + JSON + SiteB = Shared Security
Staniford, Paxson & Weaver's Reconnaisance Techniques
- "hit list scanning"
- Permutation Scanning
- Topological Scanning (not without malware, cross-site XHR)
Next Gen XSS Worm Attack: An attack component will be added to the client side. New client side piece delivered with reconnaissance piece to attack other off-domain web apps. 85% of websites have XSS (how much is reflected vs stored?) How likely is it to fnd a stored XSS in another web app
Polymorphic Javascript: javascript can be highly mutated
Next Gen XSS Worm Communication: A communication component will never occur in a XSS worm. Can't communicate directly from victim browser to another victim browser. "centralization" in worms is just another word for weakness.
Next Gen XSS Worm Command: A command component will be added to the worm payload. Communicationw ith operator necessary for command-and-control structure, data delivery (new target info, soruce updates, etc)
- Attacker quietly posts signed payloads
- Victim creates token
- Victim queries Google form token using JSON
- Victim finds a signed result
- Executes the signed payload
Next Gen XSS Worm Intelligence: An intelligence component will be used after initial worm stages, it can't be trusted (adversaries can poison). XSS worms probably don't need this, they typically follow a pattern where the first 24 hours it reaches massive infections through epic growth rate. After that, gone and never seen again.
Ways to Prevent Next Gen XSS Worms
- search+destroying polymorphed javascript
- on demand exploit egress filters: popular sites need agile response techniques
- OWASP AntiSamy - safe rich input validation. Uses a positive security model for rich input validation. High assurance mechanism for stopping XSS (and phishing) attacks
- utilizing cross-domain workflows: letting the browser SOP protection prevent cookie disclosure + sensitive application information
- browser content restrictions: Doesn't make sense in a DOM. Requires parsers to honor end tag attributes.