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/

Java Applet Security?

With so many Java applets vulnerabilities, it's tough not to poke at Java applet security. But what about the real world? Are we seeing any real attacks against enterprise applets? And how good is applet security when compared to ajax/javascript web sites that we see today?

"I'm always surprised how far people will go to ding Sun/Java security, when there are so many other targets that are so much worse it's not even really the same thing." - Jeff Williams

Well here's one for the applet side...

http://www.cio.com/article/141151/Sun_Changes_Java_Updates_Following_Criticism

Web Development Time Breakdown

What a brilliant piece of web-development wisdom! This one made me laugh out loud...