NYCPHP Meetup

[Brian O'Connor]

Thanks for the information, was greatly helpful.

I have a question about the basics of sessions you listed though - you say 
that you provide the user with a cookie that contains a long string; what if 
they don't allow cookies? are you referring to the session as a cookie?

And I have a question about my current system:
As of right now, I create 3 sessions for each user: userID, user, and pass 
(md5 of it, I never directly deal with the user's password). The reason I 
think my current system is poor is because I trust the session, and I only 
check the 'userID' session for authentication. So for instance, if the 
userID is mine (ie, 16), and that userid has access to certain areas of the 
website, I allow it, without any further checks.

Don't get me wrong, I don't think it's safe, but it's the system I created 
before I knew much about how php worked, so I didn't really know any better, 
which is why I'm trying to create a more secure system.

On 8/9/05, Michael Sims <jellicle at gmail.com> wrote:
> 
> 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
> _______________________________________________
> New York PHP Talk Mailing List
> AMP Technology
> Supporting Apache, MySQL and PHP
> http://lists.nyphp.org/mailman/listinfo/talk
> http://www.nyphp.org
> 



-- 
Brian O'Connor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20050810/3c4c35b0/attachment.html>