Azrieli Towers, Round Building - 22nd floor 132 Menahem Begin St., Tel-Aviv, ISRAEL Tel: +972-3-7581800

The Advantages of SAST – WAF Correlation The fact that it is easier to hack than protect is no secret. For example, attackers need to find a single

point of entry, whereas the defender needs to close all holes. As most of you know, defenders usually

work under tight time and budget constraints, while the attacker has no such limitations. He has full

discretion to decide how much effort, time and money he wants to put into hacking your system.

This asymmetric situation is unfair. The only way for defenders to break this asymmetry is by using the

information they have and the attacker doesn’t. The real advantage of the defenders is having internal

knowledge about their system, specifically having access to their internal source code. While designing

and implementing security solutions, it is crucial to keep that in mind.

This is especially true for WAF configuration and virtual patching. WAF are known to be very solid

solutions after being properly configured. They do great work in the process of virtual patching, by

shortening the window of the vulnerability(the time between the discovery of a security breach and the

time it is closed). This is accomplished by either fixing the code (real patch) or by giving appropriate

commands to the WAF (virtual patch)

In this paper, I will try to show several examples from different security realms of how source code

analysis can produce better WAF rules. You will see that dynamic analysis input will prove inferior

compared to SAST. We take advantage of the only puzzle piece that we have and neither Dynamic

simulators nor hackers have, the sources.

Azrieli Towers, Round Building - 22nd floor 132 Menahem Begin St., Tel-Aviv, ISRAEL Tel: +972-3-7581800

Example: SQL Injection Once a DAST tool identifies a SQL Injection, it knows exactly what page and field is vulnerable. It then

sends the information to the WAF, which creates a generic anti-SQL Injection virtual patch (for example,

the following Regex “[^’]*” – “any character but quote”). A SAST tool can tell exactly what field in the

query receives the input, and build a custom filter (“\d*” for an integer type). This lowers radically the

FP and FN ratio of the WAF (for integer types, an attack can take place without using a quote).

Figure 1 -Numeric field SQL Injection

Generalization DAST tool usually provides “black-list” patches (what values are forbidden), whereas SAST tools provide

“white-list” ones (what values are valid). White-listing is always the preferred method of validating

inputs, as attacker can easily find a way to encode their attack in a way that bypasses black lists.

Figure 2-ThreadFix SQL Injection Virtual Patch DAST->WAF rule. Blacklists malicious patterns. Fails for numeric fields.

Azrieli Towers, Round Building - 22nd floor 132 Menahem Begin St., Tel-Aviv, ISRAEL Tel: +972-3-7581800

Figure 3-ThreadFix rules. Blacklists malicious patterns

Example: Log Forgery \ Command Injection Log Forgery is an attack which invalidates the system’s log files by allowing the attacker to write tainted

values, therefore making these files untrustworthy. This is considered as a major breach of compliance

regulation where enterprises need to be accountable for their audit trails.

Command Injection takes advantage of application flow where user input is transformed into an OS

command and gets executed, for example erasing system files.

These kinds of attacks take place in the backend of the system and have no external exposure; hence

they can hardly be detected by DAST tools. In this case, DAST tools can’t create a WAF rule.

Generalization DAST can detect vulnerabilities that have external sources or consequences (UI, network). They can’t

find issues that only have a backend influence

Example: Hardcoded debug code, hidden pages & time sensitivity In cases where the developers mistakenly left a debug code, which gets executed only when using a

magic “keyword”, DAST tools can’t guess this keyword and remain unaware of this breach. A SAST tool

can easily detect these kinds of vulnerabilities. This also correlates to time-based attacks, where the

system is exposed to a security risk only at a specific time (nightly batch job). DAST will detect this only if

it is run at that very moment. The same issue exists for “hidden” pages, which are not linked from the

main site. A DAST solution will not be able to find these either.

Generalization The SAST solution outperforms the DAST solution in detecting vulnerabilities that are out of the

standard application flow.

Azrieli Towers, Round Building - 22nd floor 132 Menahem Begin St., Tel-Aviv, ISRAEL Tel: +972-3-7581800

Coverage When a DAST tool detects an issue, it can tell what page and field are vulnerable. This information is

only the tip of the iceberg in the sense that it cannot correlate that finding with other similar findings

along this path. SAST’s backtracking capabilities allows setting multiple rules for multiple input points,

based on a single finding.

Summary

SAST advantages over DAST

Create white lists versus black lists

Find issues in the backend

Identify vulnerable leftover information

Systematic coverage of the full vulnerability path

SAST challenges vs. DAST

Requires access to the application sources

Has to correlate sources to URL