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
Using Proxies to Secure Applications and More
I've been really surprised that for as long as I've been active with OWASP, I've never seen a proxy presentation. After all, they are hugely beneficial in doing web application penetration testing and they're really not that difficult to use. Take TamperData for example. It's just a firefox plugin, but it does header, cookie, get, and post manipulation just as well as WebScarab. Or Google Ratproxy, which works in the background while you browse around QA'ing your web site and gives you a nice actionable report when you're done. I decided it was time to educate my peers on the awesomeness of proxies.
This past Tuesday I presented to a crowd of about 35 people at the Austin OWASP Meeting. The title of my presentation was "Using Proxies to Secure Applications and More". Since so many people came up to me afterward telling me what a great presentation it was and how they learned something they can take back to the office, I decided (with a little insistance from Ernest) that it was worth putting up on SlideShare and posting to the Web Admin Blog.
The presentation starts off with a brief description of what a proxy is. Then, I talked about the different types of proxies. Then, the bulk of the presentation was just me giving examples and demonstrating the various proxies. I included anonymizing proxies, reverse proxies, and intercepting proxies. While my slides can't substitue for the actual demo, I did try to include in them what tool I used for the demo. If you have any specific questions, please let me know. All that said, here's the presentation.
Cryptography for Penetration Testers – OWASP AppSec NYC 2008
This presentation was on "Cryptography for Penetration Testers" and was by Chris Eng, the Senior Director of Security Research at VeraCode.
The Premise
How much do you really have to know about cryptography in order to detect and exploit crypto weaknesses in web apps.
Goals
- Learn basic techniques for identifying and analyzing cryptographic data
- Learn black-box heauristics for recorgnizing weak crypto implementation
- Apply techniques
The Crypto that Matters in 6 Short Slides
Types of Ciphers
- Block Ciphers: Operates on fixed-length groups of bits, called blocks. Block sizes vary depending on the algorithm. Several different modes of operation for encrypting messages longer than the basic block size. Example ciphers include DES, 3DES, Blowfish, AES
- Stream Ciphers: Operates on plaintext one bit at a time
Block Ciphers: Electronic Code Book (ECB) Mode
- Fixed-size blocks of plaintext are encrypted independently
- Each plaintext block is substituted with ciphertext block, like a codebook
- Weaknesses: Structure in plaintext is reflected in ciphertext. Ciphertext blocks can be modified without detection.
Bliock Ciphers: Cipher Block Chaining (CBC) Mode
- Each block of plaintext is XORed with the previous ciphertext block before being encrypted
- Change of message affects all following ciphertext blocks
- Initialization Vector (IV) is used to encrypt first block
Stream Ciphers
- Plaintext message is processed byte by byte (as a stream)
- Key scheduler algorithm generates a keystream using a key and an Initialization Vector (IV combined (XOR) with plaintext bit by bit
- Encrypt by XORing plaintext with the generated keystream
Common Crypto Mistakes
- Insecure cipher mode (usually ECB)
- Inappropriate key reuse
- Poor key selection
- Insufficient key length
- Insecure random number generation
- Proprietary or home-grown encryption algorithms (Don't do this ever!)
Analysis Techniques
Dealing with Gibberish Data
What do you do when you are pen testing a web application and you encounter data that is not easy to interpret?
- Cookies
- Hidden fields
- Query string parameters
- POST parameters
How random is it?
- Output of cryptographic algorithms should be evenly distributed, given a sufficiently large sample size.
- Tools such as ENT (http://www.fourmilab.ch/random) will calculate entropy per byte, chi-square distribution, arithmetic mean, serial correlation, etc
Observe Characteristics
Is the length a multiple of a common block size?
- Indicates that the application may be using a block cipher
Is the length the same as a known hash algorithm?
- For example, MD5 is usually represented as 32 hex characters
- May also indicate the presence of an HMAC
- Still may be worthwhile to hash various permutations of known data in case a simple unkeyed hash is being used
Stimulus, Response
Does the length of the token change based on the length of some value that you can supply?
For a block cipher, you can determine the block size by incrementing input one byte at a time and observing when the encrypted output length jumps by multiple bytes (ie, the block size)
How does the token change in response to user-supplied data?
- Figure out how changing different parts of the input affects the output
- Is more than one block affected by a single character change in the input?
Deeper Block Cipher Inspection
Are there any blocks of data that seem to repeat in the same token or over multiple tokens?
- Possibly ECB mode, this doesn't just happen by coincidence
EXAMPLE
Context: A public-facing web portal for a large ISP. Used an encrypted cookie to authenticate identity. A new cookie is issued on each request. Base64 decoded EE cookies. Divided by 8 and found 8 byte blocks. Noticed some repetition in the same position. The only variable blocks are the last two (possibly a "last accessed" timestamp or similar timeout mechanism). Register a new account with a username of 'c' x 32, the maximum length permitted, and observe the value of the EE cookie.
'c' x 32 is Perl notation for "cccccccccccccccccccccccccccccccc"
The token is longer, meaning the username is probably stored in the cookie. Still noticed repition in same position. Register another account with a username of 'c' x 16 and compare to the EE cookie generated in the previous step. Didn't see two identical blocks for 'c' x 16 and four identical blocks for 'c' x 32. Reason is padding. The username doesn't align perfectly with the block offset. Want to figure out what position in the cookie the usernaem is located. Additional user accounts were created with specific usernames in order to determine if there is any initial padding in the first block. Now you know where the username is in the ciphertext.
Able to successfully subvert the authentication mechanism without any knowledge of the algorithm or the key, based solely on observed patterns in the ciphertext. The root cause was the insecure cipher mode and the lack of a verification mechanism. ECB mode shoul dnot be used (use CBC instead).
EXAMPLE
Token values observed in URLs. Changed every time we logged on to the application. Never the same for any two sessions or any two users. Base64 decoded values for several different "stmt" tokens. Statement numbers were displayed in the browser. Looked for correlations between statement number and cipher-text. Conclusion: It looks like a stream cipher. Use XOR to calculate 10 bytes of the keystream based on the known plain-text (ie. the statement number). Now try the same things against one of the other collected tokens, such as the one called "Ctxt". Get ASCII text that allows you to infer what it would say. Expand it out more and more to get the keystream. Repeat over and over until you have enough of the key to figure out anything in the application.
Through this iterative process, we can obtain the entire keystream (or rather, a sufficient amount of the keystream to encrypt and decrypt all of the cipher-text we encounter). Can replace the statement number with another valid statement number and view the contents.
Able to subvert the encryption mechanism without any knowledge of the algorithm or the key based solely on observed patterns in the ciphertext. They were using RC4 with a unique key generated for each user session. Root cause of the vulnerability is the re-use of the keystream.
Practical Advanced Threat Modeling – OWASP AppSec NYC 2008
This presentation was by John Steven who is the Senior Director of Advanced Technology Consulting at Cigital, Inc.
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, and assets threats may compromise.
- Some leverage risk management practices. Estimate probability of attack. Weigh impact of successful attack.
Elements of a threat model
- Structural view
- Threat actors
- Assets
- Attack vectors
- Privilege/"trust"
Threat
- Capability: Access to 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 and determine "out of bounds" scenarios.
A Few Words on STRIDE
- A conceptual checklist backed by data flow diagrams
Attack Trees
- Aggregate attack possibilites
- Use OR, AND
- Allow for decoration (probability, cost, skills required, etc)
Threat Modeling as a Process
- Use threat modeling to identify where potential threats exist relative to the architecture, how threats escalate privilege, specify vectors of attack, identifies components and assets worth protecting.
Leading Up to Threat Modeling
- Identify threats
- Enumerate doomsday scenarios
- Document misuse/abuse
- Diagram structure, assets
- Annotate diagram with threats
- Enumerate attack vectors
- Iterate
Input: Goals, Doomsday Scenarios
Misuse/Abuse Cases (use case view and component view)
Inputs: Security Requirements (specified security features - "128 bit encryption", "software security != security software")
Anchor in Software Architecture
Consider where attacks occur:
- Top-down: enumerate business objects (sensitive data, privileged functionality)
- Bottom-Up: enumerate application
Output: Security Assessment & Test Design. Threat models drive assessments, Test design. Establish rules of engagement. Prioritize areas of interest. Manage a team in risk-based fashion. Establish a single tie between vulnerability and control.
Application Structure: No "One Size Fits All"
Application Structure: Topology - Coloration shows authorization by role. Arrows indicate resolution of principal/assertion propagation. Use structure to separate privilege.
Application Structure: Components - Component diagrams show critical choke points for security controls (input validation, authentication, output encoding).
Application Structure: Frameworks - Showing frameworks indicates where important service contracts exist "up" and "down".
Assets: Flow - Assets exist not only in rest, but also flow through the system. Use different types of flags to represent data flow of assets.
Use different colored arrows to represent each different attack vector.
Target Using Layered Attacks: Bootstrap later attacks with those that "deliver". Use one layer to exploit another (net, app). Combine attacks to reach desired target.
Take Homes
- Base threat model in software architecture
- When specific use (cases) and high-level architecture are defined: inventory roles, entitlements, if one doesn't exist and inventory assets, sensitive data, privileged components
- Enumerate initial attack vectors. Use common low hanging fruit.
- Elaborate more attacks. Find opportunities for privilege escalation. Layer attacks to target or "hop" to assets. Fill in gaps by "inventing" attacks.
- Use threat modeling to drive security testing
Lotus Notes/Domino Web Application Security – OWASP AppSec NYC 2008
This presentation was by Jian Hui Wang (girl) who is a security professional, but "a nobody in NYC". Talking about Lotus Notes/Domino web application architecture and security features, web application common development mistakes and fixes, and test methodology.
Lotus Notes/Domino History
Lotus Notes is client and Domino is the server. Supports multiple protocols with one interface (HTTP, LDAP, SMTP/POP/IMAP, file sharing). Strong on workflow application and collaborative application. Used by .gov, .edu, .com. Google search shows 66 million notes databases facing the internet. People use it because it's easy to develop and deploy a simple application, granular access control, good logging method, and it integrates well with e-mails.
Notes Databases
Notes databse is building block of Domino application (.nsf or .ntf). Notes Database is a container for data (document, message, web page), design elements (form, page, view, folder, navigator, agent, frameset, outline).
Two components in Domino server architecture. There is an HTTP Server and a Domino Engine (URL Parser, Command Handler, and Database).
Web Access Syntax
- http://host/data/base/NotesObject?Action&Arguments
- Database = Notes Database
- NotesObject = the web accessible design element
- Action = the action on NotesObject
- Arguments = the qualifiers for the action (optional)
Notes Database Access Control List (ACL)
- Define users and groups access privileges on the database
- Seven access levels (manager, designer, editor, author, reader, depositor, and no access)
- Eight access options for each level (create/delete documents, create/delete folders/views, create/delete agents, create/delete public documents)
- Anonymous and -Default-
- Maximum internet and password access: only works for name-password authentication but not for certificate authentication. A web user cannot get the access greater than the "Maximum" access even if the access explicitly given is higher
- Further restriction can be done by conjunction with reader field, author field, and access list of documents for granular read and write access control
Notes Web Authentication
- Anonymous user - who does not have Person documents in DOmino Directory (names.nsf)
- Authentication occurs if anonymous access is disabled on server configuration document and Notes objects
- Name-password authentication: user/pass are authenticated to Person document and internet password in Domino directory (names.nsf). Basic authentication and session-based authentication. Internet password lockout function (Notes 8 only)
- SSL client certificate authentication
Common Security Mistakes in Development
- Unauthorized Access: Anonymous access. Anonymous privilege is assigned to Default access level if there is no anonymous group explicitly set. Default access level is Designer and Maximum Internet and Password Access is Editor of most built-in templates. Forceful browsing. Solutions are to setup anonymous group and assign it "no access". Review the ACLs of all databases and confidential documents.
- Using Default Objects (Databases): Default databases are statrep.nsf, schema.nsf, reports.nsf, names.nsf, log.nsf, events.nsf, doladmin.nsf, dbdirman.nsf certsrv.nsf, certlog.nsf, admin4.nsf, ... Anonymous users should not be allowed to access these databases.
- Default Objects (view): $DefautlView?OpenView, $DefaultNav?OpenNav, $DefaultForm?OpenForm, help?OpenHelp, $about?OpenAbout, $searchform?searchdomain, $searchform?searchsite, $searchform?searchview, $Icon?OpenIcon, $first, $file. Solutions are to use the URL redirection and mapping on server document, customize the default pages, and apply the appropriate access control.
- SQL Injection: Places to process User Input (@Commands, WebQueryOpen, WebQuerySave, WebQueryClose, @URLQueryString, OpenAgent, RunAgent). Solutions is input validation in fields by formula or lotus scripts
- Cross Site Scripting: Most cross site scripting vulnerabilities are persistent. Solutions are to use input validaton or to HTMLencode.
- Session Management: By default uses basic authentication. Username and password are sent in clear-text in teh packet of every request. Solution is to configure the server document to use session-based authentication. Do not append sensitive data to Querystring.
- Information Leakage: Hard coding username and password. Solutions are to remove the sensitive information from the source code and log and customize the error message.
- Operating System Interaction: LotusScript has system commands such as Shell, OSLoadProgram, OSLoadLibrary, FileCopy, Open, Kill, Get, Input, Close. Solution is to hardcode the path and validate the filename input.
Testing security is challenging but it can be done:
- Lotus Notes Designer (Design Synopsis)
- Grep
- A good text editor
- Paros
References
- Secure Domino Application
- Lotus Security Handbook
Buildng and Stopping Next Generation XSS Worms – OWASP AppSec NYC 2008
I was originally planning on going upstairs for the SaaS Security presentation, but I had to come downstairs again to get my lunch and this topic seemed interesting, especially given the prevalence of cross site scripting in websites (see OWASP Top 10). The presentation was by Arshan Dabirsiaghi, the director of research at Aspect Security. He actually began by talking about Clickjacking and said that Jeremiah Grossman and RSnake gave up enough clues for him to figure out the exploit as far as Adobe flash goes and says that he'd rate the vulnerability a 7/10 in flash and an overall 10/10. Example non-weaponized exploit at http://i8jesus.com/stuff/clickjacking/test1.html using iframes and CSS. Suggested fix is to apply framebreakers to your page.
Is an XSS worm really a worm?
5 components of a worm:
- Reconnaissance - "[the worm] has to hunt out other network nodes to infect"
- Attack - "[components] used to launch an attack against an identified target system"
- Communication - "nodes in the network can talk to each other"
- Command - "nodes in the worm network can be issued operation commands"
- Intelligence - "the worm network needs to know the location of the nodes as well as characteristics about them"
Short answer: 3/5 - probably
How are XSS worms different from traditional?
- Infection model - Current model requires user interaction, worm strictly contained within web application, passive and localized, no Warhol worms (15 mins of fame).
- Payload capability - Perform any application function (money transfer, close account). XSSProxy/Attack API. Malware (yikes)
- Target shift - Internet worms can own everything both in front of and behind a firewall (island hopping).
- Penetration - Need to trick the user into spreading between sites using a 3rd party proxy.
Traits of Current XSS Worms
- Static payloads
- Passive infection strategy
- Staty on the same domain (don't say nduja)
- Uncontrolled growth
- No command and control
Current Incident Response Options
- Fix the vulnerability
- Manual purging - can only be done by experts and doesn't scale
- Database snapshot restore - effectively removes all worm data from tained columns, but forces loss of other application data
- Search & Destory - works now. Tricky in the future, but possible.
Next Gen XSS Worm Reconnaissance: A reconnaissance component will be added to the client side to find more web applications to infect. Nodes can use HTML5 Workers/Google Gears WorkerPool/<insert tomorrow's new RIA technology>. What about SOP? Old and busted: utilize 3rd party proxy (a la jikto ~2007). What attackers should be doing now: malware - no SOP! Next gen hotness: cross-site XHR, XDR, postMessage. Allows cross-site bidirectional communication. Servers must opt in, like Flash, so absolutely no security issues there (kidding)
Cross-site communication in HTML5
- postMessage(): Cross-domain communication based on strings. What do developers do with strings? JSON/eval() SiteA + JSON + SiteB = Shared Security
Staniford, Paxson & Weaver's Reconnaisance Techniques
- "hit list scanning"
- Permutation Scanning
- Topological Scanning (not without malware, cross-site XHR)
Next Gen XSS Worm Attack: An attack component will be added to the client side. New client side piece delivered with reconnaissance piece to attack other off-domain web apps. 85% of websites have XSS (how much is reflected vs stored?) How likely is it to fnd a stored XSS in another web app
Polymorphic Javascript: javascript can be highly mutated
Next Gen XSS Worm Communication: A communication component will never occur in a XSS worm. Can't communicate directly from victim browser to another victim browser. "centralization" in worms is just another word for weakness.
Next Gen XSS Worm Command: A command component will be added to the worm payload. Communicationw ith operator necessary for command-and-control structure, data delivery (new target info, soruce updates, etc)
- Attacker quietly posts signed payloads
- Victim creates token
- Victim queries Google form token using JSON
- Victim finds a signed result
- Executes the signed payload
Next Gen XSS Worm Intelligence: An intelligence component will be used after initial worm stages, it can't be trusted (adversaries can poison). XSS worms probably don't need this, they typically follow a pattern where the first 24 hours it reaches massive infections through epic growth rate. After that, gone and never seen again.
Ways to Prevent Next Gen XSS Worms
- search+destroying polymorphed javascript
- on demand exploit egress filters: popular sites need agile response techniques
- OWASP AntiSamy - safe rich input validation. Uses a positive security model for rich input validation. High assurance mechanism for stopping XSS (and phishing) attacks
- utilizing cross-domain workflows: letting the browser SOP protection prevent cookie disclosure + sensitive application information
- browser content restrictions: Doesn't make sense in a DOM. Requires parsers to honor end tag attributes.
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.
Building a Source Code Analysis Tool for Security Consultants – OWASP AppSec NYC 2008
This presentation was by Dinis Cruz, and OWASP board member and he works for Ounce Labs, a producer of a source code analysis tool, but he said he was not speaking on behalf of either. The presentation was entitled "Building a Tool for Security Consultants: A Story of a Customized Source Code Scanner". Everything was built on Open Source except for the scanning engine which is using Ounce.
About the Tool
Developed features while performing an assessment. Only developing features that make sense. Considered mature after 4 or 5 engagements with no feature additions necessary. Tools job should be to give you "pointers" that you can follow. Tool displays a chart of the flow from function to function. Uses different colors to represent data sources and data sinks. Can map just source to sink so you can easily figure out where tainted data arrives from and where it goes to. Able to look for "insecure patterns" instead of finding 20 XSS or 10 SQL injection pages. Able to display function calls ordered both ways: what functions are called by a function or functions that call a function. Added a scripting editing environment. Everything that is available via the GUI can be scripted.
There were no slides for this presentation and the whole thing was a demonstration of the tool and how it works, it's features, etc. I don't know a whole lot about source code scanning and will tell you that a good chunk of this presentation was over my head, but Dinis was very enthusiastic about the tool and made it sound like it's something totally awesome and very worth looking into. He says that the tool is not "nice" and not "easy to use", but once you get used to it, it is an extremely useful tool for source code analysis.
Tiger Team – AppSec Projects – OWASP AppSec NYC 2008
This presentation was by Chris Nickerson, founder of Lares Consulting, and the goal was to talk about the use of layered attacks.
General types of threats includes social engineering/human (corporate/personal manipulation, bogus e-mails, physical intrusion, media dropping, phone calls, conversation, role playing), electronic (application and business logic attacks, software vulnerability exploitation, ...), physical (break-in, theft, physical access, physical manipulation, violence), and malfunction/inherent (business logic flaws, software glitches, software coding holes/exploits, process breakdown, act of god/war/terrorism disruption, intended backdoors) and a red team test should cover them all.
Why red teaming?
How do you know you can put up a fight if you have never taken a punch?
Red teaming process: Information Gathering -> Vulnerability Analysis -> Target Selection -> Planning -> Executing the Attack -> Back to step 1
Process of Attack
- Information Gathering: Research methods and useful information (spend most time here)
- Vulnerability Analysis: Internal/external/hired/personal
- Target Selection: Internal/external/hired/personal
- Planning: Plan a, b, e, d, pie
- Executing the Attack: Getting what you need and getting out. Not getting greedy. Getting out cleanly.
Corporate Attack Approach
- External Direct: server/app attack
- External Indirect: client side/phishing/phone calls
- Internal Indirect: key/cd drops/propaganda/creating a spy
- Internal Direct: social/electronic/physical/blended
- Exotic Attacks: environment manipulation (pulling the fire alarm, etc to move people)
Information Gathering Tools
- Maltego: The best attacks from the best intel (gives a graphical view of how all of the information interacts)
- Metagoofil: Yer Dox on the net have Infos (Extracts information from internet documents)
- Clez.net (External Profiling)
- CentralOps.net (Network Profiling)
- Robtex (Server Profiling)
- Touchgraph (Show business relationships and links)
- ServerSniff (Get tons of webserver specific info and verification)
- Netcraft (usage info)
- DomainTools (Domain info)
- MySpace/Friendster/Twitter (know ya enemy)
Onsite Tools
- BootRoot/SysReQ
- Ophcrack Live
- Helix/Backtrack
- Core Impact
- FireWire PCMCIA Card + Winlockpwn = Unlock
- Switchblade + Hacksaw + U3 drive
- Elite Keylogger
- WRT + Metasploit = Cheap leave behind
Other Fun Toys Onsite
- FlexiSpy (installs image on cell phone to read SMS, listen to phone calls, etc)
- Pen cams
- USB cams
- Cell phone jammers
All of these different methods to test front/back/side doors don't rule out the low tech attacks. You could spend a million dollars to prevent someone from hacking the server and they could just walk in the front door and take it. A really good talk by a guy who really knows his stuff and the only talk I've seen so far at the conference that wasn't specifically about technical vulnerabilities.