When my bank sent me a message pitching the conveniences of mobile & text banking, I didn’t opt in. Here’s an example of why: WJS reports “Citi Discloses Security Flaw in Its iPhone App.”
Citi claims security tests were conducted before and after the application release, but a recent “routine security review” spotted the flaw. The app was released in March 2009.
The vulnerability as described to the public appears to be a classic client-side trust issue that should have been easily discovered during a design review, code review, or penetration test. Citi contracted with a vendor to build the application, and it’s not clear whether the vendor or Citi introduced the flaw or whether it manifested during the integration of the vendor’s code with Citi’s code. Nevertheless, it’s a classic case of a design flaw sneaking through the entire SDLC and making it’s way into production affecting 150K+ customers and Citi’s brand.
Take away: catch and correct these types of flaws early in the SDLC by creating abuse cases and conducting architectural risk analysis.
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.
Continue Reading »
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.
Continue Reading »
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.
Continue Reading »
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:
Networked systems admit the possibility of trust attacks. In them, one computer satisfies a request from another because it trusts the source of the request, but in fact the source has already been compromised by an attacker [1].
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:
[...] one module satisfies a request from another because it trusts the source of the request, but in fact the source has already been compromised by an attacker.
Continue Reading »
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.
Continue Reading »
Update: Read about Gary McGraw’s take on Top N lists.
MITRE and SANS released the CWE/SANS Top 25 Most Dangerous Programming Errors list today. This list is an attempt at being more code-centric than other similar lists, such as the OWASP Top 10.
Although these lists cover what is often considered “low-hanging” fruit vulnerabilities or the coding errors that lead to them, they are great conversation starters and act as a stepping-stone for organizations just getting started in improving the way they find and fix common issues. We cannot afford, however, to not think about, pay attention to, or invest resources in finding all the other kinds of vulnerabilities that don’t show up on these lists.