Confused about variable poisoning and session ID's

[journy101]

Im very confused about session ids and prevention variable poisioning. Say I have a script PHP/ASP dont matter. a function checklogin checks the username and password are valid and loggs you in by setting a variable login=true

Because the username and password are required, this prevents anyone from gaining access by setting loggin=true in a GET request, so the atacker tryes something like

www.mysite.com/index?login=true

and they dont get in because a password and username is required so even if they enter username and password into the get request they would need a valid password.

So typicaly I read that login scripts use a session ID to keep track of this data and prevent poisoning, but my question is this:

Why do I need to register any session variables?, if the password and username needs to be valid, then it would not mater if the data got to me in a GET, POST, PUT or cookie Theyd need a password.

So then whats the purpose of session id's???

Im confused beacuse the get request would need a valid username and pass wouldent mater if its associated with a session right?

[nebulus200]

It is my understanding that the session id is often passed around to avoid having to continually feed usernames/passwords into a web page. Once the user is authenticated and the session id generated, the sid is passed around and not the user information and this is usually the source of problems with security in that if the sid is easily guessed, you could 'hijaack' someones browsing session, but on the positive side you aren't repeatidly passing around user credentials...and if implemented properly (ie, sid not easily guessed and there are safeguards to timeout sids), can be a secure way of allowing access without passing around username/password pairs.

Aside from the sid working on the authentication side of things, it could also be used for tracking the 'state' through a web site, ie, whether or not they user has filled out a required form to be where they are or something to that effect.

You would need to be really careful about using cookies, if improperly done, you might be subjecting yourself to cross-site scripting vulnerabilities and cookie grabbing...(or your users)...

I might be wrong, but that is always been the way I have understood things, hope this at least helps the ball start rolling...

/nebulus

[journy101]

Thank you nebulus that makes much more sence now. Was reading around alot of example login scripts out there and even been reading about session ids and variable posioning and it was getting so confuseing.

You have a way with words, thanks.

[nebulus200]

It just occured to me that I didn't really say why it could be bad to be passing around username/passwords to logs:

1) Someone sniffing a user's connections could obtain a valid username/password pair (true they could obtain the SID as well, but if you have implemented timeouts, they would have a small window to take advantage of the info).

2) Logs. The username/password would show up in your logs, probably the person's ISP's logs, any proxy servers that they pass through, and if they quote URL's from the site, maybe even in your users own posts (once again this could be a problem with sids too, but the same argument as above applies).

So now for example, instead of passing around URL's like: http://www.mysite.com/index?login=tr...word=password, after logging in, they pass around urls like http://www.mysite.com/index?sid=aabcde34234fbadecaf. Note, it generally is a bad idea to be so blunt as to call it a sid , although I have noticed AO does this...

By hijaacking a browsing sessions, what I was referencing was as follows. Say you have a web page, after you log in, it issues a sid that is say a sequential number (or even more secure a hash of say the username and the time using say base64 encoding, but still not secure enough) . So you wind up with a url of http://wwww.mysite.com/index?sid=1. I am hoping it is pretty clear why that is bad, there is nothing stopping someone else from coming along, putting that sid in there and having the same permissions (and really becoming same person) as your signed on user. So, if the sid is easily guessed, you can essentially take over the person's session fairly simply, which is probably what you were reading was warning you.

The writers of Hacking Exposed have put out another add-on book titled : Hacking Exposed : Web Applications in which they cover this very very extensively. I highly recommend taking a peek through the book, this topic and several others are covered.

/nebulus
'
EDIT: Just realized I didn't even touch variable poisoning. Variable poisoning could be an issue like you said only if there are no other checks/sanity checks on the variables and can be an issue not only for authentication, but for things such as variables in forms. You'd be suprised how many things are not sanity checked. Using a program such as curl or curlssl, you can inject whatever values you want, so for example, say you had a form for the quanity and price of an item:

<form action=somescript.php method=POST>
Price: <input type=hidden value=9.99 name=price1>
Quantity: <input type=text value=0 name=quantity>
<input type=submit name=submit>
</form>

You could essentially use curl to change the value of the hidden variable and do something like:

somescript.php?price1=0.09&quantity=20&submit=1

You now have a substantial discount...same bad things could happen with improperly secured login variables...

[journy101]

You mention "Hacking Exposed : Web Applications" Thanks for that sugestion, sounds like it will answer alot of my questions about web application security and the likes. I will definately check it out. The methods you mention where a sid could be captured and used to impersonate a user makes much more sence.

The articles i was reading mainly were login script examples and the PHP manual pages for session related functions. One thing that was mentioned was how if you link to other sites your session id might apear in the reffer log of the linked to web site. Your tip on session timeouts I can see now how that would be imporatant.

When i started makeing my login script last night I knew nothing about session ids but came acros them when looking for examples, though I find some of the examples out there are a bit complicated as they contain my_sql stuff that im not at all familiar with.

Thanks once again this has helped me much, and has given me a valuble skill if I deside to get a job as a web developer I would need to be aware of this kind of thing.

Thank you.

[zigar]

check out the OWASP Top 10 Vulnerabilities in Web Applications and
Guide toBuilding Secure Web Applications V 1.1.

http://www.owasp.org/

[Juridian]

The user name and password are used to authenticate the user. You need session variables of some kind to maintain the users logged in state. Since http itself is stateless, you will need a variable or more of some kind to continually prove that the user is logged in with each page request.

These state variables can be in the client memory, in the cookie, etc.

You generally do not want a value such as you mention above (login=true) because it is far too easy to figure out the system and attempt to manipulate it. And you certainly don't want that in the query string of the browser.

Also, there is a very good paper (2 parts) on auditing web application authentication on securityfocus.com.

Part one - http://www.securityfocus.com/infocus/1688
Part two - http://www.securityfocus.com/infocus/1691

[Juridian]

There is also this set of documents by SCORE for auditing web applications - http://www.sans.org/score/webappschecklist.php

[journy101]

the site http://www.owasp.org/ i have bookmarked, very interesting, indeed I found it mentioned in the 3rd one down in list of top ten

"Broken Account and Session Management"

Very interesting and answeres alot of my questions, have been working with sessions now for few days, and seem to have goten my login system working and last night found a way to logout a user by first unsetting all session data, destroying the session, and calling my custom made garbage colector for my own session save handler.

Makeing my own session save handler was a bit of a task but I mainly modified what I saw in php.net

Thank you Juridian for those two articles which I will be reading tonight.

And once again to nebulus200.

EDIT: I have completed reading Part one - http://www.securityfocus.com/infocus/1688 and has given me some ideas to strenghten my login security that I have overlooked, such as engourageing strong passwords, expireing old passwords and the use of password reminders or secret questions.

Thankyou for these links.