[Owasp-alabama] using SESSION Vars to store sensitive data...

owasp-alabama at lists.owasp.org owasp-alabama at lists.owasp.org
Tue Jun 21 16:07:45 EDT 2011

Hash: SHA1

> Im using ADLDAP.php, seems to be fairly solid... ---> http://adldap.sourceforge.net/

Interesting. Stepping aside from the questions and problems below would the local OWASP chapter in Birmingham be interested in doing a source code review of this product as a group project?

> i can authenticate fine from any hosted OS, all is great there...
> here's the problem..
> i often have to go back to the ldap server during the course of setup to get different values, to do this i need to re-authenticate with the LDAP server on every request... so this means the user could have to enter the credentials multiple times... that sucks...
> the only solution is to store the user / pass the first time they enter it somewhere, so i can grab it and resend to LDAP when i need it...  
> so where to store it?

I would also add in 'where to store it , and how to store it'. 
I would store it in memory and store it securely. 
Securely meaning there is a lifespan of the information , it is encrypted and the key for encryption is protected... 

> - i dont want to store them anywhere permanent of course
> - i only need it for the existing session
> - it really only important when the admin is changing stuff for users or ldap config.

So, in theory while this is accessible only to 'one session' from the users perspective it is accessible to anyone who has www/nobody rights on the webserver. Eg - access to the memory space of apache. 
If the box was compromised in any way I would not only consider the need for where to store, but also 'how' to protect this information wherever it is stored. 

> - i cant use a one way hash, cause i need to send it to another server... 
> - i could do some sort of obfuscation, but is that really secure? better than nothing?

Not really. 

> Options
> - Session Var certainly an option... but other than the obvious session file on the server are there other risks?

The problem your describing is really a encryption and key management problem and not entirely for the faint of heart and readily open for ripe implementation vulnerabilities. 

Brian Snow talked a bit about this at RSA last year on the cryptographers panel which I found interesting. 

Other risks really could also revolve around how that data is dereferenced  and or cleaned up in the event of an exception. 

Case in point:
http://www.packetninjas.net/storage/advisories/MediaCast-PWDump-090310.txt (AD integration like you spoke of,... items were stored in clear text AND they had exception handling issues... no try:, except:, ..)

> - i could store it in the DB, but then thats seems more risky than the session because there are more points of access..

I wouldn't do this. Even reference by hash introduces risks and overhead as well as management of the hashes in the db (don't forget the salting etc.). 

> - an obvious one is to pull all the data from LDAP on the first login and stuff that in a session, but on large LDAP it will slow user login time down... non-starter...
> of course regular session security needs to be optimal...

What would be great is something that performs the features present in oath in a hybrid oath->ldap integration. 

> IDEAS or COMMENTS?  I can handle flames as long as they are intelligent... :-)

I'll chew more on this but quickly gravitated to the problems described/solved in the OAuth RFC as a place where this type of problem has been seen before. 

| Daniel Uriah Clemens
| Packetninjas L.L.C | | http://www.packetninjas.net
| c. 205.567.6850      | | o. 866.267.8851 
"Moments of sorrow are moments of sobriety"



More information about the Owasp-alabama mailing list