I wrote an article titled “Tips for secure session management” a few days ago. Today I was testing an application when I ran into a vulnerability that could compromise sessions. This had to do with the programmers using the session-id for other purposes.
The web application allows users to upload files. There were a few problems that came up.
- The application stores the files under the web root. This means that the files can be accessed by any one that knows the location of the files. The severity of this problem depends on the contents of the files.
- Directory browsing is allowed for this directory and the default page is not present in the directory. So all the files in this directory will be visible to any one browsing to this directory.
- The biggest problem was that the file names had been prefixed with the session-id. This was done programmatically to ensure that the file names were unique. But what happened was that they exposed the session-ids of all the users that uploaded files through the application. This opened all these users to session hijacking attacks.
An attacker could go to the directory, select the most recent session-ids and send them back to the server. The server would think that this user was the user that the session belonged to and allow access. The attacker can then take over the session and access data or perform unauthorized actions.
It is important that programmers think through the implications of their decisions. One of the requirements for session-ids is that they need to be random enough and long enough that they cannot be predicted by an attacker. But if the application exposes session-ids belonging to other users, those protections are useless.
This is similar to the Seinfeld episode where Sienfeld’s apartment is burglarized. Seinfeld says to Kramer (who left the door open) that he invested his money on a very good lock. “The lock has only one design deficiency. The door has to be closed for it to work”.