Vladislav Kochelaevs - Fotolia
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 Topics Archive
Related Q&A from Kevin Beaver
Explore the differing roles of inbound versus outbound firewall rules for enterprise network security and the varying use cases for each. Continue Reading
Compare host IDS vs. network IDS through the pros and cons of each, and learn how more modern systems may be better suited to ensure effective ... Continue Reading
Different tools protect different assets at the network and application layers. But both network and application security need to support the larger ... Continue Reading