When is the last time you thought long and hard about how your application can be misused and abused by an attacker? Going beyond the commonly used Web security controls of SSL, managed code and stored procedures, you can -- and should -- develop scenarios revolving around breaking your application. Rather than outlining what a system should do (as with use cases), "misuse" cases outline what can be done to the system. It's sort of an inverse set of requirements for the system -- what NOT to have.
As with standard use cases, always take into consideration every actor of the system in your misuse case. In other words, don't just assume you're always going to have an external attacker trying to break in. You very likely have trusted users trying to abuse their privileges as well. Not only do you want to look at your application from an insider's point of view, but you want to include all possible levels of user roles. By doing it this way, you can say you've covered all your bases the next time a customer or business partner sends you that ever-dreaded security questionnaire.
Figure 1 outlines the common areas of Web application weaknesses I come across in my work. Your mileage may vary, but at least focus here first and then consider other models such as the OWASP Top 10.
[TABLE]Figure 1:Critical areas for misuse cases
Rather than simply doling out yet another tutorial on writing good misuse cases, how about some examples of application abuse goals you can build on? These are actual Web application weak spots that no one can afford to overlook. Mull them over with your
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
development team and see how you build on these scenarios and integrate them into your projects early on.
With all of your misuse cases, be sure to consider alternate ways the attack can be carried out. For example, using form field and hidden field tampering in addition to a URL manipulation attack. Or, try logging in with the same user account more than once from different systems. How does this change the behavior of the application? Can it be misused?
Misuse cases are as much of a mindset as they are a software development technique. The more you step inside an attacker's mind and determine what can be exploited through behavioral sequences from every reasonable angle, the better off you'll be. You'll not only beef up your system requirements -- which is reason enough to do this exercise -- but you'll also end up with more secure applications that are less prone to abuse. That's something that'll prove to be invaluable when the next security assessment rolls around.
-----------------------------------------
About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC where he specializes in performing independent security assessments. Kevin has authored/co-authored six books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels blog and information security audio books providing security learning for IT professionals on the go. Kevin can be reached at kbeaver@principlelogic.com.
