This leads me to the conclusion that security should be considered a fundamental part of code development and not an afterthought. We should be teaching security to students at a University level so that when they graduate, corporations don't spend valuable time re-training them on proper development techniques. I've heard rumors of large companies like Oracle actually being able to impact college curriculum by telling universities they simply won't hire developers without security training. Unfortunately, most companies aren't in a position to make demands like that, but it certainly wouldn't hurt to develop relationships with faculty at your local university and tell them what you'd like to see out of their students. I did some poking around on the internet and it seems like some professors are already starting to get the memo. For example, I found a great paper written by three professors at the USAF Academy Dept. of Computer Science called Incorporating Security Issues Throughout The Computer Science Curriculum where they say:

While the general public is becoming more aware of security issues, what are our universities doing to produce graduates ready to address our security needs?  Computer science as a discipline has matured to the point that students are regularly in tructed in software engineering principles--they learn the importance of life cycle issues in the development and maintenance of software.  Where are they receiving similar instruction on security concerns in the software life cycle?  The authors propose that security should be taught throughout every computer science curriculum--that security should always be a concern and should be considered in the development of all software just as structured programming and documentation are.

Gentlemen, I couldn't agree more.  Security needs to be a foundational piece of every Computer Science program in the country.  Not one class.  Not one professor.  Secure programming techniques need to be a consideration in every CS class in every university.  Universities teach students how to write functions, create object-oriented code, and do proper documentation, but when graduates don't know the basic tenets of input validation, then we have a real problem.  If you agree with me, then I challenge you to write to the Dean of your local CS program and ask them what they are doing to ensure graduates are familiar with secure coding practices.  I'd be very interested in hearing back from you as to what their response was.

I was walking by one of the Iron Mountain Secure Shredding bins at work one day several months ago and noticed that the lock wasn't actually locked. Being the security conscious individual that I am, I tried to latch the lock again, but the lock was so rusted that it wouldn't close as hard as I tried. I can't just leave it there like that so I call the number on the bin's label and there is an automated message that tells me that they're not taking local calls anymore and gave me a different number to try. I call that number and they ask me for my company ID number which I had no idea what it was. She informed me that without that ID number I couldn't submit a support request. I informed the lady that this bin contained sensitive personal and financial information and that the issue couldn't wait for some random company ID to be found. Fortunately, she gave in and created the support ticket for me saying that I should hear back from someone within four hours.

One week later, on Friday, Iron Mountain finally calls me back and says that they will come to replace the lock the following Monday before 5 PM. When the lock hadn't been replaced yet on Monday evening, I called Iron Mountain back up. Looking at their records, they showed that a new lock had been delivered, but they had no idea where and the signature was illegible. I work on a three-building campus with 14 floors between them and almost 3,000 people. If they can't tell me where the lock is, then there's no way for me to track it down. They said that they would investigate and call me back.

After not hearing back from them again for a couple of days, I called them back. The woman I spoke with had no real update on the investigation. She said that she would send another message "downstairs" and escalate to her supervisor. At this point it had been almost three weeks with sensitive documents sitting in a bin with a malfunctioning lock. The next day they called me back and said they were never able to track down who the new lock was left with so they would bring us a new one at no charge. Finally, after a total of 24 days with a unlocked Secure Shredding bin, Iron Mountain was able to replace the lock. Iron Mountain......FAIL.

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.

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

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

Agenda

• What is AJAX?
• AJAX and Web App Security
• AJAX and Test Automation
• Vulnerability Examples: XSS, CSRF, & JavaScript Hijacking
• AJAX Best Security Practices
• Demo
• Q&A

What is AJAX?

• Asynchronous JavaScript And XML
• AJAX allows for a new generation of more dynamic, more interactive, faster Web 2.0 applications
• AJAX leverages existing technologies, such as DHTML, CSS< DOM, JSON, and the (a)synchronous XMLHTTPRequest (XHR)
• Not just a set of technologies, but a new Web application development approach and methodology
• XHR allows for (a)synchronous server requests without the need for a full page reload
• XHR "downstream" payload can be
  • XML, JSON, HTML/JavaScript snippets, plain text, serialized data, basically pretty much anything...
• Responses often get further processed using JavaScript and result in dynamic web page content changes through DOM modifications

AJAX Code Example

xhr = new XMLHttprequest();
xhr.open("GET", AJAX_call?foo-bar, true);
xhr.onreadystatechange = processResponse;
xhr.send(null);
function processResponse() {
if (xhr.readyState == 4) {
if (request.status == 200) {
response = xhr.responseText;
...
}
}
}

XHR and the Same Origin Policy

• Same origin policy is a key browser security mechanism
  • To prevent any cross-domain data leakage, etc
  • With JavaScript it doesn't allow JavaScript from origin A to access content/data from origin B
  • Origin refers to the domain name, port, and protocol
• In the case of XHR, the same origin policy does not allow for any cross-domain XHR requests
  • Developers often don't like this at all!

Common Cross Domain Workarounds

Cross-domain access is often still implemented by various means, such as:

• Open / Application (server-based) proxies
• Flash & Java Applets (depending on crossdomain.xml)
  • Ex: FlashXMLHttpRequest by Julien Couvreur
• RESTful web service with JavaScript callback and JSON response
  • EX: JSONscriptRequest by Jason Levitt

AJAX Frameworks

• AJAX frameworks are often categorized as either "Client" or "Proxy/Server" framework
• "Proxy/Server" frameworks sometimes result in unintended method/functionality exposure
• Beware of any kind of "Debugging mode" (Ex: Direct Web Remoting (DWR) debug=true)
• Remember: Attackers can easily "fingerprint" AJAX frameworks
• Beware of JavaScript Hijacking
  • Don't use HTTP GET for "upstream"
  • Prefix "downstream" JavaScript with "while(1);"

AJAX and Web App Security

• AJAX potentially increases the attack surface
  • More "hidden" calls mean more potential security holes
• AJAX developers sometimes pay less attention to security, due to it's "hidden" nature
  • Basically the old mistake of security by obscurity
• AJAX developers sometimes tend to rely on client side validation
  • An approach that is just as flawed with or without AJAX
• Mash-up calls/functionality are often less secure by design
  • 3rd party APIs (Ex: feeds, blogs, search APIs, etc) are often designed with ease of use, not security in mind
  • Mash-ups often lack clear security boundaries (who validates, who filters, who encodes/decodes, etc)
  • Mash-ups often result in untrusted cross-domain access workarounds
• AJAX sometimes promotes dynamic code (JavaScript) execution of untrusted response data

AJAX / Web 2.0 and Test Automation

• Spidering is more complex than just processing ANCHOR HREF's; various events need to be simulated (Ex: mouseover, keydown, keyup, onclick, onfocus, onblur, etc)
• Timer events and dynamic DOM changes need to be observed
• Use of non-standard data formats for both requests and responses make injection and detection hard to automate
• Page changes after XHR requests can sometimes be delayed
• In short, you need to have browser like behavior (JavaScript engine, DOM & event management, etc)

Cross-Site Scripting (XSS)

• AJAX is changing the game a little bit since the script tag may already be there, just need to look for JSON or JavaScript snippets to inject yourself into

Cross-Site Request Forgery (CSRF)

• Want to send a token for AJAX requests as well

JavaScript Hijacking

• Attacker code (override Array constructor)
• Render the JavaScript on the wire useless to anyone who doesn't have access to the code itself
• The attacker cannot sanitize the JavaScript since they do not have access to the code

AJAX Best Security Practices

Pretty much all the usual Web app security best practices apply:

• Analyze and know your security boundaries and attack surfaces
• Beware of reliance on client-side security measures
• Assume the worst case scenario for all 3rd party interations
  • 3rd parties can inherently not be trusted!
• Be extremely careful when circumventing same origin policy
• Avoid/limit the use of dynamic code/eval()
• Beware of JavaScript Hijacking
• Implement anti-CSRF defenses

Why is AppSec so hard?

• AppSec changes rapidly (look at difference between 2004, 2007, and 2010 Top 10)
• Changing landscape
  • Increase skill and talen t pool of technically proficient individuals willing to break the law
  • Growing volume of financially valuable data online
  • Development of criminal markets (black markets) to facilitate conversion to money
• "Attackers now have effective skills, something to steal, and a place to sell it"

• Application Security is a complete one-sided game
• Need to become an enabler (not a barrier)
• Must inject application security earlier through Guidance, Education, and Tools
• Must understand the development and deployment process and integrate rather than mandate
• NIST study on cost to repair defects when found at different stages of software development (http://www.nist.gov/director/prog-ofc/report02-3.pdf)
• Solving the problem of the enterprise (Culture Change)
• Success factors
• Form a mission and strategy
• Develop policy (but not corporate "mandate")
• Gain executive buy-in (cost / benefit / risk)
• Understand the magnitude of problem (metrics)
• Asset inventory and vulnerability management
• Develop standards (what should I do and when?)
• Establish a formal program (strong leadership)
• Focus on education and training materials
• Develop in-house expertise, services and "COE"
• Continuous improvement, measurement, KPI
• Communicate!
• Drive a culture change (shared need, WIIFM)
• Communicate expectations with vendors
• Implement incentives (and penalties)
• Digitize after the process is solid (tools)
• AppSec program mission & structure
• AppSec program strategy
• Policy (guidance) -> Standards (Guidance) -> Training (Education) -> Metrics (tools) -> Security tools (tools) -> Inventory & tracking (tools) -> Monitor & Improve

Guidance

• "GE Application Security Working Group" (Talking to the businesses is critical!  Meet every 2 weeks.)
• Secure Coding Guidelines
• Vulnerability Remediation Guide
• Secure Deployment
• Quick Reference Card
• Contractual Language
• Desk Calendars
• Metrics: AppSec calendars helped increase visitors to key Guidance materials  (track hits to website docs when certain activities take place)

Education

• CBT1: Intro to AppSec at GE (60 min for any IT person) - why AppSec is important and what happens when you don't do it
• CBT2: GE Best Practices for Secure Coding (90 min)
• CBT3: Attack Profiles & Countermeasures (120 min for security people)
• Developer Awareness Assessment:
  • 100's of internally-developed questions
  • Randomized questions, timed completion
  • Vendors track their own resutls
  • Allows tailoring of training/awareness programs

Tools

• - COE AppSec assessment services
• Vendor framework & Metrics
• Compliance handbook
• Common objects repository
• GE Enterprise Application Security
• Scanning and Monitoring tools
• Automation is the way to go (but the tools are not quite there yet)

Metrics

• Measure Vendor AppSec Performance (Avg % Critical/High Vulnerabilities per Assessment vs % Assessments with Zero Critical/High Vulnerabilities)
• Is it making a difference (map avg of critical/high vulnerabilities per assessment)

Forming a Center of Excellence

• Combines the best available people, processes and tools
• Formal training & defined roles (Comprehensive training program for all auditors to ensure skills are kept current and that auditors can provide more than one type of service)
• COE Team structure (tools, research, operations, stakeholder management, queue management, application security auditors
• Application Assessment Types (black/grey box vs white box)
• Application assessment process (map of the workflow with "swim lanes" of who does each step)
• Measure number of vulnerabilities and severities
• Measure customer satisfaction (overall, ease of engagement, responsiveness)