« Salary in web development
Post-XSS scenarios and database driven sessions
htmlspecialchars while inserting into DB »

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Post-XSS scenarios and database driven sessions
« 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?
The way it's meant to be

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Post-XSS scenarios and database driven sessions
« Reply #1, on June 21st, 2011, 01:20 AM »
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.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Post-XSS scenarios and database driven sessions
« Reply #2, on June 21st, 2011, 01:38 AM »
Quote
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's it? Well that's depressing...
Quote
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.
Would PHPSESSID count? I wouldn't think so.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Post-XSS scenarios and database driven sessions
« Reply #3, on June 21st, 2011, 01:42 AM »
Quote
That's it? Well that's depressing...
*shrug* There is also the fact that in a fair percentage of cases (and if you're tuning your server, more than a fair percentage), the session table will also reside in memory rather than forcing disk I/O. Any table that's hit every single request has to be worth this...
Quote
Would PHPSESSID count? I wouldn't think so.
Yup. Don't know if you're thinking of SMF/Wedge or something else, but if you don't have the cookie, you're relying on the session being passed through the URL, which means it's scrape-able from there. Worse still, depending on how that session is validated, there's also a potential vulnerability from fixation where the provided one is treated as expressly valid and ends up overriding a genuine session id, so an attacker forces a user to have a predictable session id... which isn't very good.

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Post-XSS scenarios and database driven sessions
« Reply #4, on June 21st, 2011, 01:53 AM »
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

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Post-XSS scenarios and database driven sessions
« Reply #5, on June 21st, 2011, 02:02 AM »
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.
Quote
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.
The password has been hashed with the passwordSalt (password_salt) value, which is known only in the database, and it *must* be SHA1 hashed with that salt on receipt, it won't ever be accepted by the cookie authentication code if not, and that salt is never shared.

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)

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Post-XSS scenarios and database driven sessions
« Reply #6, on June 21st, 2011, 02:05 AM »
Ah so that's what the salt is for, didn't know that. Thanks :).
Quote
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.
Well that's true, and it's quite saddening knowing that there are ways to get around all this.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Post-XSS scenarios and database driven sessions
« Reply #7, on June 21st, 2011, 02:12 AM »
Quote
Ah so that's what the salt is for, didn't know that.
That's about the only thing it is actually used for.
Quote
Well that's true, and it's quite saddening knowing that there are ways to get around all this.
Every system has its chinks. Short session length, using tokens, time state etc. are all things your banking site should be doing out of the box anyway.

Really, even sticking it all over SSL isn't foolproof, it just helps protect against another slew of issues.

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

[Unknown]

  • Posts: 77
Re: Post-XSS scenarios and database driven sessions
« Reply #12, on June 21st, 2011, 05:14 AM »
Quote from Dragooon on June 21st, 2011, 01:53 AM
- IP checking (Can't find a way around it)
- Small cookie time length
IP checking is okay, if you're sure none of your users are on AOL.

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]

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Post-XSS scenarios and database driven sessions
« Reply #13, on June 21st, 2011, 03:21 PM »
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?

[Unknown]

  • Posts: 77
Re: Post-XSS scenarios and database driven sessions
« Reply #14, on June 21st, 2011, 04:36 PM »
Quote from Dragooon on June 21st, 2011, 03:21 PM
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?
Well, httponly is pretty useful against XSS.  Not a silver bullet, but a good option.

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]
« Salary in web development
htmlspecialchars while inserting into DB »