Vulnerability Scanning
Created bymhmdiaa-trickest
Last updated8/12/2024

Input Parameters

​
urls
file
List of URLs
​
header
string
Header(s) to include in HTTP requests
​
in-scope
file
List of URLs, paths, or regular expressions to include in scanning
​
rate-limit
string
Maximum number of requests to send per second per machine
​
header-file
file
Header(s) to include in HTTP requests
​
url-details
file
JSONLines records of URL and request details
​
out-of-scope
file
List of URLs, paths, or regular expressions to exclude from scanning

Outputs

findingssitemap

​
Fuzz Web Applications for Vulnerabilities

​
Description

Scan for vulnerabilities in web applications actively by crawling the app, fuzzing inputs, and reporting insecure behaviors and potential security flaws.

​
Features

  • Scans for a wide range of vulnerabilities by actively injecting payloads and analyzing responses.
  • Crawls the web application before and after payload injection to discover endpoints and detect stored vulnerabilities.
  • Automatically switches to headless browser crawling when necessary.
  • Can scan thousands of web applications simultaneously.

​
Inputs

​
Required

  • urls: List of URLs
https://foo.example.com
https://bar.example.com

​
Optional

  • exclude-urls: List of URLs, paths, or regular expressions to exclude from scanning
https://foo.example.com/profiles?id=.*
/admin
  • header: Header(s) to include in HTTP requests
  • header-file: File with header(s) to include in HTTP requests
  • rate-limit: Maximum number of requests to send per second per machine (default: 300)

​
Outputs

  • findings: JSONLines records of finding details.
{"finding": "Cross Site Scripting (Reflected)", "location": "https://foo.example.com/products?category=%0A%0D%0A%0D%3CscrIpt%3Ealert%281%29%3B%3C%2FscRipt%3E", "hostname": "foo.example.com", "domain_name": "example.com", "severity": "high", "method": "GET", "field": "category", "attack": "\n\r\n\r<scrIpt>alert(1);</scRipt>", "description": "Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.", "matches": ["<scrIpt>alert(1);</scRipt>"]}
{"finding": "Vulnerable JS Library", "location": "https://bar.example.com/resources/js/angular_1-7-7.js", "hostname": "bar.example.com", "domain_name": "example.com", "severity": "medium", "method": "GET", "description": "CVE-2023-26116\nCVE-2022-25869\nCVE-2022-25844\nCVE-2024-21490\nCVE-2020-7676\nCVE-2023-26117\nCVE-2019-10768\nCVE-2023-26118\n", "matches": ["/*\n AngularJS v1.7.7"]}

​
Changelog

  • v1.0.0
    • Initial release
  • v1.1.0
    • Improved the finding description field to include more relevant information.
    • Resolved an issue where a scan rule for detecting proxy misconfigurations was generating false positives.
  • v1.2.0
    • Added header-file input
  • v2.0.0
    • Added automatic validation for SQL injection vulnerabilities using single-threaded, high-accuracy checks
    • Added detection of file upload forms as informational findings
    • Improved headless crawling to better support JavaScript-heavy dynamic applications
    • Added url-details input to allow passing non-GET endpoints with custom bodies; enables integration with the Analyze JavaScript Code module
    • Added sitemap output to export the dynamically accessed sitemap in a format compatible with ZAP Messages