Knowledge Center

Static on Computer Screen

Why you instead of static code analysis?

Static code analysis tools provide good value when tuned to remove false positives. This means tailoring the configuration to the application, over time. They are excellent at flagging certain types of flaws during the application's deployment flow. They do well at spotting server-side injection flaws like SQLi and command injection. Most of them check dependencies for known security issues. It’s a great idea to use static analysis tools. They have significant gaps, which make them inadequate on their own. Here are a few main areas where they are not very effective:

Static Analysis tools don’t understand context

There are many flaws that are reliant on context. Take cross-site request forgery (CSRF) for example. CSRF is a way of sending an authenticated request without the user knowing. It only works if the attacker can predict valid values for all required inputs. It's also important to note if the form interaction is sensitive at all. Meaning, if forging this request actually has a meaningful impact. Both are critical elements to assessing CSRF potential. Most static analysis tools only check for missing framework-level anti-CSRF measures.

Another weakness that requires context to detect is clickjacking. A clickjacking attack is where an attacker hides a part of the vulnerable application's UI under an unrelated page. This can prompt the user to click a button, without knowing it is even there. For example, the victim browses to a page that says: “Congratulations, you won a $25 gift card, click here to claim it”. When the victim clicks, they don't realize they are clicking a button on a different form. For this example, let's say it's a form to submit a Bitcoin transfer request. A static analysis tool may tell you that your site is frameable, or missing headers. A penetration tester should be able to show if an attacker could exploit it, and why that matters.

Static Analysis tools cannot infer business rules

Consider an application that has four roles: Employee, Supervisor, Manager, and Administrator. Their permissions are in that order, from least-privileged to most-privileged. Any user can invite or promote other users to any role that is lower than their own. Managers can invite Supervisors and Employees. Supervisors can only invite Employees. Employees cannot invite anybody. These are logical business rules. Understanding the hierarchy of these roles, you would infer that a Supervisor should not be able to invite a person to be an Administrator. This would represent a path to privilege escalation. Any tester looking at the application would attempt that. Static analysis tools will not generally be able to identify if there are flaws in the business rules or how they are being enforced. They’re often common sense to a human, but impractical to identify via static analysis.

Back to the

Knowledge Center

Didn't answer

your question?