Post-XSS scenarios and database driven sessions

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 #15, on June 21st, 2011, 04:41 PM »
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.
The way it's meant to be

[Unknown]

  • Posts: 77
Re: Post-XSS scenarios and database driven sessions
« Reply #16, on June 21st, 2011, 05:09 PM »
Quote from Dragooon on June 21st, 2011, 04:41 PM
What is clickjacking? When someone makes an image leading to a private url?
Clickjacking is popular with, for example, Facebook Like buttons.  But it's also a way to steal logins.

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.
Quote from Dragooon on June 21st, 2011, 04:41 PM
Also, doesn't httponly contain a few security problems of its own? Even cPanel recommends cookie instead of httponly.
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.
Quote from Dragooon on June 21st, 2011, 04:41 PM
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.
Mainly, yes.  It also protects against man-in-the-middle attacks and a few others.

-[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 #17, on June 21st, 2011, 05:43 PM »
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.
Quote
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.
Ohh, I totally mistook what httponly meant, I thought you were referring to HTTP authentication, I didn't know you were referring to the flag which completely disables cookies being exposed to javascript. That is definitely in I believe.

[Unknown]

  • Posts: 77
Re: Post-XSS scenarios and database driven sessions
« Reply #18, on June 21st, 2011, 07:31 PM »
Quote from Dragooon on June 21st, 2011, 05:43 PM
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.
Well, if you detect the iframe and use headers, you can prevent it.  The goal is making it so the user doesn't think everything is okay.

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]