Deeper CSRF Protection

It's almost impossible to truly protect against stored CSRF found on a secondary/malicious website, not to mention browser Trojans that we see in the banking industry on a regular basis. It's non trivial to protect against these problems, but here is one potential solution to deeply secure this frightful attack vector:

a) Implement form keys defense on all forms where both the key name and value is a strong random session id. (Current standard defense)
b) At time of login, inject another per-link session ID to all URL's of that page. No request can even request a copy of a form without the correct url-level session id.
c) If some code is trying to request a page/form with the wrong session id, explain to the user of the attack and log them off their session immediately.
d) Any time a new page is returned to the user, create new per-link session ids for all additional links on page.

This defense strategy would still work in a multi-tabbed enviornment. The key differentiator is that a potential attack from malicious CSRF would be detected and drop the users session immediately since there is an obvious compromise or poor surfing habits.

I want Cake, but please make it Light (as in Lightppd)

What a great post from Brendon Crawford (working on the woefully insecure PHP language) showing how to get CakePHP 1.1x running on Lighttpd. The woosies at CakePHP rejected his excellent patches for "IP reasons", so sad.

Anyhow, here we go!

http://thefaultandfracture.blogspot.com/2007/10/enabling-cakephp-11-on-lighttpd-15.html

Java Snob Laughter

Yes, I'm a serious Java snob who has spent way to much time working with PHP. I've tried hard to artfully describe my disdain for PHP, and I would like to thank the people at http://tnx.nl/php for helping describe my feelings in my favorite art medium: inspirational posters! :)

Reflective XSS protection, output encoding

UPDATE: The best XSS defense strategy is described here:

http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

***

Thanks to Eric Sheridan over at OWASP for fielding our "battle of the output encoding method for reflective XSS Protection" competition today! All commentary below is from Eric via email on 10/4/07.

>>1) Output encoding try 1 (Jim)

""

Although it is not frequently mentioned, URL encoding will prevent reflected XSS attacks. The browser will not interpret URL encoded values. It looks as though this approach is sufficient for this particular instance. However, I'd recommend you use HTML entity encoding instead. Aside from addressing XSS, entity encoding will fix that 'ugliness' problem that you mentioned.

>>2) Output encoding try 2 (Brendon)

badChars = [ "<", ">", "#", "&", "'", "\"" , "%", "\\" ];
entities = [ "<", ">", "&", "'", "*", "%",
"\" ];

word = "some bad xss phrase goes here";
out = "";
i = 0;
while(i < ordinal =" toAscii(word{i});" killbadchar =" false;" j =" 0;" ordinal ="="="" killbadchar =" entities[j];"> 126) {
    out .= " ";
    i++;
   }
   else {
    out .= word{i};
    i++;
   }
}

print( out );

Eck, rough looking pseudo-code :)

If I were doing a security review and I saw some code like this used to prevent XSS, I would mark it as a finding (albeit low, for the moment). This is a 'negative' or 'blacklist' approach - the developer is rejecting known 'bad' characters rather than accepting known 'good' characters. Guys like RSnake (http://ha.ckers.org) spent their entire career bypassing such blacklist filters. Don't get me wrong, this method will prove effective in a lot of scenarios. Unfortunately, there are going to be special cases where this particular method fails. Consider the case when user supplied data lands within a JavaScript tag. Example:

<script language="JavaScript">
var a = ;
</script>

In this particular example, the proof-of-concept would look like "a; alert(document.cookie); var b=" (without the quotes). A real attack vector would have to do quite a bit of obfuscation, but a determined individual will find a way (see 'Myspace Worm').

If you are looking for a good output encoding example, check out

http://www.owasp.org/index.php/How_to_perform_HTML_entity_encoding_in_Java

This method follows a 'positive security model'. It only accepts the known good values and entity-encodes all of the rest. I think the method is so simple that it can be easily ported to any language. I'd recommend you use this method in place of the two output encoding attempts listed below. Also, if your validation routines detect someone trying to enter malicious javascript, I'd highly consider logging the event as a "security event". Hope this helps!

-Eric

Secure Coding Smartie

"Product teams don't get better by reading secure coding standards. They get better by working with security testers, seeing how their code gets broken by attackers, and learning from the experience. Before we expect software companies to ship better products, we need to see a top-down commitment to security, just like we saw at Microsoft. Everyone from the board room down to the QA team needs to agree that security trumps feature sets and release schedules."

- Thomas Ptacek, principal with Matasano Security.

Who would have predicted that Microsoft would become the poster-child for secure application development practices?

JavaScript debugging in IE 6/7

Thank you Brendon Crawford for this excellent summary:

After thoroughly testing and trying about 9 or 10 different products, I have come up with the definitive must have list for debugging and developing in IE. These are all free BTW:


1) CSS/HTML inspecting - Microsoft Internet Explorer Developer Toolbar (Free)
2) AJAX/HTTP Inspecting - Fiddler (Free)
3) Javascript debugging - Microsoft Office XP Script Editor (Free if you have Office)

And here are the tools to avoid (too costly, difficult to use, lacking features, lacking stability, or unnecesarily complicated)

1) Microsoft Ajax View
2) Firebug Lite
3) CSSVista
4) DebugBar
5) DebugBar/CompanionJS
6) Microsoft Script Debugger
7) IE Watch
8) DocMon
9) IE WebDeveloper V2

IED and WebAppSecurity

When reading this article about how the US Military is struggling to defeat IED's - I could not help but think of this topic parallels to how difficult of a time we are having in terms of Web App Security.

http://www.msnbc.msn.com/id/21053750/