12Nov/090
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
25Sep/080
Security in Agile Development – OWASP AppSec NYC 2008
This presentation, entitled "Security in Agile Development: Breaking the Waterfall Mindset of the Security Industry" was by Dave Wichers, member of the OWASP board and cofounder and COO of Aspect Security.
Manifesto for Agile Software Development
Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.
Agile Traits
- Agile practices test driven development, pair programming, and doing the simplest thing.
- Planning Sprint (Sprint 0) - define user stories
- Develop in sprints and focus on what the customer wants first in short iterative development cycles
Assurance is the Goal
- "Assurance is the level of confidence that software functions as intended and is free of vulnerabilities, either intentionally or unintentionally designed or inserted as part of the software" - DOD
- Can agile software development methods generate assurance?
- "test-driven development places (functional) assurance squarely at the heart of development" - Johan Peters
Waterfall Security is "Breadth First"
- Build assurance layer-by-layer
- Challenges are problem space is very large, difficult to prioritize, ...
Agile vs Security
- Where to insert security activities?
Security in Agile (nice chart here)
- Add Threat Modeling and Stakeholder Security Stories at the beginning between the Story FInding/Initial Estimation
- Do periodic security sprints (if needed) between writing the story and scenario and implementing functionality and acceptance tests
- Do some independent expert testing and security architecture review support in the quality assurance phase
- Add Application Security Assurance Review between system testing and release phases
Key Agile Security Enablers
- Standard Security Controls: See the OWASP Enterprise Security API (ESAPI) Project
- Secure Coding Standards: How to properly use your standard security controls. How to avoid common security flaws. Automated code analysis.
- Developer Security Training: How to use your standard controls and avoid common flaws
- Support from Security Expers: Even with training and standard controls, security is hard. Access to security experts and independent testing/analysis is key. Ideally, a security expert would be on the team (but usually not possible).
Planning Sprint (Sprint 0)
- Identify StakeholdersL Ask them what thier most important security concerns are. Work with them on the basic security controls required based on system purpose, environment, existence of such mechanisms, etc
- Confidentiality: Who is allowed to access what data and how? How important is protecting this data? Regulatory requirements?
- Integrity: What data must be protected and to what degree?
- Availability: How important is system availability? Can we define an SLA?
Planning Sprint: Capture Risks in Stakeholder Security StoriesAssurance is the level of confidence
- As a User...I want to be the only one who can access my account so that I can keep my information private.
- As a User...I want my personal information encrypted in storage and transit so that it doesn't get stolen by attackers.
- As a Manager...I want to be the only one who can edit Employee salaries so that I can prevent fraud.
- As a Business Owner...I want all security critical actions logged, so that attacks can be noticed and diagnosed.
Building Assurance "Depth First"
- Identify most important security concerns and their required security mechanisms
- Within sprints, or in periodic security sprints develop test methods for them and their use, configure/implement/analyze these security mechanisms, and run the tests
Implement Stakeholder Security Stories
- Security stories are implemented just like other stories. Test-driven development (unit test cases come before the code). Continuous reviews and inspection (pair programming/constant information reviews)
Test Cases for Security Controls
- Security "requirements" are defined by developing test cases. Unit tests can test both positive (functional) and negative (not broken) aspects of security mechanisms. Tests are repeatable, providing full regression testing. But not true penetration testing or analysis.
- Real experience with test driven development. The OWASP Enterprise Security API.
- Results in significant increase in assurance
Test Cases for Security Stories
- Functional test cases. Typical unit testing by developers. Verify presence and proper function of security control. May include simple tests with a browser.
- Security test cases. Check for best practices. Test for common pitfalls. Hopefully, most come with your standard security controls.
- Test cases provide strong assurance evidence
- Independent security testing. Verifies that functional and security tests were performed. Provides additional specialized security testing expertise.
Periodic Security Sprints
- As necessary, build/integrate related security controls. Implemente highest priority related security controls first. Leveraging your standard security components is key. Building significant new security controls is hard. Security sprints may even be completely avoided if sufficient standard components are available.
- Examples: Authentication, sessions, authorization, validation, canonicalization, encoding, error handling, logging, intrusion detection
Perform Agile Security Reviews
- Security reviews: verify all are in place and complete. Threat model, security stories, security controls, test cases, test results. Notice: Most are standard agile artifacts, not just add-on security deliverables.
- Application code review and penetration testing. Added for critical applications to increase assurance. Manual (tool supported), automated, or both. Within security sprints and/or predeployment testing.
Example: Agile Access Control
- With standard access control components, just make sure "isAuthorized() is called where needed both in presentation layer and business logic. Stay focused on implementing the functionality
- Define user stories aroudn who can do what. Configure your policy for what is most important first. Define and restrict what normal users can do. Policy can be both declarative and programmatic.
- How do you test proper implementation? Develop policy specific test cases to make sure policy is enforced properly.
Security in Agile Summary
- Agile can generate assurance well, possibly better
- Approach is depth-first, not breadth-first
- Getting the right stakeholder security stories is key
- In traditional security, assurance comes primarily from expert security reviews at successive stages of development. In agile security, assurance comes from managing the key risks to the security stakeholders.