Complete Guide to Using Wapiti Web Vulnerability Scanner to Keep Your Web Applications & Websites Secure

Globally, there are roughly 30,000 web-based cyberattacks daily, primarily targeting smaller businesses and smaller websites. To put it into perspective, that is an estimated 1 cyberattack every 3 seconds that targets websites specifically.

Cybercriminals will not hesitate to attack your website, so how can you possibly find any security issues and entry points? The answer is simple: Website Vulnerability Scanners. Follow along with us as we take a look at what a Vulnerability Scanner is and how we use WAPITI Web Scanner to test some websites. 

What is a Website Vulnerability Scanner? Do YOU Need It?

Before we get into WAPITI Scanner, let's define a Website vulnerability and how a Website Vulnerability Scanner can help you. A website vulnerability is a flaw or vulnerability in the code of a website or web application that allows cybercriminals to gain control of the site and possibly even the web hosting server. Cybercriminals have gone so far as to write scripts that scrape the web for specific platforms in search of familiar and publicized vulnerabilities that they can exploit to steal information, access confidential documents or data, spam the site, or even inject scripts. If these attacks are successful, cybercriminals can cause irreparable damage to a business's hardware and public image, as well as raise questions about whether that company has the resources to keep their data secure, as well as the data of potential future clients.

Understanding and preventing website vulnerabilities is especially important for any business or corporate institution that maintains or plans to maintain a website or web application. A website vulnerability scanner is designed to look for these security flaws in a website. It searches for flaws in web services and web servers. Because cybercriminals are quick to exploit these vulnerabilities, you should be implementing regular use of a web scanner as well. Routine web vulnerability testing will allow you to patch security flaws before cyber attackers can manipulate them. These scanners simply examine the application's code for web flaws like SQL injections, cross-site scripting (XSS), and path traversal.

Wapiti Scanner: Brief Description

Wapiti gives you the ability to audit the security of your web apps. It performs "black-box" scans, which means it does not examine the application's source code but instead scans the deployed web app's webpages for scripts and forms into which it can inject data. Wapiti then acts like a fuzzer, injecting payloads to see if a script is vulnerable.

Watch: Wapiti Web Vulnerability Scanner - Review + Test

Wapiti Features

Main Scanning Features:

SQL Injections (Error based, boolean-based, time-based) and XPath Injections

SQL Injection is a type of injection attack that makes it possible to execute malicious SQL statements that can control a database server behind web applications. Attackers can use SQL Injection vulnerabilities to bypass application security measures. Scanning for SQLi vulnerabilities is a must to make sure that important information is not accessed and to furthermore, be able to reinforce your server to mitigate SQL injection attacks.

XPath injections are attacks where malicious user input can be used to grant unauthorized access or reveal sensitive information such as XML document structure and content. These attacks are carried out by making the user's input be used in the construction of the query string. XPath Injection scans check how your server handles malicious XPath queries. If the scan does not return information on vulnerabilities, it will be considered secure.

Cross-Site Scripting (XSS) reflected and permanent

Cross-site scripting targets an application's users by injecting code, usually a client-side script such as JavaScript, into a web application's output. The concept of XSS is to manipulate client-side scripts of a web application to execute in the manner desired by the attacker. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface websites or redirect the user to malicious sites.

Cross-Site Request Forgery (CSRF) basic detection

Cross-Site Request Forgery is a malicious attack where a user is tricked into performing an action he or she didn't intend to do. A third-party website will send a request to a web application that a user is already authenticated against (e.g. their bank). The attacker can then access functionality via the victim's already authenticated browser. Targets include web applications like social media, in browser email clients, online banking, and web interfaces for network devices.

CRLF Injection

CRLF injection attacks are one of several types of injection attacks. It can be used to extend more malicious attacks such as cross-site scripting, page injection, cache poisoning, and cache-based tampering. A CRLF injection attack occurs when Cyber Criminals are able to inject CRLF characters into a web application. The most common use for CRLF injection attacks is log poisoning, where the Cyber Criminal forges log file entries which ultimately, can be used to hide other attacks or confuse system administrators. Although CRLF isn’t amongst the most commonly known web vulnerabilities, it is still a big threat. Due to the fact that CRLF injections are used to hide and escalate possibly stronger and potentially more dangerous attacks, it is best to use a scanner to help mitigate the exploitation of this vulnerability.

XXE (Xml eXternal Entity) injection

An XML External Entity attack is an attack that abuses a widely available but rarely used feature of XML parsers. Using XXE, Cyber Criminals are able to cause Denial of Service attacks on top of being able to access local and remote content and services. XXE can be used to perform Server Side Request Forgery forcing the web application to make requests to other applications. Furthermore, XXE may even enable port scanning and lead to remote code execution. There are two types of XXE attacks: in-band and out-of-band. Cyber Criminals can use XML entities to cause a denial of service by embedding entities within entities within entities.

Other Scanning Features:

• File disclosure detection (local and remote include, require, fopen, readfile...)
• Command Execution detection (eval(), system(), passtru())
• Search for potentially dangerous files on the server
• Bypass of weak htaccess configurations
• Search for copies (backup) of scripts on the server
• Shellshock
• Folder and file enumeration
• Server Side Request Forgery
• Open Redirects
• Detection of uncommon HTTP methods
• Basic CSP Evaluator
• Brute Force login form
• Checking HTTP security headers
• Checking cookie security flags
• Fingerprinting of web applications using the Wappalyzer database
• Enumeration of Wordpress and Drupal modules
• Subdomain takeovers detection
• Log4Shell (CVE-2021-44228) detection

Wapiti supports both GET and POST HTTP methods for attacks. It also supports multipart and can inject payloads in filenames. Furthermore, Wapiti displays a warning when an anomaly is found which makes the difference between permanent and reflected XSS vulnerabilities.

How to Install Wapiti for Linux Distributions:

With root permission, update the apt database with apt-get using the command:

root@server:~# apt-get update 

Kali Linux and Ubuntu Installation:

root@kali:~# apt-get install wapiti 

Debian Installation:

root@debian:~# apt -y install wapiti

UNIX-like Systems Installation:

Prerequisites: Packages must be updated and Python must be installed. Run the command

apt-get install python3 OR apt-get install python

Let's grab the most recent Wapiti tar file from their page using this command below:

root@kali:~# wget githubusercontent 

Lets extract the tar file from our download using this command below: 

root@kali:~# tar  -xzvf  wapiti3-3.1.2.tar.gz 

Extracting the tar file will create a directory in the directory in which you downloaded and extracted the tar file. Below, lets change to that directory using the cd command: 

root@kali:~# cd wapiti3-3.1.2/

We should now be in the wapiti3-3.1.2 directory. If we run the ls command, we should see the contents of the directory: 

root@kali:~/wapiti3-3.1.2# ls

Bin INSTALL.md MANIFEST.in README.rst setup.py wapiti3.egg-info

Doc LICENSE    PKG-INFO    setup.cfg  VERSION  wapitiCore

We should now be able to install Wapiti by running the command python3 setup.py install just like below:

root@server:~/wapiti3-3.1.2# python3 setup.py install

Wapiti Help:

For this instance, I used Kali Linux. Run the command wapiti -h to pull up a list of arguments that wapiti accepts. 

Wapiti in Action:

For this instance, I will be using Kali Linux. Let’s use Wapiti to test Two sites, one that is generally considered secure and one that is vulnerable. Run the command below, substituting the proper url:

root@kali:~# wapiti -v2 -u https://monsterhost.com/promo/

Google.com Test:

For this example, we ran this command against Google. This is what wapiti will output:

As you can see in the example above, we ran wapiti in verbose mode and it generated a report in html format. We use open /path/to/file to open the html file in a web browser. Below is what that looks likes:

From this generated report, we see that we have a possible vulnerability with Content Security Policy Configuration. As you can see, the issue is with our CSP which helps mitigate and detect attacks such as XSS. Keep following along below to see the solution wapiti returns:

The solution above is provided by wapiti. Rather than a solution, it is more of a highly recommended suggestion that you can choose to heed or not. Configuring our CSP would allow for better deterrence of attacks.

HTTP Flag Cookie:

In the image above, we also see that we receive a vulnerability with the HTTPOnly Flag cookie. The HttpOnly flag is not set to true in this instance. Setting it to true will help mitigate the risk of client side scripts accessing protected cookies.

Secure Headers Error:

In the image above, we also see that we receive a vulnerability stating it is an HTTP Secure Headers Error. Modern browsers support many HTTP headers that can improve web application security to protect against clickjacking, cross-site scripting, and other common attacks. Wapiti refers to some links that will help in hardening your web applications.

Mutillidae Test:

For this example, we ran this command against Mutillidae, a deliberately vulnerable web application. Whilst running, wapiti will show you real-time the tests it is running like below:

In the image above, whilst wapiti was running tests, it found an XSS Vulnerability. In the image below, it found a SSRF vulnerability:

When wapiti is all finished with its scans, this is what it will output:

As you can see in the example above, we ran wapiti in verbose mode and it generated a report in html format. We use open /path/to/file to open the html file in a web browser. Below is what that looks like:

From this generated report, we see that we have possible vulnerabilities with Content Security Policy Configuration. As you can see, the issue is with our CSP which helps mitigate and detect attacks such as XSS. Keep following along below to see the solution wapiti returns:

 The solution above is provided by wapiti. Rather than a solution, it is more of a highly recommended suggestion that you can choose to heed or not. The CSP is not set; configuring our CSP would allow for better deterrence of attacks.

Path Traversal:

A path traversal vulnerability allows Cyber Criminals to access files on your web server to which they should not have access. They do this by tricking either the web server or the web application running on it into returning files that exist outside of the web root folder. Using code access policies and chrooted jails along with using file path code to prevent users from entering the full path, we can fix thesen vulnerabilities.

HTTPOnly Flag Cookie:

In the image above, we also see that we receive a vulnerability with the HTTPOnly Flag cookie. The HttpOnly flag is not set to true in this instance. Setting it to true will help mitigate the risk of client-side scripts accessing protected cookies as shown in the solution below:

Secure Headers Error:

In the image above, we also see that we receive a vulnerability stating it is an HTTP Secure Headers Error. Modern browsers support many HTTP headers that can improve web application security to protect against clickjacking, cross-site scripting, and other common attacks. Wapiti refers to some links that will help in hardening your web applications like below:

SQL Injection (SQLi):

SQL injection attacks allow CyberCriminals to spoof identity, tamper with existing data, destroy the data or make it otherwise unavailable, and possibly, even become administrators of the database server. Scanning for possible SQLi vulnerabilities will help prevent your database from possibly taking over. As you can see above, Wapiti even provides us with a solution: User input must not directly be embedded in SQL statements. Instead, user input must be escaped or filtered or parameterized statements must be used. Depending on the company, getting this information to the proper team is essential to get it resolved.

Server Side Request Forgery (SSRF):

Solution:

SSRF allows attackers to carry out scans and collect information about internal networks. Once an attacker has gained access to the server, they can use this information to compromise other servers within the network. Quite a few breaches within the past couple years such as Capital One and MS Exchange have all included SSRF attacks.

SSRF vulnerabilities allow CyberCriminals to send requests from the back-end server of the web application and they do this to target internal systems that are behind firewalls and are not accessible externally. Scanning against SSRF will aide in mitigating these attacks and hopefully, keeping your system secure. Wapiti provides us with a solution as shown above. The more frequently you scan, the closer we are to avoiding another Capital One-like instance.

Cross-Site Scripting (XSS):

Solution:

Cross-site scripting works by manipulating a vulnerable website so that it returns malicious JavaScript to users. Cybercriminals can fully compromise users interaction with web applications by executing this malicious Javascript code/scripts. The way to ensure that you, your users, and your web app are safe is to ensure that the application does checking and validation of headers, cookies, query string, forms, and hidden field. Moreover, encoding user output can help mitigate these types of attacks.

Wapiti Summary

Wapiti is a well-known tool that is widely used amongst security researchers, regular users, and even System Administrators. As Cyber Criminals continue to exploit new found vulnerabilities and even existing ones due to poor security management, Wapiti is the perfect solution to auditing your website and webservers. The commands and arguments are fairly simple to use, it is a powerful tool, and the report provided in HTML format allows for any user to see urgent issues and their possible solutions without having to sit, search, and create a solution. It provides you with a baseline understanding of your vulnerabilities and a baseline path to a solution.

Our Thoughts

Web applications are the technological base of modern companies. That’s why more and more businesses and corporate institutions are looking to monitor their websites and web apps more often and wapiti is the perfect tool to do so. It is amongst many well-known web vulnerability scanners and can play an essential role in assisting daily users and System Administrators alike to deter attacks. 

We hope you found this article useful! Be sure to stay tuned for more tips and advice on Linux security tools.