At the suggestion of my mother and some other members of my family, I’ve just finished The Shack by Wm. Paul Young. My overall impression is that its a good book, especially for someone who has recently lost a family member or someone who has strayed away from God. The first part was hard to get through, I’m not one for violence against children. It turns my stomach. Everything is righted at the end, but its still difficult.
The one thing to remember is that this is a fictional book. If anybody were to interpret this as literal or a true story they would have a hard time believing it. It does raise some great questions though. Something I have always struggled with is if Jesus is the only way to the Father, then what about the billions of other people who aren’t Christians? There are many people who are never given the chance to learn about Him, so why should they be damned? I think this book sheds some interesting light on that issue.
Even more interesting: is this book so appealing because this is the type of God people want to believe in? A God that unconditionally loves us with no eternal consequences for our actions? It puts a huge dent in the belief of predestination. Many of aspects of this book make sense to me, but its not based on Scripture. There’s even some antiestablishment tones about religion…I don’t know if Jesus would say some of the things he did in this book. Even though the church is a human establishment susceptible to evil, I would think Jesus is happy about some of things we are doing.
Overall, I would suggest reading it. It’s a short read and will raise some feelings that maybe you haven’t had in awhile.
Eric Books
The folks over at Errata Security have a blog post about Cyber Commands failing. They make some really good points, but they are missing a few things.
On the offensive side, they’ve hit the nail on the head. Hacking is asynchronous and to do it on command will be difficult. The one aspect left out of their article is a DDoS attack capability. We may already have this capability, but its probably classified. Russia used DDoS effectively against Georgia last year, so hopefully that opened some eyes.
On the defensive side, we most definitely need a central cyber command. We do have some standards organizations and policies, but the mandates are too loose and there’s not much oversight. There needs to be a huge push for software security. I think the government does a decent job with network security, they just need to extend that ability to contractors. A central cyber command with the charge of defending the United States against cyber attacks is crucial.
Eric IT Security cyber security command
The Joint Strike Fighter program was infiltrated by Chinese hackers attempting to gain intelligence on the new aircraft. According to the article, this was a network attack on the contractors in charge of developing the JSF.
The article makes a great point about there not being a single agency in charge of cyber security. The Department of Defense should have a central organization with a clear mandate to increase our defenses against cyber attack.
Eric IT Security
Cross Site Request Forgery (CSRF or XSRF) is number 5 on the OWASP Top 10 and the “silent killer” of web app vulnerabilities. The best way to handle this problem is use a “token” system that is unique to every user. If the server side receives a request that does not contain the correct token, then the request is not processed.
In .NET, the ViewState provides this functionality…or does it? The ViewState by itself does provide some protection. The ViewState is a hash value use to store state information between PostBacks. This ViewState can be altered and recorded, so it’s not completely safe. To increase the safety, you can use the ViewStateUserKey property to encrypt the ViewState to the session ID of the current user. That reduces the exposure to recorded attacks.
But what if the ViewState is passed as a GET variable? If it’s not a PostBack, then the ViewState will not be checked. There’s that false sense of security again.
Setting the ViewStateKey is a good step, but to completely block CSRF, you will still need to use a token system with good resistance to brute force.
Eric IT Security
Cross Site Scripting (XSS) is listed as the top vulnerability on the OWASP Top 10 and one of the more dangerous vulnerabilities on the web. Because of the different ways to manipulate content, fighting XSS is a chore. For proof, check out the “XSS Cheat Sheet” at http://ha.ckers.org/xss.html. That list is still growing…
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.
Eric IT Security cross site scripting, software security, xss
There’s a good post over at ha.ckers.org that list some live sites that you can use to practice exploiting vulnerabilities. In addition, you could probably use demo.testfire.net. The site was created by Watchfire to test AppScan, but you could also use it for light testing.
Eric IT Security application security
In my line of work I go to customer sites, scan software, and provide training on using our tools to write secure software. The problem is that while we’re talking about detailed attack categories, we don’t give much detail on how to fix them. There’s usually not enough time to show a developer how to use regular expressions or html encoding to block vulnerabilities. Our academic institutions are not really teaching software security, so developers are on their own to learn how to do this.
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.
Eric IT Security .net, software security