Gary McGraw discusses prescriptive vs. descriptive models, and why/how BSIMM helps model the reality of software security initiatives in our industry.
good code
It’s time to start being less reactive and more proactive
Teaching Fortify SCA About Confidential Data
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 XSS cheat sheet
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.
Applying Basic Trust Concepts to Software Module Design
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.
Building Security In Maturity Model (BSIMM)
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:
- Software Security Top 10 Surprises (December 15, 2008)
- A Software Security Framework: Working Towards a Realistic Maturity Model (October 15, 2008)
What do you think?
IO Chokepoints: J2EE Filters
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.
CWE/SANS Top 25 released today
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.
Consistency is important
With so many APIs and frameworks out there, there are many different ways to accomplish the same task. The problem is that each way (or method) usually exhibits different behavior in the face of maliciousness. The challenge for us is to (1) find bad behavior in the APIs/frameworks we use, (2) apply fixes consistently, and (3) remember all of the ways things can go wrong. (1) is difficult but doable, (2) is more challenging, and (3) is arguably impossible for a person to do alone. The fact that APIs change frequently, even if changed for the better, often exacerbates the problem because it’s costly to go back and consistently make changes across existing applications.
Mixing GET and POST request data
Are designs that mix GET and POST requests inherently flawed?
It’s common for J2EE developers to create designs that pass both GET and POST requests through a centralized processing pipe, as in the controller method below:
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class MyServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response) {
controller(request, response);
}
public void doPost(HttpServletRequest request, HttpServletResponse response) {
controller(request, response);
}
private void controller(HttpServletRequest request, HttpServletResponse response) {
// process the request
}
}