 |
Account Login
|
 |
|
Latest Articles
|
|
|
IRC Channel
|
|
|
Associates
|
|
|
Associates
|
|
|
|
Article Reviews |
|
httponly
|
|
|
|
Review added by SneakyWhoami
on 09-30-2009
|
|
All linked articles in my comment are also available on wikipedia.
For a complementary method with no downside, use an httponly cookie to store the session id.
http://www.owasp.org/index.php/HTTPOnly
That will break your prompt attack in one line of php; javascript won't be able to access the cookie.
Dog Cow is right about the XSS. There are pages on this:
http://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
Hiding it in POST doesn't help. You can script a post request cross site in javascript using a hidden iframe and a form's submit() method and target attributes.
Using ajax will only make it harder for legitimate users and easier for attackers if anything. A GET-ted ajax request can be turned into an img src attribute and called from anywhere.
Basically pretty much any element in HTML can be turned into an XSS vector; while it's important to protect your session cookies (which was the whole point of the article) you have to protect your users from other kinds of session hijacking which are easier to pull off (and work for a disgusting number of sites).
Specifically I'm talking about CSRF: http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
Nonces are your protection against CSRF. CSRF is easier than stealing a session cookie so a more urgent form of session protection. Require proof that the user actually owns the session!
|
|
|
Buiding on from that...
|
|
|
|
Review added by JaoudeStudios
on 07-15-2009
|
|
|
It is more secure to save the session data in a database rather than the usual method which is in the /tmp directory.
|
|
|
Good advice, but not comprehensive
|
|
|
|
Review added by Dog Cow
on 02-03-2009
|
|
Keep in mind that while this article provides good advice, it is not comprehensive.
Imagine this hypothetical situation:
Some web site allows users to delete their own account, at this URL: http://exmple.com/account/delete.php
Now, if user Bob is logged in, he may not ordinarily delete his account. But here's the problem: a malicious user named Joe can set up his own web page, and use Javascript to make an HTTP request to that delete account URL.
If Joe can trick Bob into clicking onto his web page, then that javascript will execute the request, using the Bob's own cookie data, IP address, and browser signature.
The fix? Implement a token/hash in sensitive URLs, and make this hash unique for each user and require it in order to access potentially "dangerous" URLs. This means that malicious user Joe will have a lot harder time guessing what the token is.
Simply substituting the POST method without using a hash is NOT a fix. Javascript can execute GET and POST requests in less than 10 lines of code.
|
|
|
.....
|
|
|
|
Review added by nightowl
on 01-07-2009
|
|
a) it's perfectly possible to be on the net at the same time with different IP addresses. Big LAN's often have an internal IP, and use several outbound IP's in a sort of round robin. You'd accuse somebody of stealing a session while it's in fact a correct user
b) you claim it's that easy, but your first step requires access to the person's computer you want to steal the session from ... and if you have access to his computer, why not just use his computer then? ;)
|
|
|
hmm
|
|
|
|
Review added by t3st
on 11-17-2008
|
|
|
is there a way to just save the mac address rather than the ip address??
|
|
|
Not entirely true
|
|
|
|
Review added by kjarli
on 10-31-2008
|
|
|
If you are behind the same router or switch, the server can't figure out the difference. Somewhere I have a dutch version of how to steal them, when I have some time I'll translate it.
|
|
|
Member's Menu
|
|
|
|
|
All times are GMT. The time now is 05:32 PM.
Join the friendly bunch on IRC...
