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.
Recent Comments