There's no concise way of outlining how to test business logic for security flaws. Every application is unique...
in this regard. It's not unlike trying to tell a racecar driver how to go fast. With the numerous variables involving the car, the track, and the racer's driving style and mental state, it's a complex situation with no single good answer. Instead, there are a lot of small things that must be done -- and tested -- that will add up to an improved race craft, faster lap times and, in this case, more secure applications.
When it comes to vulnerable application logic, here are some areas I often discover as being weak and exploitable:
- User provisioning and password change processes that can be manipulated.
- Initial logins and how the application and workflow are presented to the user may allow for unauthorized access if the user simply hits "Esc" or clicks the back button in the Web browser.
- Order and data entries that can be manipulated for ill-gotten gains.
- Search queries that return interesting information that leads to different parts of the application that were otherwise unknown.
- Directory enumeration for a logged-in user can uncover areas of the application that are actually publicly accessible (and can be exploited from the outside without a user ever logging in once it's discovered).
- Role or privilege escalation that can be exploited by merely knowing where to go within the application.
- Session hand-offs to separate (often third-party) applications that disclose how the authentication and session management work.
- File upload areas that facilitate the spreading of malware on unprotected servers.
As you can see, much of this involves core application security principles such as authentication, access control, session management and input validation. It's really all related, but uncovering many business logic flaws takes a special way of thinking and a special eye that can look at the bigger picture.
Other things to consider when testing for business logic flaws:
- Whether or not workflows and processes can be automated and then attacked using vulnerability scanners and scripts.
- Testing both with and without user authentication. (You can often uncover publicly exploitable weaknesses that might otherwise go unnoticed to a logged-in user.)
- Audit or exception logging and how anomalies are being monitored and addressed.
Application logic flaws can be detrimental to a business, and there's hardly a firewall or IPS system (including those that monitor layer 7) that will protect you from these types of exploits. It's something that needs to be tested for in your ongoing security assessments and penetration tests at least once per year or after any significant code changes.
Dig Deeper on Software Security Test Best Practices
Related Q&A from Kevin Beaver
Android Oreo replaced the allow unknown sources setting with a new feature that enables users to selectively install unknown apps. Kevin Beaver ...continue reading
Several vulnerabilities were recently discovered in Android bootloaders via the BootStomp tool. Kevin Beaver explains how they work and what risk ...continue reading
Equifax's Apache Struts vulnerability was an example of a scan not being read correctly. Kevin Beaver explains vulnerability scans and how issues can...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.