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
OWASP Live CD: An open environment for Web Application Security
General Goals Going Forward
- Showcase great OWASP projects
- Provide the best, freely distributable application security tools/documents
- Ensure that the tools provided are easy to use as possible
- Continue to document how to use the tools and how the modules were created
- Align the tools with the OWASP Testing Guide v3 to provide maximum coverage
- Awesome training environment
330,081 total downloads as of 10/5/2009
~5,094 GB of bandwidth since launch (7/2008)
Most downloads in 1 month = 81,607 (3/2009)
Available Tools: 26 "Significant"
- Web Scarab
- Web Goat
- CAL9000
- JBroFuzz
- WSFuzzer
- Wapiti
- Burp Suite
- Paro
- Spike Proxy
- Rat Proxy
- w3af
- Grendel Scan
- Nikto
- nmap
- Zenmap
- sqlmap
- SQL Brute
- Metasploit
- ....
OWASP Documents
- Testing Guide v2 & v3
- CLASP
- Top 10 for 2007
- Top 10 for Java Enterprise Edition
- AppSec FAQ
- Books (CLASP, Top 10 2007, Top 10 + Testing + Legal, WebGoat and Web Scarab, Guide 2.0, Code Review)
- WASC Threat Classification
- OSTTMM
Where are we going?
- Project Tindy (Live CD installed to a virtual hard drive, persistence, VMware, VirtualBox, and Paralles)
- Project Aqua Dog (OWASP Live CD on a USB drive, VM install + VM engine + USB drive = mobile app sec platform, currently testing, Qemu is the current VM engine)
- Much easier URL - AppSecLive.org
- Community site around OWASP Live CD
- Online Tool DB (331+ tools)
- New release will be based on Ubuntu instead of SLAX
- Create .deb packages for every tool
- Create a repository for packages
- Add dependency info to packages
- Brings the 26,000+ existing packages to the Live CD
- More fun cool stuff like Wubi (install Ubuntu onto an existing windows desktop to be able to dual-boot without repartitioning windows)
Design Goals
- Easy for users to keep updated
- Easy for project lead to keep updated
- Easy to produce releases (every 6 months)
- Crank out new .debs when new tool releases
- Continually updating repository
- Focused on just application security - not general pen testing
- Both dynamic and static tools
- Developer tools also
OWASP Education Project
- Natural ties between these projects
- Already being used for training classes
- Need to coordinate efforts to make sure critical pieces aren't missing form the OWASP Live CD
- Training environment could be customized for a particular class thanks to the individual modules
- Student gets to take the environment home
- As more modules come online, even more potential for cross pollination
- Builder tools/docs only expand its reach
- Kiosk mode?
Crazy Pie in the Sky Idea
- .deb package + auto update + categories = CD profiles
- Allows someone to customize the OWASP Live CD to their needs
- Example Profiles:
- Whitebox testing
- Blackbox testing
- Static analysis
- Targe specific (Java, .Net)
What have you done for me lately?
- For Testers/QA testers
- Wide array of tools, preconfigured and ready to go
- Nice "jump kit" to keep in your laptop bag
- Great platform to test or learn the tools
- For App Sec Professionals
- Both dynamic and static tool coverage
- Ability to customize the job your on
- For Trainers
- Ready to go environment for students
- Ability to customize for the class
Get Involved
- Join the mailing list
- Post on hte AppSecLive.org forums
- Download an ISO or VM
- Complain or praise, suggest improvements
- Submit a bug to the Google Code site
- Create a deb package of a tool
- How I create the debs will be documented, command by command and I'll answer questions gladly
- Suggest missing tools, docs, or links
- Do a screencast of one of the tools being used on the OWASP Live CD
Learn More
- Google "OWASP Live CD"
- Download & Community Site (http://AppSecLive.org)
Everything is stored in /opt/owasp
The ESAPI Web Application Firewall
This presentation was by Arshan Dabirsiaghi and was about the OWASP ESAPI Web Application Firewall (WAF) project. My notes are below:
WAF Fallacies (at least in regards to OWASP ESAPI WAF)
- WAFs add attack surface
- WAFs can create culture problems
- WAFs can't fix business logic vulnerabilities
- WAFs are way too expensive
- WAFs complicate networks
Why fix in ESAPI WAF vs Fix in code?
- Changing in ESAPI WAF is just a text file
- Shorter gap between time discovered and WAF fix vs code fix
Advantages of WAF
- Performance - Only your rules are checked, plus state is already managed by the app server
- Capability - being closer to the app lets us do more
- Process - Rules are closer to application owner, shortening discovery-to-patch time, also fix-to-patch-removal time
Principle: Make common tasks easy, uncommon tasks possible
General virtual patching functionality is easy to understand
Ability to write custom script rules as well "bean-shell-rules"
Fixing Injection Flaws is easy
Can fix business logic flaws with the WAF (missing authentication, missing functional access control, missing data layer access control)
Can add "outbound" security as well
- Add anti-clickjacking header
- Set uniform content-type
- Add HttpOnly flag
- Add secure flag
- Detect outbound information
- Replace outbound information
Takes advantage of early failing to make rules as optimized as possible
Now we see the tool demonstrated with several different vulnerabilities in a real-world application (JForum):
- Cross-Site Scripting Flaw (JForum XSS flaw is unable to be fixed with a WAF because of dynamic URLs)
- Unchecked Redirect
- Add HttpOnly
- Add anti-clickjacking header
- Privilege escalation
3 Different WAF Modes
- Log
- Block
- Redirect
Latency with all of the rules turned on is about 5%. With selected rules is closer to 0%. Basically an order of n magnitude where n is the number of rules enabled. Comes out to milliseconds.
Defending Yourself: Integrating Real Time Defenses into Online Applications
This presentation was by Michael Coates, the AppSensor Project Lead. Michael works as a Senior Application Security Engineer at Aspect Security. AppSensor is a real time defense system with the goal being to protect an application by detecting who is bad and getting rid of them before they do bad things. My notes from this session are below:
Agenda
- AppSensor Project
- Malicious Attackers
- Application Worms
Detecting Attacks the Right Way
- Integration
- Detect INSIDE the application
- Understand business logic
- Effectiveness
- Minimal false positives
- Immediate response
- Effort
- Automatic detection
- No manual work required
Detection Outside the Application (WAF)
- Application context not available
- No concept of access violations
- Custom application + Generic Solution != success
- Ex: Changing the account ID in /viewAccount?id=1002
Inside the Application is Best
- Understand application & business context
- Integration with authentication & user store
How Does AppSensor Protect the App?
- Take many requests for an attacker to find a vulnerability
- Takes fewer requests by AppSensor to determine that the user is malicious
AppSensor is Faster than Attacker
- User identified as malicious and blocked before a vulnerability is found
Categories of Detection
- Request
- Authentication
- Access Control
- Session
- Input
- Encoding
- Command Injection
- File IO
- User Trend
- System Trend
Attack Detection: Real vs Cyber World
- Why do bank robbers get caught?
- Why don't hackers get caught?
Let's Change Things - Applications Should...
- Detect attacks
- Understand normal use vs suspicious use
- Instantly identify attackers
- Shutdown attackers in real time
- Modify application accessibility for defense
Detecting Malicious Users
- Many malicious attacks are obvious and not "user error"
- POST when expecting GET
- Tampering with headers
- Submissions of XSS attack
Detecting Malicious Users
- Bypassing client side input validation
- Transaction using functionality not visible to user role
- Multiple access control violations
- Change of user agent midsession
- Double encoded data
The Code
- Leverages ESAPI!
- 3 lines to setup AppSensor
- 2 lines per AppSensor detection point
Setting up AppSensor
- Configure response action object (log logout, account lock)
- Create AppSensorIntrusionDetector with response action object
- Set ESAPI intrusion detector
Defining Response Policies
- ESAPI.properties file
- Define
- Threshold count
- Interval of events
- Response action
- Per exception type or aggregate
2 Lines to Use AppSensor
- Check for "maliciousness"
- Create new AppSensorException
Understanding the Intrusion Exception
new AppSensorIntrusion Exception(
- request.getServletPath(),
- "ACE1",
- "User Message",
- "Direct object tampering with ..."
);
AppSensor vs Scanners
- Tools attempt 10,000s of generic attacks
- AppSensor stops automated scans nearly instantly
AppSensor vs Human Attackers
- Very difficult for attacker
- Requires advanced obfuscation for each attack
- Multiple probes == detection
Application Worms on the Rise
- Twitter Worm
- MySpace Samy WOrm
- Huge damages for site
- Remediation
- Cleanup
- Bad PR
- Infected Users
- Leverage XSS and CSRF
Detecting/Preventing an Application Worm
- Can you find/fix all XSS?
- Pattern matching easily foiled
- Block the common factor!
- Worms use XSS and CSRF for propagation
- 1000% usage increase -> problem
- Our example: updateProfile, updateStatus, updateName
Case Study: Samy
- MySpace Application Worm
- XSS worm embedded in User Profile
- Exponential Growth of Samy's friends
Samy vs AppSensor
- AppSensor detects uptick in addFriend usage
- Compares against trended info
- Automatic response initiated
- Alert admin +200% add friend usage
- Alerts admin 2nd time +500% add friend usage
- Automatically shuts down add friend feature
- Result
- Worm contained
- Add friend temporarily disabled
- Site stays up
Benefits of Trend Monitoring
- Detection of
- Application worms
- Scripted attacks/probing
- CSRF attacks
- Alerting of excessive activity
- Selective feature shutdown for overall stability
AppSensor in Action
- Demo social networking app
- Defended with AppSensor trend monitoring
What's Under the Hood?
- REST communication between AppSensor & App
- Support Response Actions (warn user, logout user, disable user, etc)
AppSensor Brain
- Drools - Rule Based System
- Support for complex rule sets - much more than just counting feature usage
- Evaluates objects in Drools memory
The Exploit
- XSS infects victim's "Status" with worm
- CSRF adds victim as friend of Charlie
Defend with AppSensor
- AppSensor Policy
- Notify admin if events > 5
- Disable service if events > 10
- AppSensor notices anomaly - alerts admin
- After 10 events AppSensor disables just that feature of the site
- Users protected, worm contained, site stays up
Trend Monitoring Benefits
- Auto detection of attacks
- ...
Development Issues within AJAX Applications: How to Divert Threats
This presentation was by Lars Ewe, CTO of Cenzic on AJAX applications and trying to explore the different implications of running AJAX in your environment. My notes are below:
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
Software Assurance Maturity Model (SAMM)
This presentation on the OWASP Software Assurance Maturity Model (SAMM) was by Pravir Chandra, the project lead. I was actually really excited in seeing this topic on the schedule as SAMM is something that I've been toying with for my organization for a while. It's actually a very simple and intuitive approach to how to assess where your organization is at as far as software maturity, where you want to get to, and how to get there. My notes on this presentation are below:
By the end of the presentation should be able to....
- Evaluate an organizations existing software security practices
- Build a balanced software security assurance program in well-defined iterations
- Demonstrate concrete improvements to a security assessment program
- Define and measure security-related activities throughout the organization
Lessons Learned
- Microsoft SDL
- Heavyweight, good for large ISVs
- Touchpoints
- High-level, not enough details to execute against
- CLASP
- Large collection of activities, but no priority ordering
- ALL: Good for experts to use as a guide, but hard for non-security folkds to use off the shelf
Drivers for a Maturity Model
- An organization's behavior changes slowly over time
- Changes must be iterative while working toward long-term goals
- There is no single recipe that works for all organizations
- A solution must enable risk-based choices tailored to the organization
- Guidance related to security activities must be prescriptive
- A solution must provide enough details for non-security-people
- Overall, must be simple, well-defined, and measurable
Therefore, a viable model must...
- Define building blocks for an assurance program
- Delineate all functions within an organization that could be improved over time
- Define how building blocks should be combined
- Make creating change in iterations a no-brainer
SAMM Business Functions (4 in total)
- Start with the core activities tied to any organization performing software development
- Named generically, but should resonate with any developer or manager
- Governance, Construction, Verification, Deployment
SAMM Security Practices (12 in total)
- From each of the Business Functions, 3 Security Practices are defined
- The Security Practices cover all areas relevant to software security assurance
- Each one is a 'silo' for improvement
- Governance: Strategy & Metrics, Education & Guidance, Policy & Compliance
- Construction: Threat Assessment, Security Requirements, Secure Architecture
- Verification: Design Review, Code Review, Security Testing
- Deployment: Vulnerability Management, Environment Hardening, Operational Enablement
What is "software"?
- Lots of different aspects of what software is
- Could be a tarball of source code, UML and specifications, or a server running the code
Under each Security Practice
- Three successive Objectives under each Practice define how it can be improved over time
- Level 1, Level 2, and Level 3
- "Going from crawling to walking to running"
- 72 different actives all about the size of a bread box
Per Level, SAMM defines...
- Objectives
- Activites
- Results
- Success Metrics (2-4 metrics for each objective)
- Costs (training, content, license, or buildout)
- Personnel (overhead on different roles because operating at this level)
Conducting Assessments
- SAMM includes assessment worksheets for each Security Practice
Assessment Process
- Supports both lightweight and detailed assessments
- Organizations may fall in between levels (+)
Creating Scorecards
- Gap Analysis
- Capturing scores from detailed assessments versus expected performance levels
- Demonstrating Improvement
- Capturing scores from before and after an iteration of assurance program buld-out
- Ongoing Measurement
- Capturing scores over consistent tiem frames for an assurance program that is already in place
Roadmap Templates
- To make the "building blocks" usable, SAMM defines Roadmaps templates for typical kinds of organizations
- Independent SW Vendors
- Online Service Providers
- Financial Services Organizations
- Government Organizations
- Organization types chose because
- They represent common use-cases
- Each organization has variations in typical software-induced risk
- Optimal creation of an assurance program is different for each
Expert Contributions
- Build based on collected experiences with 100's of organizations
- Including security experts, developers, architects, development managers, IT managers
Industry Support
- Several case studies already
- Several more case studies underway
The OpenSAMM Project
- http://www.opensamm.org
- Dedicated to defining, improving, and testing the SAMM framework
- Always vendor-neutral, but lots of industry participation
- Targeting new releases every ~18 months
- Change management process
Future Plans
- Mappings to existing standards and regulations
- Additional roadmaps where need is identified
- Additional case studies
Enterprise Application Security – GE’s Approach to Solving Root Cause
The first presentation of the day that I went to was by GE's Darren Challey and was about GE's application security program and how he took a holistic approach to securing the enterprise. My notes on this presentation are below:
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)