“After all, even the best-designed and most thoroughly audited web applications have far more issues, far more frequently, than their nonweb counterparts”. - Michal Zalewski in The Tangled Web
The following is a true story.
I was looking up future concerts at the Lincoln Center’s website and I was welcomed by the this page:
I (Me) then called the Lincoln Center Customer Service (CS).
CS: "Thank you for calling Lincoln Center...."
Me: "I'm glad that you have someone answer this call on Sunday. Your web site was hacked! When I browsed your homepage, it's directed to http://new.lincolncenter.org/live/ and the page was hacked”.
CS: "That’s alright. That is our new site”.
Me: "Sir, this is not right. Your website was hacked! Why don't you see for yourself..."
CS: "No, the website is fine”.
Me: "Sir, the page may be cached on your browser. Why don't you clear your browser cache and check your site again”.
CS: "Oh yeah. You're right. We got hacked”.
Me: "I think you should contact your IT and web administrator immediately. Have a good day. Bye”.
CS: "Thank you. Bye”.
Even Google captured the hack that day:
Websites are hacked everyday. With our daily life more and more relying on services on the internet, web application attacks becomes major concerns not only to the application hosts/owners, but also to the application users.
The Open Web Application Security Project (OWASP) is an international non-profit organization dedicated to improving security of web applications. Every three years since 2004, OWASP has published the Top 10 Project, the top 10 most critical web application risks worldwide. The most recent one is of 2013 and we expect an updated list in 2016. I summarized the previous Top 10 lists in the following table.
Interesting observation from the table above is that injection (no matter of SQL, OS, or LDAP) and cross-site scripting (XSS) have been among the top web application risks for years. The nature of the web applications probably contribute to the ease of hacking with these techniques. So, how do we detect and protect from the web application threats?
WILL IPS/IDS BE USEFUL?
No really. Web applications are of OSI Layer 7. While IPS/IDS do have some signatures for web application attacks, in general IPS/IDS are of up to OSI Layer 4. IPSs can be placed as the first line of defense and block the threatening traffic, but they don’t understand web application protocol logic, URLs, or parameters.
WEB APPLICATION FIREWALL (WAF)?
WHAT ABOUT THE DEVELOPERS?
From the OWASP Top 10 lists above, many risks can be considered as developers’ responsibility to secure the applications. Web developers are trained better in securing the codes; for example, the number 1 2004 risk, Unvalidated Input, fell out of the list in recent years. But I think we still have a long way to go for having developers with sound security mindset. I swear that I saw web applications requiring authentication ran on port 80 (HTTP)!
How does your organization detect and mitigate web application threats? Do you deploy or manage WAF? Is it a tough job to keep up with the web applications? How much thoughts do your web developers put when they build the applications? Do they have thoughtful security testings?
I would like to hear from you.
Lastly, I would like to point out that the IBM Security Systems Ethical Hacking team prepared a series of videos a series of videos based on the OWASP Top 10 2013 list. Beware of the marketing of IBM AppScan. But the videos show good examples of those top 10 web application attacks.