OWASP Top 10 Security Risks
OWASP Top 10 Security Risks
OWASP Top 10 Security Risks
When managing a website, it’s important to stay on top of the most critical security risks and
vulnerabilities. The OWASP Top 10 is a great starting point to bring awareness to the biggest threats to
websites in 2020.
What is OWASP?
OWASP stands for the Open Web Application Security Project, an online community that produces
articles, methodologies, documentation, tools, and technologies in the field of web application
security.
OWASP Top 10 is the list of the 10 most common application vulnerabilities. It also shows their risks,
impacts, and countermeasures. Updated every three to four years, the latest OWASP vulnerabilities list
was released in 2018.
Broken Authentication
Security misconfigurations
Insecure Deserialization
A code injection happens when an attacker sends invalid data to the web application with the intention
to make it do something that the application was not designed/programmed to do.
Perhaps the most common example around this security vulnerability is the SQL query consuming
untrusted data. You can see one of OWASP’s examples below:
This query can be exploited by calling up the web page executing it with the following URL:
http://example.com/app/accountView?id=’ or ‘1’=’1 causing the return of all the rows stored on the
database table.
The core of a code injection vulnerability is the lack of validation and sanitization of the data used by the
web application, which means that this vulnerability can be present on almost any type of technology.
Anything that accepts parameters as input can potentially be vulnerable to a code injection attack.
We’ve written a lot about code injection attacks. One of the most recent examples is the SQL injection
vulnerability in Joomla! 3.7.
Here is another example of an SQL injection that affected over half a million websites that had the YITH
WooCommerce Wishlist plugin for WordPress:
The SQL injection shown above could cause a leak of sensitive data and compromise an
entire WordPress installation.
If you have a tailored web application and a dedicated team of developers, you
need to make sure to have security requirements your developers can follow when
designing and writing software. This will allow them to keep thinking about security
during the lifecycle of the project.
Preventing SQL injections requires keeping data separate from commands and
queries.
• The preferred option is to use a safe API, which avoids the use of the interpreter
entirely or provides a parameterized interface or migrate to use Object Relational
Mapping Tools (ORMs). Note: Even when parameterized, stored procedures can still
introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or
executes hostile data with EXECUTE IMMEDIATE or exec().
• Use positive or “allowlist” server-side input validation. This is not a complete
defense as many applications require special characters, such as text areas or APIs
for mobile applications.
• For any residual dynamic queries, escape special characters using the specific
escape syntax for that interpreter. Note: SQL structure such as table names,
column names, and so on cannot be escaped, and thus user-supplied structure
names are dangerous. This is a common issue in report-writing software.
• Use LIMIT and other SQL controls within queries to prevent mass disclosure of
records in case of SQL injection.
Broken Authentication
A broken authentication vulnerability can allow an attacker to use manual and/or
automatic methods to try to gain control over any account they want in a system – or even
worse – to gain complete control over the system.
Websites with broken authentication vulnerabilities are very common on the web. Broken
authentication usually refers to logic issues that occur on the application authentication’s
mechanism, like bad session management prone to username enumeration – when a
malicious actor uses brute-force techniques to either guess or confirm valid users in a
system.
To minimize broken authentication risks avoid leaving the login page for admins publicly
accessible to all visitors of the website:
• /administrator on Joomla!,
• /wp-admin/ on WordPress,
• /index.php/admin on Magento,
• /user/login on Drupal.
The second most common form of this flaw is allowing users to brute
force username/password combination against those pages.
• Permits automated attacks such as credential stuffing, where the attacker has a list
of valid usernames and passwords.
• Permits brute force or other automated attacks.
• Permits default, weak, or well-known passwords, such as”Password1″ or
“admin/admin.″
• Uses weak or ineffective credential recovery and forgot-password processes, such
as “knowledge-based answers,” which cannot be made safe.
• Uses plain text, encrypted, or weakly hashed passwords.
• Has missing or ineffective multi-factor authentication.
• Exposes session IDs in the URL (e.g., URL rewriting).
• Does not rotate session IDs after successful login.
• Does not properly invalidate session IDs. User sessions or authentication tokens
(particularly single sign-on (SSO) tokens) aren’t properly invalidated during logout or
a period of inactivity.
• Credentials
• Credit card numbers
• Social Security Numbers
• Medical information
• Personally identifiable information (PII)
• Other personal information
Responsible sensitive data collection and handling have become more noticeable
especially after the advent of the General Data Protection Regulation (GDPR). This is
a new data privacy law that came into effect May 2018. It mandates how companies
collect, modify, process, store, and delete personal data originating in the European
Union for both residents and visitors.
SSL is the acronym for Secure Sockets Layer. It is the standard security technology
for establishing an encrypted link between a web server and a browser. SSL
certificates help protect the integrity of the data in transit between the host (web
server or firewall) and the client (web browser).
We have created a DIY guide to help every website owner on How to Install an SSL
certificate.
• The Brazilian C&A retail fashion retail clothing chain gift card platform cyberattack
that happened in August 2018.
• The Uber breach in 2016 that exposed the personal information of 57 million Uber
users, as well as 600,000 drivers.
• The Target store data breach that occurred around Thanksgiving exposing
credit/debit card information and contact information of up to 110 million people.
Not encrypting sensitive data is the main reason why these attacks are still so
widespread. Even encrypted data can be broken due to weak:
Most XML parsers are vulnerable to XXE attacks by default. That is why the responsibility of
ensuring the application does not have this vulnerability lays mainly on the developer.
What are the XML external entity attack
vectors?
According to the OWASP Top 10, the XML external entities (XXE) main attack vectors
include the exploitation of:
• Vulnerable XML processors if malicious actors can upload XML or include hostile
content in an XML document
• Vulnerable code
• Vulnerable dependencies
• Vulnerable integrations
• Whenever possible, use less complex data formats ,such as JSON, and avoid
serialization of sensitive data.
• Patch or upgrade all XML processors and libraries in use by the application or on
the underlying operating system.
• Use dependency checkers (update SOAP to SOAP 1.2 or higher).
• Disable XML external entity and DTD processing in all XML parsers in the
application, as per the OWASP Cheat Sheet ‘XXE Prevention.’
• Implement positive (“allowlisting”) server-side input validation, filtering, or
sanitization to prevent hostile data within XML documents, headers, or nodes.
• Verify that XML or XSL file upload functionality validates incoming XML using XSD
validation or similar.
• SAST tools can help detect XXE in source code – although manual code review is the
best alternative in large, complex applications with many integrations.
• Virtual patching
• API security gateways
• Web Application Firewalls (WAFs) to detect, monitor, and block XXE attacks
Broken Access Control
In website security, access control means putting a limit on what sections or pages visitors
can reach, depending on their needs.
For example, if you own an ecommerce store, you probably need access to the admin
panel in order to add new products or to set up a promotion for the upcoming holidays.
However, hardly anybody else would need it. Allowing the rest of your website’s visitors to
reach your login page only opens up your ecommerce store to attacks.
And that’s the problem with almost all major content management systems (CMS) these
days. By default, they give worldwide access to the admin login page. Most of them also
won’t force you to establish a two-factor authentication method (2FA).
The above makes you think a lot about software development with a security-first
philosophy.
• Scenario #1: The application uses unverified data in a SQL call that is accessing
account information:
pstmt.setString(1,request.getParameter(“acct”)); ResultSetresults
=pstmt.executeQuery( );
An attacker simply modifies the ‘acct’ parameter in the browser to send whatever
account number they want. If not properly verified, the attacker can access any
user’s account.
http://example.com/app/accountInfo?acct=notmyacct
• Scenario #2: An attacker simply force browses to target URLs. Admin rights are
required for access to the admin page.
http://example.com/app/getappInfo
• http://example.com/app/admin_getappInfo
Developers are going to be more familiar with the above scenarios, but remember
that broken access control vulnerabilities can be expressed in many forms through
almost every web technology out there; it all depends on what you use on your
website.
• Employ least privileged concepts – apply a role appropriate to the task and only for
the amount of time necessary to complete said task and no more.
• Get rid of accounts you don’t need or whose user no longer requires it.
• Audit your servers and websites – who is doing what, when, and why.
• If possible, apply multi-factor authentication to all your access points.
• Disable access points until they are needed in order to reduce your access
windows.
• Remove unnecessary services off your server.
• Check applications that are externally accessible versus applications that are tied to
your network.
• If you are developing a website, bear in mind that a production box should not be
the place to develop, test, or push updates without testing.
• Unpatched flaws
• Default configurations
• Unused pages
• Unprotected files and directories
• Unnecessary services
One of the most common webmaster flaws is keeping the CMS default configurations.
Today’s CMS applications (although easy to use) can be tricky from a security perspective
for the end users. By far, the most common attacks are entirely automated. Many of these
attacks rely on users to have only default settings.
This means that a large number of attacks can be mitigated by changing the default
settings when installing a CMS.
There are settings you may want to adjust to control comments, users, and the
visibility of user information. The file permissions are another example of a default
setting that can be hardened.
• Network services
• Platform
• Web server
• Application server
• Database
• Frameworks
• Custom code
• Pre-installed virtual machines
• Containers
• Storage
One of the most recent examples of application misconfigurations is
the memcached servers used to DDoS huge services in the tech industry.
• Scenario #1: The application server comes with sample applications that are not
removed from the production server.
These sample applications have known security flaws that attackers use to
compromise the server. If one of these applications is the admin console and
default accounts weren’t changed, the attacker logs in with default passwords and
takes over.
• Scenario #2: Directory listing is not disabled on the server. An attacker discovers
they can simply list directories. They find and download the compiled Java classes,
which they decompile and reverse engineer to view the code. The attacker then
finds a serious access control flaw in the application.
• Scenario #3: The application server’s configuration allows detailed error messages,
e.g. stack traces, to be returned to users. This potentially exposes sensitive
information or underlying flaws, such as component versions. They are known to
be vulnerable.
• Scenario #4: A cloud service provider has default sharing permissions open to the
Internet by other CSP users. This allows stored sensitive data to be accessed within
cloud storage.
How to Have Secure Installation Systems
In order to prevent security misconfigurations:
• A repeatable hardening process that makes it fast and easy to deploy another
environment that is properly locked down. Development, QA, and production
environments should all be configured identically, with different credentials used in
each environment. Automate this process in order to minimize the effort required
to set up a new secure environment.
• A minimal platform without any unnecessary features, components,
documentation, and samples. Remove or do not install unused features and
frameworks.
• A task to review and update the configurations appropriate to all security notes,
updates, and patches as part of the patch management process. In particular,
review cloud storage permissions.
• A segmented application architecture that provides effective and secure separation
between components or tenants, with segmentation, containerization, or cloud
security groups.
• Sending security directives to clients, e.g. Security Headers.
• An automated process to verify the effectiveness of the configurations and settings
in all environments.
Cross-Site Scripting (XSS)
Cross Site Scripting (XSS) is a widespread vulnerability that affects many web
applications. XSS attacks consist of injecting malicious client-side scripts into a
website and using the website as a propagation method.
The risks behind XSS is that it allows an attacker to inject content into a website and
modify how it is displayed, forcing a victim’s browser to execute the code provided
by the attacker while loading the page.
An XSS vulnerability gives the attacker almost full control of the most important software of
computers nowadays: the browsers.
Back in 2017, our research team disclosed a stored XSS vulnerability in the core of
WordPress websites. Remote attackers could use this vulnerability to deface a random post
on a WordPress site and store malicious JavaScript code in it.
Types of XSS
According to the OWASP Top 10, there are three types of cross-site scripting:
• Reflected XSS: The application or API includes unvalidated and unescaped user
input as part of HTML output. A successful attack can allow the attacker to execute
arbitrary HTML and JavaScript in the victim’s browser. Typically the user will need to
interact with some malicious link that points to an attacker-controlled page, such as
malicious watering hole websites, advertisements, or similar.
• Stored XSS: The application or API stores unsanitized user input that is viewed at a
later time by another user or an administrator. Stored XSS is often considered high
or critical risk.
• DOM XSS: JavaScript frameworks, single-page applications, and APIs that
dynamically include attacker-controllable data to a page are vulnerable to DOM
XSS. Ideally, the application would not send attacker-controllable data to unsafe
JavaScript APIs. Typical XSS attacks include session stealing, account takeover, MFA
bypass, DOM-node replacement or defacement (such as Trojan login panels),
attacks against the user’s browser such as malicious software downloads,
keylogging, and other client-side attacks.
• Using frameworks that automatically escape XSS by design, such as the latest Ruby
on Rails, React JS. Learn the limitations of each framework’s XSS protection and
appropriately handle the use cases which are not covered.
• Escaping untrusted HTTP request data based on the context in the HTML output
(body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS
vulnerabilities. The OWASP Cheat Sheet for XSS Prevention has details on the
required data escaping techniques.
• Applying context-sensitive encoding when modifying the browser document on the
client side acts against DOM XSS. When this cannot be avoided, similar context-
sensitive escaping techniques can be applied to browser APIs as described in
the OWASP Cheat Sheet for DOM based XSS Prevention.
• Enabling a content security policy (CSP) is a defense-in-depth mitigating control
against XSS. It is effective if no other vulnerabilities exist that would allow placing
malicious code via local file includes (e.g. path traversal overwrites or vulnerable
libraries from permitted content delivery networks).
Insecure Deserialization
Note: The OWASP Top 10 noted that this security risk was added by an industry survey and
not based on quantifiable data research.
Every web developer needs to make peace with the fact that attackers/security researchers
are going to try to play with everything that interacts with their application–from the URLs
to serialized objects.
In computer science, an object is a data structure; in other words, a way to structure data.
To make it easier to understand some key concepts:
• Scenario #1: A React application calls a set of Spring Boot microservices. Being
functional programmers, they tried to ensure that their code is immutable. The
solution they came up with is serializing user state and passing it back and forth
with each request. An attacker notices the “R00” Java object signature, and uses the
Java Serial Killer tool to gain remote code execution on the application server.
• Scenario #2: A PHP forum uses PHP object serialization to save a “super” cookie,
containing the user’s user ID, role, password hash, and other state:
a:4:{i:0;i:132;i:1;s:7:”Mallory”;i:2;s:4:”user”;
i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960″;}
a:4:{i:0;i:1;i:1;s:5:”Alice”;i:2;s:5:”admin”;
i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960″;}
One of the attack vectors presented by OWASP regarding this security risk was a super
cookie containing serialized information about the logged-in user. The role of the user was
specified in this cookie.
If an attacker is able to deserialize an object successfully, then modify the object to give himself
an admin role, serialize it again. This set of actions could compromise the whole web
application.
If you can’t do this, OWASP security provides more technical recommendations that you (or
your developers) can try to implement:
• Implementing integrity checks such as digital signatures on any serialized objects to prevent
hostile object creation or data tampering.
• Enforcing strict type constraints during deserialization before object creation as the code
typically expects a definable set of classes. Bypasses to this technique have been demonstrated,
so reliance solely on this is not advisable.
• Isolating and running code that deserializes in low privilege environments when possible.
• Logging deserialization exceptions and failures, such as where the incoming type is not the
expected type, or the deserialization throws exceptions.
• Restricting or monitoring incoming and outgoing network connectivity from containers or
servers that deserialize.
• Monitoring deserialization, alerting if a user deserializes constantly.
We can all agree that failing to update every piece of software on the backend and
frontend of a website will, without a doubt, introduce heavy security risks sooner rather
than later.
For example, in 2019, 56% of all CMS applications were out of date at the point of infection.
The question is, why aren’t we updating our software on time? Why is this still such
a huge problem today?
• Webmasters/developers cannot keep up with the pace of the updates; after all,
updating properly takes time.
• Legacy code won’t work on newer versions of its dependencies.
• Webmasters are scared that something will break on their website.
• Webmasters don’t have the expertise to properly apply the update.
This might be a little too dramatic, but every time you disregard an update warning,
you might be allowing a now known vulnerability to survive in your system. Trust
us, cybercriminals are quick to investigate software and changelogs.
Whatever the reason for running out-of-date software on your web application, you
can’t leave it unprotected. Both Sucuri and OWASP recommend virtual patching for
the cases where patching is not possible.
Virtual patching affords websites that are outdated (or with known vulnerabilities) to be
protected from attacks by preventing the exploitation of these vulnerabilities on the fly.
This is usually done by a firewall and an intrusion detection system.
Vulnerable Applications
Vulnerable applications are usually outdated, according to OWASP guidelines, if:
• You do not know the versions of all components you use (both client-side and
server-side). This includes components you directly use as well as nested
dependencies.
• The software is vulnerable, unsupported, or out of date. This includes the OS,
web/application server, database management system (DBMS), applications, APIs
and all components, runtime environments, and libraries.
• You do not know the versions of all components you use (both client-side and
server-side). This includes components you directly use as well as nested
dependencies.
• You do not fix or upgrade the underlying platform, frameworks, and dependencies
in a risk-based, timely fashion. This commonly happens in environments when
patching is a monthly or quarterly task under change control, which leaves
organizations open to many days or months of unnecessary exposure to fixed
vulnerabilities.
• The software developers do not test the compatibility of updated, upgraded, or
patched libraries.
• You do not secure the components’ configurations.
Not having an efficient logging and monitoring process in place can increase the damage of
a website compromise.
Here at Sucuri, we highly recommend that every website is properly monitored. If you need
to monitor your server, OSSEC is freely available to help you. OSSEC actively monitors all
aspects of system activity with file integrity monitoring, log monitoring, root check, and
process monitoring.
• Scenario #1: An open-source project forum software run by a small team was
hacked using a flaw in its software. The attackers managed to wipe out the internal
source code repository containing the next version and all of the forum contents.
Although source could be recovered, the lack of monitoring, logging, or alerting led
to a far worse breach. The forum software project is no longer active as a result of
this issue.
• Scenario #2: An attacker scans for users with a common password. They can take
over all accounts with this password. For all other users, this scan leaves only one
false login behind. After some days, this may be repeated with a different
password.
• Scenario #3: A major U.S. retailer reportedly had an internal malware analysis
sandbox analyzing attachments. The sandbox software had detected potentially
unwanted software, but no one responded to this detection. The sandbox had been
producing warnings for some time before detecting the breach due to fraudulent
card transactions by an external bank.
How to Have Efficient Website Monitoring
Keeping audit logs are vital to staying on top of any suspicious change to your
website. An audit log is a document that records the events in a website so you can
spot anomalies and confirm with the person in charge that the account hasn’t been
compromised.
Whatever the reason for running out-of-date software on your web application, you
can’t leave it unprotected. Both Sucuri and OWASP recommend virtual patching for
the cases where patching is not possible.
We know that it may be hard for some users to perform audit logs manually. If you
have a WordPress website, you can use our free WordPress Security Plugin to help
you with your audit logs. The plugin can be downloaded from the official WordPress
repository.
Vulnerable Applications
• Remote scanner
• Website blocklist scanner
• Server-side scanner
• DNS scanner
• Uptime scanner.