Secure Web

Reefer Madness or Session ID Pollution, you choose

So you can grok the title of this post, anyone remember that awful '50s documentary that tried to scare everyone into not smoking marijana? Reefer Madness! What I am getting at is this: back in early 2004 I reported a vulnerability in PHP and got ridiculed by a developer for even pointing out the issue. He said in a round about way that I was suffering from the Reefer Madness Syndrome, that is to say, that I was hyping an essentially benign issue and trying to scare everybody with it. Well, I was really busy back then and didn't feel like debating the issue so I let it drop. The flaw was later silently fixed in some 5 dot dot something release in 2006.

But still, the idea interests me because I am curious the degree to which its a localized problem in older versions of PHP or a broader issue. The root cause of what I called Session ID Pollution during my talk at OWASP Appsec 2007 is a failure to sanitize the session id of a web application, allowing an attacker to append some junk to it which gets passed around by the web application. The appended junk is essentially ignored by the application itself, but as its passed between content brokers like proxies or content portals, it has the potential to do harm.  One specific example that I cited was appending <script>foo<script> to a valid session ID token and as that information is passed around, it can become cached or directly execute within a web portal when a user follows a link. Wrapping your head around this issue is really a two part process:

1. A web application allows a user to append arbitrary data to a Session ID token, and this data is not filtered or sanitized, but is transmitted as if it were part of the valid session id, like so:

SessionID=24378923479<script>malicious code</script>

The script gets more or less tacked on to the end of the session id and it doesn't affect the session or disrupt it, but its not stripped away or sanitized either, so it effectively becomes part of the session ID as its passed around, its just not a part of the session Id that the application cares about. This is the benign aspect of the vulnerability. But don't read benign to literally, because in the same way a person or animal can carry a disease, manifest no outward symptoms, but spread it around just like the monkey in the movie Outbreak with Dustin Hoffman.

2. The session ID that has been polluted is then passed around various applications, and thus it has the potential to be executable as one of these other applications parse the URI in question when presenting data to the user.  This is the part of the movie where the monkey  gives  the disease to everybody in the village and the UN has to drop a fuel  air bomb on it. The original application hands off its polluted session ID to a content broker, content portal, proxy, or web logging server.  Thus a user follows a link to a web application, the application does not filter the session ID and the malicious content contained in the link is preserved. In fact, the application goes so far as to assign the user a new session ID but preserves the data appended onto the session id in the original request. But when the user receives the response from the application, the malicious code executes in their browser as the polluted session ID is parsed by the proxy sitting between the user and the application.

Ok... so  what? (The "so what" test is venerable tradition of college debaters. Subjecting an argument to the rigors of the "'So What' test" requires asking does anybody give a damn.) Evidently, when I reported this issue back in 2004 it didn't pass the so what test of the developer to whom I reported it. Objections to the significance of so called "Session ID Pollution" were as follows:

1. Its not the fault of the application, or a bug in the application, its the Proxy's problem. I.E. The content portal, proxy, or broker should filter hazardous characters from input not pass potentially harmful data off to the user.

2. The issue is not new, its just lame old boring cross-site scripting.

3.  You're a lamer for bringing this issue to my inbox.

My rejoinder:  Applications and servers should ensure that the session ID doesn't contain harmful or dangerous characters and that it has not been modified. Failure to do so means increased risk that some other application will recieve dangerous input from the application. One simple example is webtrends-like software that logs browsed urls in and does so in an insecure fashion. When someone views the log the script executes in their browser. Yes its a problem of the logging software, but the application, which transmits the information unsanitized, is being abused by the attacker to get their exploit into proper attack vector where it can have its impact. Now we shouldnt' go about blunting our scissors because its unsafe to run with them, but in the case of sanitizing the session ID,  there really is no good reason for someone to be able to append arbitrary data onto it, and failure to check and prevent its modification is, I suggest, a vulnerability.

At OWASP Appsec 2007 I called this vulnerability "Session ID Pollution." Because I'm interested in the topic and have been for a few years, you will be hearing more about this from me as I continue to research the issue. Consequently, at the conference where I recently presented on this topic I was challenged that the problem is only a PHP problem, and for that, at the present, I have no answer. More to follow.

-Tom S.

As Holiday Shopping approaches, Web security woes continue

With the release of our Q3 Trends report on Web application security on Nov 12th, we continue to see a rise in Application vulnerabilities which formed 68% of all published vulnerabilities in the quarter. But, the main issue here is not the rise in application vulnerabilities. Rather, the problem is with inaction or lack of sufficient action by companies and government agencies in doing something about securing their Web applications. Jupiter Research is predicting 126 million shoppers will spend over $39 billion this holiday season. That's a lot of shoppers putting their personal information in millions of Web sites that sit on top of applications - most of them vulnerable to hackers.

In looking at the data from our services unit as well as many published sources, we estimate that about 90% of all Web applications out there contain some vulnerabilities. While 70% of the applications tested by Cenzic's managed service unit were found to be vulnerable, most of these companies  are in North America and are sophisticated users who understand the importance of securing their Web applications. If we look at the entire population of Web applications across the world, there is little awareness on secure coding and application vulnerabilities.

To give credit where it's due, there are a number of leading edge companies in North America like Google, Oracle, Microsoft, and many large financial services companies and a few government agencies who are making major investments in testing their applications and fixing vulnerabilities. But, these form a small percentage of all the companies that are doing e-commerce transactions or collecting customer information online.

As hackers keep getting smarter, Web sites keep getting hacked without companies realizing the intrusion, and consumers  keep getting frustrated with their identities and other personal information being stolen. So, what can we do? Customer need to be more alert and look for the right companies to do business with and ask the right questions around Web security. Companies and government agencies need to do a lot more to secure their Web applications and start the process immediately. We have a long way to go so the quicker we can start the better. And let's hope this Christmas season doesn't turn into Halloween when it comes to holiday shopping!

- Mandeep Khera, Cenzic Inc.