I wanted to make sure I fully understood what was going on under the hood here so I started asking questions about the static testing and how it works. They've got a nice looking portal where you name your application, give it a version, assign it to a group of developers, and point it to your compiled code (WAR, EAR, JAR, etc). Once you upload your binaries, their system basically runs a disassembler on it to get it into assembly code. It's then at this level that they start looking for vulnerabilities. They said that this process takes about 3 days initially and then maybe 2 days after the first time because they are able to re-use some data about your application. Once complete, they say they are able to provide you a report detailing your vulnerabilities and how to fix them.

The thing that immediately struck me as worth noting here was the 2-3 day turnaround. This means that our developers would need to wait a fairly substantial amount of time before getting any feedback on the vulnerability status of their code. In a world full of Agile development, 2-3 days is a lifetime. Compare that to static source code testing where you get actionable results at compile time. The edge here definitely goes to source code testing as I believe most people would prefer the near-instant gratification.

The next thing worth noting was that they are taking binary files and disassembling them in order to find vulnerabilities. This lends itself to one major issue which is how can you determine with any accuracy the line number of a particular vulnerability written in let's say Java from assembly code generated by disassembling the binaries. By default, it's simply not possible. This vendor claimed that they can by adding in some debug strings at compile time, but even then I'd contend that you're not going to get much. I'm guessing they have some heuristics that are able to tell what function generated a set of assembly code, but I'm extremely skeptical that they can do anything with variable names, custom code functions, etc. I've seen some source code scanners, on the other hand, that not only tell you what line of code is affected, but are able to give you an entire list of parameters that have been consequently affected by that vulnerability. The edge here definitely goes to source code testing.

The main benefit that I can see with binary testing vs source code testing is that we can test code that we didn't write. Things like APIs, third-party applications, open source, etc are all things that we now have visibility into. The only problem here is that while we now can see the vulnerabilities in this software, they are unfortunately all things that we can't directly influence change in, unless we want to send our developers off to work on somebody else's software. I'd argue that scanning for vulnerabilities in that type of code is their responsibility, not ours. Granted, it'd be nice to have validation that there aren't vulnerabilities there that we're exposing ourselves to by uptaking it, but in all honesty are we really going to take the time to scan somebody else's work? Probably not. The edge here goes to binary testing with the caveat being that it's in something that I frankly don't care as much about.

This isn't the complete list of pros and cons by any means. It's just me voicing in writing some concerns that I had about the technology while talking to this particular vendor. In my opinion, the benefits of doing source code testing far outweigh any benefits that we could get from testing compiled binary files. What do you think about the benefits of one versus the other? I'd certainly love for someone to try to change my mind here and show me where the real value lies in binary testing.

As a case in point, we're in the middle of our annual audit by one of those "Big Four" audit firms which I won't name here to protect the innocent. I sent an email checking in with our auditors to make sure that they had everything they needed before we went into our four-day holiday weekend. They said that they had received everything they needed except for documentation on "privileged users from the current OS and Database environments" as well as "evidence of current password settings from the application servers, OS, and Database". We go through a round of translation from Auditorese to Techie and figure out that they want exports of some specific user, profile, role, and privilege tables from the database and copies of /etc/passwd, /etc/shadow, and /etc group from the servers.

So we obtain the requested documentation and I shoot them back an email message to find out their proposed method for transferring the files. Secure FTP? No. PGP encryption? Nope. Their response back was astonishing:

How large do you think they'll be? Email should be fine.

Seriously? These are the guys that we're paying to verify that we're properly protecting our systems and they're suggesting that sending our usernames and password hashes via cleartext email is an appropriate method of file transfer. I respond back:

I'm not really concerned about the size of the files, but rather, the data that they contain. Sending files containing the users, groups, and password hashes for our financial systems via cleartext is probably not a good plan considering the point of this process is protecting that data.

And they respond with:

Whatever you'd like Josh. As long as you have the files as of today, we're good.

So now I'm convinced that auditors (or at least these auditors) view security as nothing more than a checklist. The people telling me what I need to do in order to protect my systems really have no clue about the fundamentals of security. If it's not on their checklist, then it must not be of importance. In this particular situation it may be easier or more convenient to send the documents via email, but any security professional worth their salt would tell you that's not secure nor appropriate for that data. Either our auditors hold themselves to a very different standard than the rest of us security professionals or they just don't understand security unless it's on a checklist.

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!

Agenda

1. Introduction to XML/Web Services Threats
2. Techniques for Defending XML Threats
3. XML Attack Examples and Classification
4. 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

XML Security Gateway - Base Requirements

• Certified PKI Infrastructure (DOD PKI)
  • X509 Path validation
  • Sign/verify, SSL initiation, SSL termination
• Certified Security Architecture (FIPS)
  • Key management and storage
  • Physical security device
• Transaction Privacy
  • Encryption, decryption, SSL
• Transaction Integrity
  • Digital signature, signature verification, schema validation
• Transaction Accountability
  • Archiving, logging, reporting, and monitoring
• Transaction Threat Mitigation
  • Intrusion detection and prevention
  • Rate-based rules, size-based rules, anti-virus detection, pattern recognition
  • Structural integrity, protocol adherence, athorization attempts

XML Attack Examples and Classification

1. SQL Injection Attack
2. Denial of Service Attack
3. XSD Mutation Attack

XML Web Services SQL Injection Attack Example

• How to Attack
  • Construct SQL escape sequences
  • Construct SQL 1=1 query
  • Inject into XML node values
• Discovered Exposure
  • Sensitive data loss
  • Database corruption
• Used "SOAPSonar" tool to load WSDL and send responses

SQL Injection - XML Gateway Secured

• How to Defend
  • Deploy XML Gateway
  • Enable pattern scanning IDP rules
  • Configure response message size and complexity limits
• Advantages
  • Prevent Data Loss
  • Alert and Quarantine Attempted Breaches

XML Web Services based Denial of Service Attack

• How to Attack
  • Loading client with concurrent simultaneous threads
  • Coercive parsing attack
• Discovered Exposure
  • Unlimited message flow
  • Unfair service SLA distribution
  • Back-end CPU and I/O Saturation

Denial of Service - XML Gateway Secured

• How to Defend
  • Deploy XML gateway
  • Set allowed transaction rates (Group, user, or IP)
• Advantages
  • Message flow limited to specified rate

Another Example: Denial of Service through Coercive Parsing

• Sending malformed XML data (removing the ">" end tag) creates increased time to parse a request

XML Web Services Based XSD Mutation Attack

• How to Attack
  • Obtain WSDL
  • Derive message structure and types from WSDL schema
  • Send SOAP message mutations based on schema
• Discovered Exposure
  • Code paths not handled for exceptions
  • Stack traces returned with implementation details
  • Application failure

XSD Mutation Attack - XML Gateway Secured

• How to Defend
  • Deploy XML Gateway
  • Enforce inbound message structure and type validation
  • Cleanse outbound data (stack traces, sensitive data)
• Advantages
  • Reduce parser impact on web service
  • Remove vendor and implementation details in response
  • Protect application layer code paths on web service

XSD Mutation - Secured

1. Deploy specialized XML Gateways - Packet firewalls and HTML application firewalls are insufficient
2. Validate XML against a robust schema
3. Tighten Schema: restrict unbounded strings, etc
4. Enforce XML specific detection rules (node depth, recursive payloads)

Best Practices for Countermeasures

• Information Control - Outbound
  • Restrict SOAP Faults
  • Protect Sensitive Information
  • Audit Transaction Flows
• Information Control - Inbound
  • Tighten Payloads
  • Enforce SLA
  • Disallow SQL, virus, malicious code
• Use Web Services Penetration Testing Product
• Deploy XML web Services Gateway
• Deploy Centralized XML Security

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

The 10000' View For Most Organizations

• Legal and Regulatory Compliance: Because we have to
• Incident Prevention, Risk Mitigation and Cost of Entry: Because this is what everyone else does
• Competitive Advantage: Really?

Regs are Not App Sec Friently...

• Regulations, contracts, and RFPs are usually based on the notion of "reasonable effort" - state regulations, HIPAA, FTC, SEC, Red Flags Rule
• When regulations do get technical, they focus on old school security fetishes like firewalls, SSL, encryption, biometric passes and server rooms

A Few Examples

• PCI Prioritized Approach
• Massachusetts 201 CMR 17.00
• The encryption exemption in state data breach notification laws
• HIPAA Notification Form
• Recent SEC Action
• Most of the contracts/RFPs/Vendor security whitepapers I have seen...

A Real World Example of Where Your PII Lives...

• Small company with a few dozen employees sells widgets over the Internet
• Pay an outsourced team to develop a Joomla/Drupal/whatever site to build a widget-lovers community where users can connect.  All sorts of PII involved in the app
• They deploy their site on a shared hosting/VPS model and basically only interact with the App from a web admin interface
• They know a bit about the technical details of their app but not much.  Actually, no actual web developers were really involved in the building or deployment of the app

Here is What Company A Did...

• Asked their developer team in India to develop code securely.  Referenced OWASP Top 10 or similar list.
• Told their dev team that services and DB users needed to run with minimum privilege.  Dev team balked.  Company A agreed to pay a bit extra.
• ...
• ...

Here's What Company B Did...

• Installed anti-virus on all employee machines
• Bought a firewall for the corporate network
• Maybe even got two-factor tokens for network access
• Made sure everything is going over SSL everywhere,.
• Put a biometric reader in the data center
• Encrypt all laptops

Company B is more likely to be in compliance with state laws and other regulations.

Company B is also more likely to suffer a data breach.

So the only thing left to finance your application security program is the "reasonable spend" argument...

As a community we need to get some consensus on what constitutes a reasonable spend...

About the OWASP Security Spending Benchmarks Project

• First survey focused on general web application spending.
• Second survey focused on cloud computing.
• Responses currently being gathered for third survey
• Approximately 50 companies profiled in each case
• We do not collect IP addresses
• Most of the partners are security vendors
• Relatively small respondent base
• Meant to stimulate a discussion on security spending benchmarks

Percentage of Development Headcount Spent on Security

• 41% had less than 2%
• 20% had 5-10%
• 18% didn't know
• 10% had 2-5%

Percentage IT Budget on Web Application Security

• 33% don't know
• 24% had 5-10%
• 12% had 1-5%
• 12% had 10-20%

Organizational Responsibility for Security Reviews

• 67% in IT Security

47% of companies surveyed provide developers with security training via internal resources.

• Organizations that have suffered a public data breach spend more on security in the development process than those that have not.
• Web application security spending is expected to either stay flat or increase in nearly two thirds of companies
• Half of respondents consider security experience important when hiring developers

Cloud Summary

• SaaaS is in much greater use than IaaS or PaaS.
• Security spending does not change significantly as a result of cloud computing.
• Organizations are not doing their homework when it comes to cloud security.
• The risk of an undetected data breach is the greatest concern with using cloud computing, closely followed by the risk of a public data breach.
• Compliance and standards requirements related to cloud computing are not well understood.

Future of Project

• Currently collecting responses for the third survey
• Partners assist in promoting survey, analyzing results, and providing strategic input
• Current status of project can always be found on OWASP website
• New partners are always welcome

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

Staffing the Team

• Decide how to staff your team and what skills you need.  Possible candidates include:
  • Experienced Application Testers
    • This is ideal from a skills standpoint, but people in this category may be harder to find, cost more, may not be familiar with your company and or fit its culture.
  • Experienced Developers
    • Developers will have a good understanding of the technologies, but may not understand security principles.  Their focus is on what an application is intended to do, not what it can be made to do.
  • Other IT Security Professionals
    • They have a good understanding of security principles, but may lack specific technical skills.  However, some skills may provide a useful overlap, like experienced OS or network testers.
  • Service and Project Managers
    • Building a new team, defining processes and standards, managing work flow and handling customer relations requires a set of skills as important, but distinct, from technical testing skills.

Selecting Tools

• There are a lot of options when it comes to tools.  What you choose depends on the services you want to provide, your team's skills and your budget.
  • Commercial vs. Free or Low Cost Tools
    • Commercial tools scale to support enterprise use, utilize a higher degree of automation and come with product support.  They also come with a big price tag.
    • Open source and low cost tools allow for more customization, and are free or inexpensive, usually have a supportive user community, but often require a higher degree of user knowledge and skill.
  • Types of Tools
    • Vulnerability Scanners
      • Commercial examples include IBM AppScan, HP WebInspect and Cenzic Hailstorm
    • Source Code Analysis
      • There are commercial options like Fortify or open source tools like the OWASP Yasca Project
    • Client Side Web Proxies
      • Options include WebScarab, Burp Suite and Charles Proxy
    • Other Tools
      • These include password crackers, hex editors, text extractors, browser plug-ins, integrated development environments, network mapping, network traffic analysis, and exploitation tools

What to Assess

• Measuring an application's risk:
  • The Types of Users
    • Privileged Users, employees, suppliers, customers or the general public
  • The Sensitivity of the Data
    • Intellectual Property, PII or other regulatory requirements
  • Availability and Integrity Requirements
    • The impact to the business if compromised
  • Technology and Environmental Consideration
    • What technologies are used, where is it deployed,...

Gather Necessary Information

• Before starting an assessment you will need to gather important information:
  • Application contacts
  • Server contacts
  • The process for getting accounts
  • A description of what the application does
  • The description or diagram of the system architecture

Assessment Planning Meeting

• Meet with the application development and support teams:
  • Get a demonstration of the application
  • Review the information gathered to support the assessment
  • Discuss the testing process and ground rules
    • No changes to the code during testing
    • Backups of the application servers and databases
    • How to address system crashes during testing
    • Database corruption issues
    • Emails generated by the application

Testing Notifications

• You should have a process to notify affected parties before the actual testing begins.
  • Key system contacts
  • Intrusion detection teams
  • Other assessors
• Information to include in the notification:
  • Source IP addresses
  • Target IP addresses, URL, system name
  • Testing schedule
  • Assessment team contacts

Conducting the Assessment

• If you are using automated scanning tools, beware of false positives and negatives
  • Pattern recognition has limitations
  • Combine various testing methods
    • Automated scanning
    • Code review
    • Manual testing
  • Learn what your tools do and do not do well
  • Validate every finding
  • Keep detailed notes

Establish Standards

• Assessments performed by two different people or the same person over time, may result in the same finding being presented very differently
  • This may result in inconsistent descriptions of the vulnerability or different recommendations for remediation
  • Without standard findings you may also find it difficult to produce meaningful metrics about discovered vulnerabilities

Standard Findings

• Opinions about how to standardize software vulnerabilities are like noses, everyone has one.
• At Boeing we have categorized vulnerabilities into approximately 70 standard findings like:
  • SQL Injection
  • Path Traversal
  • Session Fixation
  • Excessive Authentication Attempts
  • Forced Browsing
  • System information Leakage

Data Elements for Standard Findings

• Each finding is made up of the following data elements:
  • Name
  • Control Classification
  • Severity (Likelihood + Impact)
  • Company Policy References
  • Industry References
  • Summary Description (one sentence)
  • Impact Statement (one sentence)
  • Detailed Description (basic introduction to vulnerability + detailed description of how it manifests within their application)
  • Recommendation (standard remediation recommendations tied into SDLC practices)

Control Classifications

• We group individual vulnerabilities into control classifications.  This helps us determine how effective we are at implementing control types.
• Our classifications:
  • Input and output controls
  • Authentication and password management
  • Authorization and access management
  • Sensitive information storage or transmission
  • System configuration and management
  • General coding errors

Reporting Findings

• Developing a standardized reporting template will allow you to deliver a consistent, branded message
  • Cover Page
    • Provides information necessary to identify the assessment, what was assessed and who the key people were
  • Executive Summary
  • Findings Summary
  • Detailed Findings
  • Conclusion
    • Summary of assessment results, discussion of next steps and links to additional resources
  • Appendixes
    • Information on how severity ratings are determined, description of control classifications
  • Attachments
    • Typically raw scan files

Managing Corrective Actions

• Once a report is issued you need a closed loop process to ensure serious issues are addressed.  Considerations include:
  • Tracking Findings:
    • Critical and high findings should be tracked to resolution
    • Medium findings are less straight forward
    • Low or informational findings may not be value added
  • Customer Responses to Findings:
    • Implement a technical fix to address the finding
    • Implement a process fix to address the finding
    • The business formally accepts the risk of not remediating

When to Re-Evaluate an Application

• Depending on the number of applications you support and the frequency with which they change you may need to establish re-evaluation guidelines.  Soem criteria to consider include:
  • Fixes to previously accepted risk
  • User population changes
  • Data sensitivity changes
  • Business's dependency on the application has increased
  • Authentication mechanism has changed
  • Authorization mechanism has changed

Application Assessment Process Flow Version

• Create a document that shows the process flow for both requested and targeted assessment (ask for document from presenter?)
• Formal closure process

Conclusion

• Building an assessment team from the ground up takes:
  • Executive Support
  • A lot of planning
  • Staffing
  • The right tools
  • Training
  • Standards
  • Supporting Processes

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

#8

• Eddy Nigg at StartCom Ltd...
  • or John Doe at SSL Cert Reseller
• Job: Developer/QA
• Why: Has access to create wildcard SSL certs for any domain
• Impact: Would allow an attacker to steal any information they were able to man in the middle.
  • Previously demonstrated bad security
  • Much smaller and therefore less controlled than Verisign or Thawt

#7

• John Doe at Authorize.net
• Job: Network admin/Server admin
• Why: Has the ability to see the vast majority of online transactions.
• Impact: Would allow an attacker to get PII and credit card information for the bulk of the US online shopping population and many international shoppers as well

#6 (RSnake recants this one after dinner last night)

• John Doe at Mozilla
• Job: Has check-in access
• Why: Has the ability to change functionality within the browser, including installing new SSL certs.
• Impact: Would allow the attacker to man in the middle and read all SSL traffic.
  • Almost no documentation
  • The verification process is very open and subject to tampering - meaning the update mechanism isn't probably much better

#5

• Chirag and Floyd at Adwords
• Job: Whomever checks in code
• Why: Has access to millions of websites because it is XSS
• Impact: Can be leveraged for stealing cookies and hijacking web functionality
  • Is embedded in millions of web pages
  • Is already obfuscated heavily
  • Is seen daily by the bulk of the Internet population
  • Begs the question about CDNs in particular

#4

• John Doe at Google's Postini
• Job: Programmer/Server admin
• Why: Controls and can view the bulk of the world's email - including Gmail
• Impact: Would enable attacker to steal credentials, spoof conversations, tamper with data, introduce malware, etc
  • More dangerous than Adwords because it's passive

#3

• John Doe at 1 Wilshire
• Job: NOC Monkey
• Why: One of the largest peering centers on the west coast
• Impact: Can tamper with machines, install malware, inject malicious traffic, intercept communications, etc...
  • Most amount of data links in one physical location
  • CIA has already demonstrated interest in choke points in San Francisco as outed by Mark Klein

#2

• John Doe at gtei.net
• Job: Network Admin/Server Admin
• Why: Controls 4.2.2.2 and 4.2.2.3
• Impact: Can be used to subvert a huge chunk of Internet traffic by giving erroneous DNS answers
  • Used by default in many devices
  • Used by tons of individuals and companies who are lazy
  • Can be used in very targeted attacks for a very short period of time

#1

• John Doe at iDefense
• Job: Security Engineer/Consultant
• Why: Consults for and is owned by Verisign, who owns Network Solutions, who controls authoritative DNS for ".com"
• Impact: Would allow the bulk of the Internet traffic to be modified
  • Heavily monitored and protected but still could lead to temporary and targeted compromise
  • More dangerous than 4.2.2.2 because it controls all of .com and not just a subset of users

Disappointed?  Upset?

The room is full of people who care that your feelings are hurt.

The List

1. John Doe at iDefense
2. John Doe at gtei.net
3. John Doe at 1 Wilshire
4. John Doe at Google's Postini
5. Chirag and Floyd at Adwords
6. John Doe at Mozilla
7. John Doe at Authorize.net
8. Eddy Nigg at StartCom Ltd.
9. Giorgio Maone of NoScript
10. John Doe at C|Net

Questions/Comments?

• Robert Hansen
  • Robert_at_sectheory d0t c0m
  • http://www.sectheory.com
  • http://ha.ckers.org/
  • Detecting Malice
    • http://www.detectmalice.com/
  • XSS Book: XSS Exploits and Defense
    • ISBN: 1597491543

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)

1. 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)
2. 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)
3. A3 - Broken Authentication and Session Management: Means credentials have to go with every request.  Should use SSL for everything requiring authentication.
4. A4 - Insecure Direct Object Reference: This is part of enforcing proper "Authorization", along with A7 - Failure to Restrict URL Access.
5. 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)
6. 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.
7. A7 - Failure to Restrict URL Access: This is part of enforcing proper "authorization", along with A4 - Insecure Direct Object References.
8. 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.
9. 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.
10. 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.

"To measure is to know." - James Clerk Maxwell

"Measurement motivates." - John Kenneth Galbraith

Metrics do Matter

1. Metrics quantify the otherwise unquantifiable
2. Metrics can show trends and trends matter more than measurements do
3. Metrics can show if we are doing a good job or bad job
4. Metrics can show if you have no idea where you are
5. Metrics establish where "You are here" really is
6. Metrics build bridges to managers
7. Metrics allow cross sectional comparisons
8. Metrics set targets
9. Metrics benchmark yourself against the opposition
10. 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

Use Enumerations

• Enumerations help identify specific software-related items that can be counted, aggregated, evaluated over time
• CVE - Common Vulnerabilities and Exposures
• CWE - Common Weakness Enumeration
• CAPEC - Common Attack Pattern Enumeration and Classification

Organizational Metrics

• Percentage of application inventory developed with SDLC (which version of SDLC?)
• Business criticality of each application in inventory
• Percentage of application inventory tested for security (what level of testing?)
• Percentage of application inventory remediated and meeting assurance requirements
• Roll up of testing results

Organizational Metrics

• Cost to fix defects at different points in the software lifecycle
• Cost of data breaches related to software vulnerabilities

Testing Metrics

• Number of threats identified in threat model
• Size of attack surface identified
• Percentage code coverage (static and dynamic)
• Coverage of defect categories (CWE)
• Coverage of attack pattern categories (CAPEC)

SANS Top 25 Mapped to Application Security Methods (CWE, Title, Education?, Manual Process?, Tools?, Threat Model?)

Weakness Class Prevalence based on 2008 CVE data (Mitre?)

Basic Metrics: Defect Counts

• Design and implementation defects
  • CWE identifier
  • CVSS score
  • Severity
  • Likelihood of exploit

Automated Code Analysis Techniques

• Static Analysis (White Box Testing)
• Dynamic Analysis (Black Box Testing)

Manual Analysis

• Manual Penetration Testing
• Manual Code Review
• Manual Design Review
• Threat Modeling

WASC Web Application Security Statistics Project 2008

• Goals
  • Identify the prevalence and probability of different vulnerability classes
  • Compare testing methodologies against what types of vulnerabilities they are likely to identify
• Summary
  • 12186 web applications with 97554 detected vulnerabilities
  • More than 13% of all reviewed sites can be compromised completely automatically
  • About 49% of web applications contain vulnerabilities of high risk level detected by scanning
  • Manual and automated assessment by white box method allows to detect these high risk level vulnerabilities with the probability up to 80-96%
  • 99% of web applications are not compliant with PCI DSS standard
• Compare to 2007 WASC Project
  • Number of sites with SQL Injection fell by 13%
  • Number of sites with Cross-site Scripting fell 20%
  • Number of sites with different types of Information Leakage rose by 24%
  • Probability to compromise a host automatically rose from 7 to 13%

• 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