4 Oct 2009 8:24 AM #1
One topic that I don't see addressed to any significant degree is authentication between the client and server (web service), so I was trying to come up with a concept using tokens.
1) User submits username/password via an SSL page.
2) Server authenticates user against database and if valid, generates a token (random number) and stores that along with the IP address of the client in the database.
3) Server send back token to client, client stores in session cookie.
4) All requests to web services via the client (ExtJs AJAX Requests), send along as a param the token.
5) Server checks to see if token and IP address are valid and hasn't expired, allowing call to be completed
I figure with the above mechanism, if someone were to have somehow hijacked the user's token, even if they passed it in, the IP address of the client wouldn't match, thus failing.
Does anyone see any "holes" in the above mechanism?? Any suggestions??
4 Oct 2009 11:47 AM #2
I do think it is possible to spoof the ip address. So someone that has access to server-client communication (steps 3/4) can hijack / take-over the session. So more secure would be to have all communications via SSL (or were you suggesting that in the first place?).
An additional security measure would be to always/frequently change the token, as a token that remains unchanged would lead to a multiple identical headers, which gives a possibility to hijack the session even under SSL. However, I am not sure how that can lead to a successful attack.
BTW I wouldn't consider this a specific ExtJS topic, so in that respect I am not surprised it is not being addressed here.
4 Oct 2009 11:54 AM #3
An additional point is that an IP address is not unique for a user, as a whole company might be accessing the Internet via the same IP. And, clearly users on same IP can hijack each others sessions once they know the token.
4 Oct 2009 1:36 PM #4
Security bugs can be extremely subtle. You plan to allocate tokens via a random number. Random numbers occur in a predictable sequence and are not secure. They are more accurately called pseudo-random numbers.
I would strongly suggest not building your own session management code. This is hard subject for people that specialize in the subject. There are plenty of existing projects to choose from. Do yourself a favor and use one.The plural of anecdote is not data.
4 Oct 2009 1:59 PM #5
Obviously internet security is a specialty in itself (and I am sure with many sub-specialties), but there are many degrees of security and the vulnerability in using pseudo-random number generator seems to me on the high end of the spectrum.
All internet applications developers should have some basic awareness, ie knowing about SSL, cross-scripting, database-injections, etc.
5 Oct 2009 7:47 AM #6
How about using a GUID?
Ya, I realize that people within the same network will most likely be visible on the Internet with a single shared IP address. But in that case, I feel that the threat is much lower because it is the larger, outside Internet that is more of the threat. What I mean is that, if I have built an application, and a particular company subscribes to it to allow their users access to it, any threat coming within the company, IMO, would be next to nil.
Also, is it really possible to spoof an IP address? I mean, when someone hits a website, how do they have a chance to conceal the IP address that actually hit the web site??
5 Oct 2009 8:01 AM #7
- Join Date
- Nov 2008
- San Diego, Peoples' Republic of California
- Vote Rating
Binding a session cookie or token to IP address is problematic, as people with DHCP can get their IP addresses renewed and changed at random times.
Your best bet is SSL and combining the user's login time as part of the hash for the token. On top of this, if you send a separate and freshly generated (each form/time) token any time a form is going to be submitted, you can eliminate XSS type attacks. This second token would be stored in the user's session on the server side and sent as a hidden field on the client side. You can also expire the server-side session token after some period (5 minutes) in case the user walks away from his machine without submitting the form. Upon form submit, delete the cookie from the user's session on the server.
What I see as a huge problem is someone is visiting a message board like this and sees someone post "check out this link!" You click on the link and it's a site under some hacker's control. His site loads JS into your page that does an XHR request back to ExtJs.com (or google mail or whatever), which will send your logged in cookies to ExtJS.com. If the XHR does some URL like ExtJS.com/forum/UserCP?do=changepassword, hacker can hijack your account.
Note that ExtJS is running vb 3.8.4 which has a form token scheme like I mentioned above, so the UserCP.php thing will fail.
The XHR request is just one of several means a hacker can cause you some pain.
5 Oct 2009 8:03 AM #8
Security is always relative; you have to make a trade off between user-friendliness / speed / implementation considerations.
So perhaps for your application it would be fine to communicate via HTTP and check IP address. In general I wouldn't consider that secure. Perhaps the boss doesn't want his employees being able to take over his session? Or at university, the professor doesn't want his students to be able to access his account? Also note that especially for users on same host (IP address) it will be relatively easy to see the communications.
IP spoofing is possible. It might be difficult to catch the response, but it will be possible to fake a request. I think that is also the reason you want to change the token, even when communicating over HTTPS.