The real advantage that defenders have over malicious hackers is having the internal knowledge about their system, specifically access to their internal source code. While designing and implementing security solutions, it is crucial to keep that in mind.

1. 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

2. 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

3. 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

4. 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
Azrieli Towers, Round Building - 22nd floor
132 Menahem Begin St., Tel-Aviv, ISRAEL
Tel: +972-3-7581800