OFFICIAL: web application security is pants

According to the 2009 Web Application Security Report from NTA Monitor, 90% of all web applications have at least one medium risk vulnerability and 27% have at least one high risk vulnerability. Apparently the most common vulnerabilities are those which involve SQL injection, cross-site scripting and cross-request forgery. One data security specialist told DaniWeb that not only should this come as no real surprise, but nor should the fact that the problem is steadily getting worse instead of better.

Brian Contos is the Chief Risk Strategist at Imperva, and he points out that the high risk category percentage is up from 17% last year, while the medium risk number has risen from 78% a year back. "Although this comes as no surprise to us" Contos says "it is an appalling indictment on the software audit and control operations in most companies. With NTA spotting an average of 13 vulnerabilities per test, it's clear that IT departments really do need to pull their socks up in terms of testing and auditing of their software development processes."

Indeed, according to Contos, NTA Monitor's report proves what he has been saying for some time: few organisations have the in-house resources to perform regular software testing and updating a clearly-stated set of application security policies. Worse, even fewer do as NTA Monitor suggests and include security service level agreements into their contracts with Internet or managed service providers.

Maybe some of the recently projected increase in security budgets for 2010 should be diverted to ensuring that web application developers do a better job of protecting those who use their products?

If you are a web app developer, how much of a priority is security in the overall scheme of things?

[MichaelWClark]

I always try to keep secure coding practices in mind. I will use Stored procedures, input validation and sanitation and always re-authenticate on page load if I am utilizing session, application, or cookies. I do this all coming from a web-hacker/ security upbringing so I am a bit more conciseness and knowledgeable about these issues than most. I am a purely self taught IT professional and I have a firm grasp on how exploits are executed, what makes them work, and how to code in a manner that doesn't allow them. I however am only one man at one business, most programmers coming out of college I fear are not being taught the security aspect of it as much as they should be.

Even with a solid background in security it is not easy to audit my code 100% on every project. Programming is a complex and time consuming profession. Security auditing is hard to fit in between 10s of thousands of lines of code and reporting to department heads concerning there projects. With the amount of code I write we could probably hire a part time security auditor to do nothing but read code all day and document potential security issues. This however is not feasible or in the budgets. Also it would add cost and reduce the benefit to dev-ing in house as opposed to outsourcing.

This is, always has been, and probably always will be a difficult issue to address. I think the only way to really make sure the number of exploits out there drop is to increase the teaching of secure programming in schools and universities. Being able to code secure is only half of it. Having the knowledge of how these exploits work will help any programmer to consciously avoid coding in a way to allow these.

[dnanetwork]

have u ever heard of Session HiJacking..?

wot would be steps you will take to prevent this action..?

do you any site you have deployed..just wanna checkout for fun!

[MichaelWClark]

Yes I am aware of Session Hijacking. ASP.NET apps tend to be much less susceptible to Session ID guessing because ASP.NET uses highly random 120-bit numbers for its session IDs (unless you specify your own ??why??). Even with this in place it is possible to hijack a session with stolen/borrowed ;) cookies. Because of this I simply do not use Session data for authentication when possible. ASP.NET has the Application("..") and ViewState(" ") for keeping data alive across post backs if needed. Even with these I tend to stray from these forms of authentication. I develop primarily for intranet applications so I tend to use Active Directory paired with forms authentication.
If I decided that Session Authentication is going to be the best option for me I will use the session ID provided by ASP.NET and pair this with <sessionState cookieless="true" />. Steal my cookies...go a head, it wont help you much ;). I also try to set a rather low expire time for session <sessionState timeout="xxx"/>.
Do you have any other recommendations to help prevent such attacks?

[ashumiloff]

This may be a somewhat long tutorial but may prove beneficial in the long run...
http://www.asp.net/security/tutorials/security-basics-and-asp-net-support-cs

Here they go in great detail and talks about various methods, what if's, and so on.

I used this tutorial to build several different templates for various projects, now the bulk of the work is now done for any new projects

Oh, the above link points to C#, if you prefer VB the link is here:
http://www.asp.net/security/tutorials/security-basics-and-asp-net-support-vb