Getting started with Web application misuse cases

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.

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 development team and see how you build on these scenarios and integrate them into your projects early on.

1. Exploit server misconfigurations. Many people overlook this, believing that the server is an IT or security operations issues. That may be so, but it still affects your application's well-being. For example, the server may not be properly hardened or is missing a patch that can be exploited in order to gain a leg up or even penetrate the system. This testing can be done manually, but I prefer to automate the process where possible using tools such as QualysGuard and LANguard Network Security Scanner. What can you find? What's even remotely exploitable, such as that FTP server your application uses?
2. Crack system authentication mechanism. This is about as straightforward as misuse gets. Set up a scenario where you check your logins both manually and in an automated fashion using a tool such as Brutus. Analyze errors returned when both incorrect user names and incorrect passwords are entered. Also check to see how the lockout mechanism works. How it can be defeated?
3. Analyze data in transit for weaknesses. Step through and look at traffic types and protective mechanisms. Look at the SSL version. Are you running SSL version 2 that can be cracked? Perhaps the application is not using SSL everywhere. Of the data in transit that's not encrypted, create a scenario where data is captured off the wire using a good network analyzer such as OmniPeek or CommView. What can be done with that data? What other communications sessions are being opened up to/from the application. Can they be exploited?

Learn more about misuse cases and how to think like an attacker Threat modeling enhanced with misuse cases Software security testing: Finding your inner evildoer Want secure software? Think like an attacker

4. Enter junk data into form fields and URLs. This is another straightforward but fun scenario to setup. For example, you could send attack requests using an automated scanner such as WebInspect, Acunetix Web Vulnerability Scanner or N-Stalker Web Application Security Scanner. What's accepted? Can you determine what's being returned by the application or submitted client side that could be manipulated for ill-gotten gains? What can be prodded further? Can you manually enter a single character or even 500-plus characters into a field? How do the application and server behave?
5. Exploit user registration logic. Set up a scenario where you're a new "malicious" user of the application. Could you set yourself up in a way that could escalate privileges? Is the user name already taken? If so, can that be something to misuse in item #2 above? Can you set up multiple user accounts tied to the same email address? Does the application send an email or other message to the user? What's contained in the message -- sensitive information that could be abused by a third party or system configuration information such as internal IP addresses that the user doesn't need to know about? What happens if you reply to the message?
6. Mask identity to cover tracks. This tests your system's monitoring and incident response capabilities. For example, you could send attack requests using an automated scanner via a proxy host and then analyze your log data. Would it be easy to evade system monitoring and tracking? How can this be abused by an insider or outsider trying to hide his true identity? A neat use case for this is to inject code into HTTP responses from the application such as JavaScript to determine the actual IP address of the intruder. It's sort of a reverse cross-site scripting (XSS) attack.

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.

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.