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!
Techniques in Attacking and Defending XML/Web Services
This presentation was by Jason Macy and Mamoon Yunus of Crosscheck Networks - Forum Systems. It wins the award (the one I just made up) for being the most vendor-oriented presentation at the conference. Not that it wasn't an interesting presentation, but their solution to defend against most of the attacks was "Use an XML Gateway" (guess what Forum Systems sells?) and the attacks were all presented using the CrossCheck SOAPSonar tool. I realize that being a vendor they probably have more knowledge than most in the field, but being an Open Source conference, you'd think they would have demonstrated using a free/open tool (SOAPUI?) and talked more about non-hardware solutions to fix the issues. My notes from the session are below:
Agenda
- Introduction to XML/Web Services Threats
- Techniques for Defending XML Threats
- XML Attack Examples and Classification
- Review sample attacks
Introduction to XML Threats
- Explicit Attacks
- Forced Disruption
- Information Theft
- Vendor Discovery
- Implicit Vulnerability
- Perimeter Breach (embeeded virus, malware)
- Infrastructure Malfunction (parser and data processing failures)
New Attack Vectors
- Protocol Firewalls are blind to XML
- Malware and virus delivered via SOAP attachments
- WSDL exposes schema and message structure
- Injection attacks exposed via XML parameters
- Data replay attacks
Security Testing - Base Requirements
- Security Framework
- Sign, ENcrypt, Decrypt, SSL
- Identity Framework
- Basic auth, SSL auth, WS-Security token auth
- Parameter Injection
- Database or file driven
- Permutations for security, identity, and SOAP/XML
- Concurrent Client Simultaneous Loading
- Denial of Service Testing
- SOAP with Attachments
- Malware and Virus testing
- Dynamic XSD Mutation
- Derive SOAP vulnerability profile from WSDL schema
The OWASP Security Spending Benchmarks Project
This presentation was by Boaz Belboard, the Executive Director of Information Security for Wireless Generation and the Project Leader for the OWASP Security Spending Benchmarks Project. My notes are below:
It does cost more to produce a secure product than an insecure product.
Most people will still shop somewhere, go to a hospital, or enroll in a university after they have had a data breach.
Why do we spend on security? How much should we be spending?
- Security imposes extra costs on organizations
- The "security tax" is relatively well knnown for network and IT security - 5 to 10% (years of Gartner, Forrester, and other studies)
- No comparable data for development or web apps
- Regualtions and contracts usually require "reasonable measures". What does that mean?
OWASP Security Spending Benchmarks Project
- 20 partner organizations, many contributors
- Open process and participation
- Raw data available to community
Reasons For Investing in Security
- Contractual and Regulatory Compliance
- Incident Prevention, Risk Mitigation
- Cost of Entry
- Competitive Advantage
Technical and Procedural Principles
- Managed and Documented Systems
- Business-need access
- Minimization of sensitive data use
- Security in Design and Development
- Auditing and Monitoring
- Defense in Depth
Specific Activities and Projects
- Security Policy and Training
- DLP-Type Systems
- Internal Configurations Management
- Credential Management
- Security in Development
- Locking down internal permissions
- Secure Data Exchange
- Network Security
- Application Security Programs
Building an In-House Application Security Assessment Team
This presentation was by Keith Turpin from The Boeing Company. About three years ago, all of Boeing's assessments were coming from outsourced service providers. They realized that they were unable to have control over the people and process and had difficulties integrating the controls into the SDLC and decided to bring these functions in house. The goal of this presentation is to show some of the issues they ran into and how they addressed those problems. My notes from the presentation are below:
Contraced Services Considerations
- Some Advantages:
- Highly skilled
- Established tools, processes, and standards
- Unbiased
- Available as needed
- Some Disadvantages:
- Expensive, especially for an extended engagement
- Less control and flexibility
- Not familiar with company processes and culture
- Rotating staff
Planning
- Considerations for establishing an internal team:
- Time to staff and train the team
- Overlap of external and internal teams
- Development of processes and standards
- Acquiring necessary tools
Service Model
- Define the services your team will provide. This will be greatly influenced by:
- The team's size and skills
- The number of applications you have to support
- The tools available
- The level of executive support
- The funding model
- Who pays for your services
- The team's role
- Development support, pre-deployment testing or post deployment auditing and pen testing
The 10 Least-Likely and Most Dangerous People on the Internet
This presentation was by Robert "RSnake" Hansen and was designed to be a fun conversation to have over drinks with security people. I feel privileged to have been one of those security people who he talked about this with beforehand. A very interesting topic about the non-obvious threats that may or may not exist. My notes are below:
Why?
- Because I use the Internet
- Because I'm a target
- Because most people don't know
- Because it's a fun conversation to have over drinks with security guys
- Maybe/hopefully you'll continue this conversation instead of just arguing!
Ground Rules
- Must be non-obvious and must be directly related to the Internet. Not:
- ...the President or any other gov'ernment official
- ...or someone involved with SCADA Systems/Brick and mortar
- Must be in control of some infrastructure or software, etc
- Must have the largest or widest negative impact possible for the least amount of work and least likelihood of being stopped
- No magic - must be real and dangerous
- They can't be "bad" people
- You can't take this list too seriously
How I Got Started
- Started thinking about core technologies that everything relies on
- Made a big list
- Shopped it around to dozens of security experts
- Assigned an arbitrary, unscientific, hand-wavy, risk-rating system of my own design
- Ranked them in order of how scared I am of them personally
#10
- John Doe at C|Net
- Job: Network Engineer
- Why: Controls com.com
- Impact: Largest collection point of typo traffic both for web adn email.
- Doesn't require anything overt or even indefensible
#9
- Giorgio Maone of NoScript
- Job: Consultant
- Why: Controls NoScript
- Impact: Nearly every security researcher on the planet - complete compromise. In general the most paranoid people on earth would be compromised.
- Builds arbitrary whitelists (ebay.com)
- Has changed functionality to subvert Adblock Plus
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.
Application Security Metrics from the Organization on Down to the Vulnerabilities
This presentation was by Chris Wysopal, the CTO of Veracode. My notes are below:
"To measure is to know." - James Clerk Maxwell
"Measurement motivates." - John Kenneth Galbraith
Metrics do Matter
- Metrics quantify the otherwise unquantifiable
- Metrics can show trends and trends matter more than measurements do
- Metrics can show if we are doing a good job or bad job
- Metrics can show if you have no idea where you are
- Metrics establish where "You are here" really is
- Metrics build bridges to managers
- Metrics allow cross sectional comparisons
- Metrics set targets
- Metrics benchmark yourself against the opposition
- Metrics create curiosity
Metrics Don't Matter (Mike Rothman)
- It is too easy to count things for no purpose other than to count them
- You cannot measure security so stop
- This following is all that matters and you can't map security metrics to them:
- Maintenance of availability
- Preservation of wealth
- Limitation on corporate liability
- Compliance
- Shepherding the corporate brand
- Cost of measurement not worth the benefit
Bad metrics are worse than no metrics
Security Metrics Can Drive Executive Decision Making
- How secure am I?
- Am I better off than this time last year?
- Am I spending the right about of money?
- How do I compare to my peers?
- What risk transfer options to I have?
Goals of Application Security Metrics
- Provide quantifiable information to support enterprise risk management and risk-based decision making
- Articulate progress towards goals and objectives
- Provides a repeatable, quantifiable way to assess, compare, and track improvements in assurance
- Focus activities on risk mitigation in order of priority and exploitability
- Facilitate adoption and improvement of secure software design and development processes
- Provide and objective means of comparing and benchmarking projects, divisions, organizations, and vendor products
Securing the Core JEE Patterns
This presentation was by Rohit Sethi, the Project Leader for the Secure Pattern Analysis Project at OWASP and he works at Security Compass, a security analysis and training company. My notes from the session are below:
- Before anyone starts building complex systems, they need to design.
- We create threat models on completed designs.
- What about during design?
- Book: "Core J2EE Patterns Best Practices and Design Strategies"
- If you use J2EE development, chances are you're using patterns documented here
- Core J2EE patterns are used extensively
- Patterns are used in JSF, Velocity, Struts, Tapestry, Spring, and Proprietary Frameworks
Example: Project: Analyze Patterns
Use to Implement:
- Synchronization Tokens as Anti-CSRF Mechanism
- Page-level authorizations
Avoid:
- XSLT and Xpath vulnerabilities
- XML Denial of Service
- Disclosure of information in SOAP faults
- Publishing WSDL files
- Unhandled commands
- Unauthorized commands
Project Goals
- Analyze patterns for security pitfalls to avoid
- Determine how patterns can implement security controls
- Provide advice portable to most frameworks
A security pattern is not the same as a security analysis of a pattern.
Uses
- Designing new web application frameworks (make the next generation of frameworks secure by default)
- Designing new apps that use the patterns
- Source code review of existing apps
- Runtime assessment of existing apps
- Integrate with threat modeling of new or existing apps
You can help:
- Tell developers
- Improve the analysis
Next Steps?
- Add code review and examples to the existing pattern book
- Look at other pattern books to see if there are other patterns that we should analyze
Our Dream
- New web application framework idea + Design-time security analysis = Secure-by-default web application framework
Threat Modeling
This presentation was by John Steven, the NoVA Chapter Lead and Senior Director of Advanced Technology Consulting at Cigital, Inc. He notes that this is not that MS thing, it is not going to help you find XSS, and is not going to help you with Risk Management. My notes are below:
Don't use threat modeling to help you with the things you already have checklists for.
Do this because you want to understand the intersection of your stakeholder's goals and the architecture.
What is a Threat?
- An agent who attacks you?
- An attack?
- An attack's consequence?
- A risk?
What is a Threat Model
- Depiction of
- The system's attack surface
- Threats who can attack the system
- Assets threats may compromise
- Some leverage risk management practices
- Estimate probability of attack
- Weight impact of successful attack
Threat
- Capability
- Access ot the system
- Able to reverse engineer binaries
- Able to sniff the network
- Skill Level
- Experienced hacker
- Script kiddie
- Insiders
- Resources and Tools
- Simple manual execution
- Distributed bot army
- Well-funded organization
- Access to private information
- Threats help
- Encourage thorough throught about how intentions for misuse
- Determine "out of bounds" scenarios
Threat Modeling as a Process
- Know thy enemy and how they attack you (who, what, how, why, impact, mitigation)
Threat Modeling - High-level Process
- Diagram Structure
- Identify Assets
- Identify Threats
- Stitch Threats onto Structure
- Enumerate Doomsday Scenarios
- Document Misuse/Abuse
- Enumerate Attack Vectors
- Iterate
1. Diagram the Software
- Different methods of diagraming (likes the whiteboard the best)
1.1 - Anchor in Software Architecture
Consider where attacks occur
Top-down
- Enumerate business objects
- Sensitive data
- Privileged functionality
Bottom-up
- Enumerate application entities
- Sensitive data
- Privileged functionality
Look for
- Middleware
- Open source
- Frameworks
1.2 - Identify Application Attack Surface
- Are there different privilege levels?
- Connectivity between services and processes
1.3 - Annotate with Design Patterns
- Are there pieces that whitebox testings is unable to analyze?
- What types of frameworks is the application using?
- Where are there command patterns?
- Where is there an inversion of control?
1.4 - Consider Patterns' Responsibilities
- Document specific standards for implementing each responsibility
- List out each pattern, piece of app, and associated standards
1.5 - Enumerate Potential Failures in Design Elements
1.6 - Find Key Structural Componenets
Component diagrams show critical choke points for security controls
1.7 - Identify Frameworks
Showing frameworks indicates where important service contracts exist 'up' and 'down'
1.8 - Explicitly Identify Controls
2 - Identify Assets
2.1 - Identify Critical Data Assets
- Do I have PII?
- Things that proxy for PII like sessions?
2.2 - Identify Interfaces as Proxies for Data
2.3 - Identify Assets flow through the System
- Assets exist not only in rest, but also flow through the system
- Think about where there are points you could stop the data from going
2.4 - Identify Critical Application Entities
2.5 - Identify 'Intermediate' Asset Objectives
Identify:
- Sensitive data
- Privileged function
Look out for:
- Proxies, facades, etc
- Services
- UI vs implementation
- Aggressive caching scheme
2.6 - Identify Equivalence-classes
- In essence an escalation of privilege connector
- Ex: Putting username and password and password reset questions on the same page puts them on the same equivalence-class without reauthentication and defeats the security control
3 - Identify Threat Agents
3.1 - Anchor Threats in Use Cases
- What is the dumbest things that a user can do?
- What is the most malicious thing a user can do?
4.1 - Identity Principal Resolution
- Arrows indicate resolution of principal/assertion propagation
4.2 - Place Threats on Diagram
4.3 - Show Authorization in Structure
- Coloration shows authorization by role
- Color modules by who you would need to be to access them and look where the colors change
- Has never NOT found a vulnerability for John
5 - Enumerate Doomsday Impacts
5.1 - Assign Threats Malicious Intent
- What is each Threat's motivation?
- What would drive escalation?
- Why would each try beyond the first hurdle?
5.2 - Instanstiate Doomsday Attack
6.1 - Add in Misuse Cases
Convert Actors to Threats
- Abuse - Make actors behave stupidly
- Misuse - Make actors deviant/evil
6.2 - 'Cache' Misuse in a 'Cookbook'
7 - Enumerate Attack Vectors
7.1 - Pilfer technology-specific security standards
7.2 - Pilfer community resources
7.3 - Pass technology-specific resources as your own
- When testing finds an attack:
- First, decide if its impact warrants further exploration
- Are additional impacts possible?
- Consider what conceptual goals the attack supports
- Then consider who could launch the attack against the application
- After analysis converges, iterate secure design