Netsparker Hawk is the infrastructure the Netsparker web application security scanner uses to detect Server Side Request Forgery (SSRF), and all other kinds of blind, asynchronous and second order vulnerabilities that require data to be sent over out-of-band channels.
Why Netsparker Hawk?
Most common types of SQL Injection, Cross-site Scripting and similar vulnerabilities can be detected fairly easily. The scanner sends a request to the target web application, and once it receives a response it analyses it to determine if the target is vulnerable or not. For example a typical SQL Injection vulnerability can be identified from an error message or content changes in the response, or the time the page takes to load.
However, not all vulnerability detection is as straightforward. For example, if the request sent to the web application is queued and processed by another block of asynchronous code, even if the code that's processing the input is vulnerable to SQL Injection there won’t be any error messages, content differences or time load differences in the response. To detect vulnerabilities like this, the scanner forces the code to respond via a different communication channel ('out-of-band'). Netsparker Hawk is the intermediary server (the different communication channel that will receive these signals). The scanner will communicate with it to confirm these types of vulnerabilities.
What Vulnerabilities Does Netsparker Hawk Detect?
Netsparker Hawk also finds vulnerabilities that benefit from out-of-band detection, or can be only detected with this way, including the following:
- Out-of-Band SQL Injection
- Out-of-Band Remote File Inclusion
- Out-of-Band Code Injection
- Out-of-Band Code Evaluation
- XML External Entity (XXE) Injection
- Server-side Request Forgery (SSRF)
- Blind Cross-site Scripting
How Does Netsparker Hawk Work?
This is how Netsparker works.
- During a web security scan, Netsparker generates a custom hash and uses it in the attack payload. For example, it sends the following request to the target web application:
- If the target web application is vulnerable, it tries to resolve the URL by contacting our DNS server.
- On receiving the request, the DNS server hashes it and sends it to the database server, together with the type of the request. For example:
- Next, the Netsparker scanner queries the Netsparker Hawk server, which checks with the database server for the hashed record.
- Once the scanner receives the hashed value, it applies the same hashing algorithm to the local data that the DNS server used. If both the hashes of the scanner and the DNS server match, it means that the target web application is vulnerable. Netsparker can confirm the vulnerability.
Security and Sensitive Data
Netsparker's dead accurate approach to finding and confirming vulnerabilities means that we are able to confidently confirm vulnerabilities. However, while using this approach, none of our servers log any sensitive data about vulnerabilities or about the target web application.