OWASP recently posted videos of all talks from the OWASP AppSec USA conference held in Minneapolis in September 2011.
You can find my talk on an approach for “simplifying threat modeling” here. Grab my slides here.
Check it out and let me know what you think. Would love to hear from you and your thoughts on where threat modeling is headed in our industry.
Can attackers control URL redirection functionality exposed by your application?
Unvalidated Redirects and Forwards is #10 on the 2010 OWASP Top Ten 10 List. Sites that are vulnerable often expose a servlet or server-side script that constructs the URL being transferred to using data that is received from the client (i.e., something that can be controlled by an attacker). A lot of sites simply accept a URL as input to the redirection script, and that’s what gets them into trouble.
Here are a few typical questions from my “assessment runbook” that I ask for an app that accepts and parses XML data that can be controlled by an attacker (think file uploads, web services, stored XML content made up of inputs from an external user, etc.):
(1) Is there a check to enforce a maximum number of bytes that is read from the data stream that consumes the data?
(2) Is there a check to ensure the markup is valid XML?
(3) Is there a check to ensure the content of the XML message is part of the application’s protocol and matches expected data types and formats?
I’ve intentionally left out two questions that are the focus of this post (entity expansion) and the next post (external entities). It turns out that you can implement checks to cover (1), (2), and (3) and still be vulnerable to a denial of service scenario caused by insecure entity expansion due to parser weaknesses. In fact, most parsers that I’ve come across seems to be vulnerable to entity expansion attacks by default. Xerces is no exception. It’s a widespread issue because developers must explicitly configure the XML parser being used to mitigate the vulnerability; a step that often isn’t included in company security standards.
I recently found a SQL injection vulnerability in a J2EE app where a request parameter is used to construct a dynamic JDBC query via string concatenation. When I discussed the issue with the developer, he became confused and said “Wait, I’m validating this field against a white list like you said a few weeks ago, how could this possibly be?”. So we reviewed the validation check. Turns out a regex was being applied, but it was flawed: it wasn’t anchored from beginning to end. I’ve seen this happen a few times now so I figured I’d write about it.
Gary McGraw discusses prescriptive vs. descriptive models, and why/how BSIMM helps model the reality of software security initiatives in our industry.
In Cigital’s latest newsletter, I explain a few tips for gaining assurance that Fortify SCA is “seeing” code (specifically private or confidential data) the way you think it should be.
Static analysis tools like Fortify SCA are powerful in how they can quickly and consistently apply rules to identify insecure coding patterns (i.e., patterns that reflect or lead to weaknesses in code). Sometimes, though, the default rulepacks shipped with a tool may leave gaps in how it covers your code, particularly if your application is built with in-house frameworks, new third party libraries, old third party libraries, or less well known libraries. Check with the tool vendor’s documentation to find out exactly what rules you’re getting.
OWASP has published a very well written XSS cheat sheet.
If you google “cross-site scripting”, most of what you’ll find is a simplistic view of the problem and why XSS is so bad. Unfortunately, articles that only point out problems don’t really offer guidance for the guys writing code. Our industry needs better, more proactive guidance about how to create secure designs and write secure code. The XSS cheat sheet fits the bill. By following positive advice, DEV has a better chance at preventing entire swarms of problems, rather than attempting to fix every individual instance and corner case.
My favorite part of the article is the section on why you can’t simply do HTML output escaping to fix *all* XSS issues. In my experience, this is what most people fail to get.
In the January/February 2009 issue of IEEE S&P, Schneider and Birman talk about “trust attacks” in a good article discussing IT Monoculture risk. They write:
As a consultant who reviews code a lot, this statement immediately got me thinking about trust at the code-level. Trust issues are fun to think about — not only because there are bookoos of trust-related issues in today’s apps (particularly mashups) but also because they are difficult to mitigate through good defensive design. As a software design enthusiast, I believe we can apply the concept of trust attacks as described above to low-level module design (think the Class keyword in Java or class keyword is C++) by changing one word in the second sentence:
A lot has been said about what companies *could do* to build secure software. Ever wonder what companies *really do*? Now you can find out — the Building Security In Maturity Model (BSIMM) recently went public. Cigital, along with Fortify, conducted the study by interviewing leaders of software security initiatives to gather facts about what activities they carry out to meet software security goals.
This is a big, big deal for our industry. It’s all about being proactive, thinking about software security from day 1, and developing a strategy for going from point A to point B to point C. We finally have good data from serious initiatives out there that shows what has worked over the years and what hasn’t. Companies included in the study that can be named: Adobe, The Depository Trust and Clearing Corporation (DTCC), EMC, Google, Microsoft, QUALCOMM, and Wells Fargo.
The framework that’s presented in the study is easy to read and understand. I invite you to ponder about how your organization sizes up against the nine companies included in this study. If you’re not doing the nine things everybody does, you may want to ask why.
Two other articles about BSIMM to check out:
What do you think?
This is the first post in a series covering tactics for implementing input and output chokepoints in J2EE. My goal is to describe different techniques in separate posts and then summarize the tradeoffs (advantages, disadvantages, and corner cases) involved in putting them in place in a final post. In this first post, I’ll show you how to setup a J2EE servlet filter to perform HTML escaping on multiple servlet-related input sources. A lot of DEV teams out there do this in an attempt to prevent cross-site scripting vulnerabilities.