Wedge
Public area => The Pub => Off-topic => Topic started by: Dragooon on June 21st, 2011, 12:45 AM
-
I've been running post-xss scenarios and the obvious one is cookie stealing(Perhaps the only use of XSS) and after a cookie is stolen. The common protection is using sessions and I've not been doing that, although can't that too be stolen since it has to be tracked via cookie? So is there a way to protect against a post-cookie stealing scenario?
Also, how do database driven sessions help?
-
Last question first. Database driven sessions help in shared host cases. By having them in your database tables, as opposed to a system-wide temporary folder, the odds of session poisoning or simple overwriting by accident are basically nil.
Post-XSS scenarios... hmm. Cookie stealing is the main one in our case, especially when you start combining it with CSRF (doesn't have to be explicitly cross site!)
If you can steal the cookie, you can theoretically regenerate it on a separate machine and spoof the session - though you have to generate it as a cookie, you can't just plug it into the URL and expect it to work (if it did, you'd have a session fixation issue). The solution for that is to use HTTP-only cookies, cookies that indicate they are only for the current browser context and explicitly not exposed to the script context.
That won't prevent you if you have URLs with the session in them, which can be scraped and are accessible to the current scripting context.
-
Last question first. Database driven sessions help in shared host cases. By having them in your database tables, as opposed to a system-wide temporary folder, the odds of session poisoning or simple overwriting by accident are basically nil.
That won't prevent you if you have URLs with the session in them, which can be scraped and are accessible to the current scripting context.
-
That's it? Well that's depressing...
Would PHPSESSID count? I wouldn't think so.
-
Ah yeah. I didn't think of that. Plus HTTP security has a few issues and holes of its own. Since mine is a custom made project and it contains a lot of sensitive information, I am very paranoid of security. Features be damned if a single security issue arises. Although since at the moment data can only be entered through our staff, XSS isn't a possibility but we will be opening it to the public
Oh, and in SMF's case, if an user got somebody's cookie he or she can basically access his or her account since passwords can be sent pre-SHA1'd.
So far here are a few things I've thought of
- IP checking (Can't find a way around it)
- Small cookie time length
- Database check for cookie time length(All the whole time thing can be poofed).
- Storing a token instead of password in the cookie
-
Let's be honest for a moment: the entire nature of cookies is a workaround for the fact that you want to represent some semblance of state over a protocol designed to be stateless.
Oh, and in SMF's case, if an user got somebody's cookie he or she can basically access his or her account since passwords can be sent pre-SHA1'd.
They have access to the 'softer' stuff. They won't be able to go into the admin panel (assuming admin security has not been disabled), or change account options for other users (also uses admin security check), or change account details for the user they're masquerading as (since it requires their current password to do so)
-
Ah so that's what the salt is for, didn't know that. Thanks :).
Let's be honest for a moment: the entire nature of cookies is a workaround for the fact that you want to represent some semblance of state over a protocol designed to be stateless.
-
Ah so that's what the salt is for, didn't know that.
Well that's true, and it's quite saddening knowing that there are ways to get around all this.
Really, even sticking it all over SSL isn't foolproof, it just helps protect against another slew of issues.
-
Really. Really. htmlspecialchars.
-
htmlspecialchars is a tool. It protects against one angle of attack. There are others.
-
Yes, it was one of my more useless posts. I'm burned out, haven't slept in all night.
-
Ugh, I know that feeling, hope you get to sleep OK soon
-
- IP checking (Can't find a way around it)
- Small cookie time length
Small cookie timeouts are a good idea, as long as you use a session keepalive (or are fine getting logged out constantly.)
The best way to do "remember me" is like another form of sessions (just not garbage collected.) This allows you to have a button to log other computers (which each have a separate token) out or etc. SMF tries to do this, and does okay, but the better way is to have each computer use a separate token.
-[Unknown]
-
I've really been looking into it even though I was 16 hours overdue for sleep. So the best way against XSS is to prevent it, I've realised that regardless of the measures the session will be stolen. So it is mostly in hands of htmlspecialchars, is there other way to do XSS even if the output is htmlspecialchar'ed?
As far as CSRF go, I guess that's what those session tokens in SMF are for?
Also as far as iFrame go, a person can't really steal a cookie from iframe correct?
-
I've really been looking into it even though I was 16 hours overdue for sleep. So the best way against XSS is to prevent it, I've realised that regardless of the measures the session will be stolen. So it is mostly in hands of htmlspecialchars, is there other way to do XSS even if the output is htmlspecialchar'ed?
As far as CSRF go, I guess that's what those session tokens in SMF are for?
Also as far as iFrame go, a person can't really steal a cookie from iframe correct?
For CSRF, actually, using XMLHttpRequest and setting custom headers can really help here. But yes, using SSL and using some sort of token in the URL works well.
For iframes, there's X-Content-Frame-Options or something like that. You can't steal a cookie, but clickjacking is a significant security concern.
<IfModule mod_headers.c>
Header add X-Content-Type-Options nosniff
Header add X-Frame-Options SAMEORIGIN
</IfModule>
-[Unknown]
-
What is clickjacking? When someone makes an image leading to a private url?
Also, doesn't httponly contain a few security problems of its own? Even cPanel recommends cookie instead of httponly.
And SSL mostly protects against traffic sniffing correct? I'm mostly trying to figure out what is the significance of each security measure out there.
-
What is clickjacking? When someone makes an image leading to a private url?
Imagine I show you your bank's webpage, inside an iframe. Imagine they show you a "site seal" or some such, with a picture. Because it's in an iframe, this works fine, and they show you exactly what you expect.
But now, I create an absolute positioned div. I place this on top of the iframe, right where the login textbox and button normally are. I carefully design it to look exactly like you're used to.
Now, sure, hopefully you check the domain name... but, after all, you see your site seal, don't you? All is well. Just your browser isn't autofilling the password. Darn buggy browser. And then you retype it. Victory for me, the hacker.
This technique can be applied to endless scenarios.
Here's another. Suppose I want you to delete a post, but you don't want to delete it. I create an interesting page with a button you can click to start playing an exciting game I created.
Next, I place an iframe on top of my game, but I set it to opacity: 0. Then I absolute position and use the zoom css property, such that the "delete" button is exactly on top of the "start playing" button.
Now all I have to do is get you to try my game. You'll tell me it doesn't work (ah, sorry, bug fixed, thanks for testing.) And now you'll have done the administration I wanted you to without even knowing it. Thanks a bunch.Also, doesn't httponly contain a few security problems of its own? Even cPanel recommends cookie instead of httponly.
And SSL mostly protects against traffic sniffing correct? I'm mostly trying to figure out what is the significance of each security measure out there.
-[Unknown]
-
But then you can't really prevent an iframe fooling people, now can you? It's all up to people to properly look out for that. Session tokens might restrict them to the point where blind images won't screw but if a person does get the entire site in his iframe, he has almost endless control.
Sending session ids over GET: bad. Use cookies only ini setting. Sending cookies with the "httponly" flag so that JavaScript cannot even read them via document.cookie: good. Definitely enable the httponly ini setting.
-
But then you can't really prevent an iframe fooling people, now can you? It's all up to people to properly look out for that. Session tokens might restrict them to the point where blind images won't screw but if a person does get the entire site in his iframe, he has almost endless control.
Try putting http://www.facebook.com/ in an iframe in a test.html file or something. You'll see how it refuses to load.
-[Unknown]