NYCPHP Meetup

[Michael Sims]

On Monday 08 August 2005 12:44, Brian O'Connor wrote:

> Well I knew I was doing a poor job before, but this session discussion
> has finally brought me to finally design a new system. However, I think
> in order to prevent against something, you need to first learn how it
> works, which is why I write. What is session hijacking, and how do you do
> it? I'm currently designing a new site where security is very important,
> and I feel the need to go fully into this. If anyone could explain, or
> point me to some articles ( can't really afford books at the moment,
> about to leave for college and don't really have that much money ) I
> would greatly appreciate this. Thank you.

Basics of sessions:

1) User logs in providing something he knows (username, password)
2) You assign (cookie) the browser with a long random string.  You record 
the string in a datastore on the server.
3) Anytime you get hits from a browser which presents the long random string 
that's in your datastore, you can assume it's the same user - therefore you 
need not ask for the username/password again.  Also, you know what the user 
did last - you can keep state across requests.
4) If time passes without access, you might delete the long random string in 
your datastore, rendering the browser's credentials invalid and requiring 
the user to log in again.

Good points:

1) User doesn't have to log in for each page.

Bad points:

1) If someone obtained the long random string, it would be like obtaining 
the user's username and password.  Bad person's browser could present the 
long random string...

Ways to hijack a session:

1) Eavesdrop on the user's datastream.  By default, all of this is in plain 
text, including the initial sending of the username and password.  
Solution: use HTTPS.

2) Find a way to insert javascript on YOUR website that accesses the cookies 
the user is sending and resends them to BAD_WEBSITE.  This is called 
cross-site-scripting, or XSS.  Solution: design your website to not echo 
any user input back to the user without sanitizing it.  Many, MANY sites 
are vulnerable to this.  The only upside is that usually XSS attacks have 
to be customized for the site they are attacking - someone has to want to 
attack YOUR site, not just any site.  The motivation for doing so is as 
valuable or as non-valuable as the accounts on your website are (so many of 
the vulnerable sites don't really need to care).  Read up on XSS.

3) If your session id's are being maintained in the user's URLs rather than 
user cookies, an attacked just has to get the user to follow a link to 
BAD_WEBSITE, then the session id will show up in the HTTP_REFERER variable.  
Solution: cookies are much preferred over URL-variable sessions.

4) Hack your server.  Solution: Don't let them hack your server.

5) Come along shortly after a user and use the same web browser he did.  
Solution: limit session length, warn users about logging in from public 
workstations, use session cookies that are deleted when the browser is 
closed, etc.

Miscellaneous:

1) Some people store state info in the cookies themselves, where the user 
can get at and modify them.  I prefer storing it serverside.  For 
unimportant state info, like a user's choice of language for a site, it 
doesn't matter.  For important state info, serverside is the only choice.

2) PHP's session info is stored in text files on the server.  I prefer 
sessions that are stored in a real database.  For small sites, it doesn't 
matter.  For large sites, database is the only real choice.

3) Keep in mind that PHP's built-in session-handling is one implementation 
of the idea of "sessions", and not necessarily a good one for you.  You can 
write a PHP app that does sessions, and does them very well, without using 
any of PHP's session-handling functions.

4) Storing and verifying other info about the user (such as their IP 
address, user-agent string, or what-have-you) is effectively requiring the 
user to present more than just the long random string to validate his 
session.  Your sessions will break if you require something to be static 
(i.e., IP address) that actually isn't (AOL users behind an array of 
proxies).  Also, if the attacker can steal the long random string, he can 
just as well get the browser user-agent, etc. etc.


Michael Sims