Software security abuse cases

As an attacker, I find and target old or weak cryptographic algorithms by capturing traffic and breaking the encryption. Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations.

As an attacker, I exploit vulnerable areas of the application where the user or system can upload XML to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks. As an attacker, I include hostile content in an XML document which is uploaded to the application or system to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks.

As an attacker, I include malicious XML code to exploit vulnerable code, dependencies or integrations to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack e.

Billion Laughs attack , as well as execute other attacks. Exploitation of access control is a core skill of attackers. Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks. As an attacker, I manipulate the primary key and change it to access another's users record, allowing viewing or editing someone else's account.

As an attacker, I force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user. As an attacker, I target default crypto keys in use, weak crypto keys generated or re-used, or keys where rotation missing is missing. As an attacker, I find areas where the user agent e. Attackers will often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories, etc to gain unauthorized access or knowledge of the system.

As an attacker, I find and exploit missing appropriate security hardening configurations on any part of the application stack, or improperly configured permissions on cloud services. As an attacker, I find unnecessary features which are enabled or installed e. As an attacker, I use default accounts and their passwords to access systems, interfaces, or perform actions on components which I should not be able to.

As an attacker, I find areas of the application where error handling reveals stack traces or other overly informative error messages I can use for further exploitation. As an attacker, I find areas where upgraded systems, latest security features are disabled or not configured securely. As an attacker, I find security settings in the application servers, application frameworks e.

Struts, Spring, ASP. NET , libraries, databases, etc. As an attacker, I find the server does not send security headers or directives or they are not set to secure values. Typically the victim will need to interact with some malicious link that points to an attacker-controlled page, such as malicious watering hole websites, advertisements, or similar. As an attacker, I perform stored XSS where the application or API stores unsanitized user input that is viewed at a later time by another user or an administrator.

Exploitation of deserialization is somewhat difficult, as off-the-shelf exploits rarely work without changes or tweaks to the underlying exploit code. As an attacker, I find areas of the application and APIs where deserialization of hostile or tampered objects can be supplied. As a result, I can focus on an object and data structure related attacks where the attacker modifies application logic or achieves arbitrary remote code execution if there are classes available to the application that can change behavior during or after deserialization.

Or I focus on data tampering attacks such as access-control-related attacks where existing data structures are used but the content is changed.

While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit. Misuse and abuse cases describe how users can misuse or exploit weak controls in software features to attack an application. A direct attack against business functionalities, which may bring in revenue or provide a positive user experience, can have a tangible business impact. Abuse cases can be an effective way to drive security requirements to properly protect these critical business use cases.

An online retailer plans to support an anonymous checkout and payment system whereby an anonymous user can enter a shipping address and payment details, place the order, and expect delivery without needing to create an account.

In the design, when a customer adds an item to their shopping cart, stock is reserved for that item. So if there were pairs of pants available, and someone adds a pair to their cart, there are now pairs of pants available for other customers. Organizations try to combat high load with auto-scaling, which leads to a secondary vector of attack—bankrupting a company with infrastructure costs. Oh, and people can also attack hard drive space too. There are plenty of load-testing tools that you can use, from the simple siege tool to the more complex WebLOAD, and more.

Remember, with abuse cases you are trying to break your app in as many ways you can think of. Developed at the University of Wisconsin, fuzzing is a technique where random input, pseudorandom input, or user behavior is applied to a system.

This technique is incredibly useful when it comes to helping you detect the unexpected. So here we have a much wilder and more random test of our simple function that tests random numbers between 1 and 1 million, 50, times in a row.

Note that another emergent property of fuzzing is that you end up testing properties of your code instead the direct results.

In the above example, the code tests:. Now our very simple example has become fairly interesting. Fuzzing has that effect on testing. You can even apply fuzzing at the system level with Selenium. Hacks can happen at every layer, so be prepared.