full-disclosure - Session data pollution vulnerabilities in web applications

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu Jan 12 16:50:59 2006
From: frank at knobbe.us (Frank Knobbe)
Subject: Session data pollution vulnerabilities in
	web applications

On Thu, 2006-01-12 at 11:33 +0000, Alla Bezroutchko wrote:
> As for fixing those bugs, I suppose one approach is having a separate
> session variable for each function in the application. For example new
> user registration will keep its stuff in $_SESSION["register"]["login"]
> and authentication will keep its stuff in $_SESSION["auth"]["login"]

These type of bugs stem from bad program design. (BTW: I wouldn't call
it session data pollution... your not polluting anything).

The proposed fix is -- besides being only specific to this example --
equally flawed. The underlying issue is that you trust user supplied
data. When a user supplies a user name for login purposes, you should
only use that input to perform a search in your database. If a match has
been found, take a *trusted* value from your database, for example an
index ID, and carry that in the session object to identify the user.

In other words, don't accept any user input (even after proper input
validation) and carry it as trusted data in your session object. Don't
base further decisions on this data. Since it is user supplied it can
not be trusted.

Your example is further flawed in that it allows the change of a
password without being properly authenticated. Just having a valid
'login' session object present doesn't indicate that the user is
authenticated. I really, really hope this was just an example you made
up, and not something you actually saw being used. If so, go back to
that web site with a clue-by-four and give it a few whacks.

But you are right that these type of issues are common. While we're
educating developers on secure program design, I think we need to do a
better job at teaching some paranoia too. Every programmer should have a
healthy dose of paranoia and distrust when writing applications :)

Cheers,
Frank

-- 
It is said that the Internet is a public utility. As such, it is best
compared to a sewer. A big, fat pipe with a bunch of crap sloshing
against your ports.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060112/f17904ef/attachment.bin