Are you finding all possible vulnerabilities and addressing them?
Editor’s note: This article has been updated to reflect the OWASP
Top 10 Application Security Risks – 2017 list.
Web applications are at the forefront of the cloud computing revolution,
and steadily replacing the traditional OS-stacked desktop applications. It is easy to understand why, as web
browser-based applications are universally accessible in a world where
global customers and the company workforce carry connected mobile devices
in their pockets that can instantly use them. Web apps are proven to be
far more cost effective to develop, quicker to release, and easier to
maintain than the applications of old. And their constant network
connectivity allows for real-time data, enabling far greater application
functionality and management capabilities than ever before.
Today’s modern, cloud-powered web apps are limitless in their sophistication
and power, and are increasingly providing essential functions within
businesses and our personal lives. Whether online banking, making a doctor’s
appointment, filing a tax return, or booking a vacation, web apps are at
the very forefront in providing essential services and managing
confidential, financial, and personal data records. Which is why it is imperative for
modern applications to be resilient and secure.
“Vulnerabilities are created when developers either
make coding errors or do not grasp the importance of using robust coding
Given the increasing sophistication of web apps, developing code is now more complicated than ever before. The more
complicated the code and sophisticated the application functionality,
the greater the risk of coding flaws that can then cause security vulnerabilities.
Application vulnerabilities face exploitation by relentless groups of
malicious actors: Cyber criminals who are bent on profiteering from data theft and
blackmail; hacktivists who seek to cause organizations’ reputational
damage, havoc and self notoriety; and even nation-states that covertly spy and
cause mass outages to essential services. The cyber threat steadily grew
in recent years, and hardly a day goes by now without a major
hack or data breach in national media headlines.
The data that is managed by applications is subject to a growing number of
stringent privacy laws and regulations, whether the European Union’s
General Data Protection Regulation, PCI DSS, Financial Conduct Authority,
or Sarbane-Oxley—all carry significant financial sanctions for any data
compromise that’s caused by weak application security.
Web app security
From the moment a web application is made available online until the day it
is taken offline, it is open to constant attacks. Whether
specifically targeted by an individual or group, or by randomly automated
malicious ‘bots,’ expect every aspect of an online web app to be
continually probed for security weakness. Assuring the application’s
security is essential prior to its release and on an ongoing basis
Securing the network layer (hosting) of web apps is a well-trodden path and
is a fairly straightforward process to achieve and continually assure with
regular patching and monitoring. However, a network firewall has little
effect in securing a web application, and hackers know the Achilles Heel
of online security weakness is at the application layer. Application
vulnerabilities that are caused by coding errors and weak coding techniques
continue to be regularly exploited by hackers and were the cause of
many of the largest data breaches in recent times.
In September 2017, Equifax announced that hackers stole 145 million of its
customer records. Hackers exploited a known security weakness in the
Equifax’s web-application hosting platform. In October 2015, UK telecom
company TalkTalk had 157,000 customer records stolen via a web application
SQL injection attack orchestrated by teenage hackers. This serious data
breach was reported to have cost TalkTalk over £42 million and the loss of
100,000 customers, and resulted in a public £400,000 fine by the UK’s
privacy watchdog. In March 2008, Heartland Payment Systems had 134 million
credit card details stolen by a hacker, again due to the exploitation of
web application vulnerabilities through SQL injection attacks.
Neglecting web app security can rock the largest enterprise to the smallest
business (and individual) down to the core. Website defacements can lead to embarrassing
media coverage and reputational damage, but it is often mass personal data
theft that proves the most costly and detrimental to organizations.
Customer data loss typically means facing the full brunt of negative media
scrutiny, followed by legal repercussions, and regulatory sanctions that can run into the
millions of dollars and even cause a sharp drop in share price. And there
are the many hidden costs of mopping up after an attack, forensic
investigations, system and application outage time, and the frantic
recoding of the web app—which all come with a high price tag. Prevention
is vastly more cost effective than trying to cure active application security
failings. And adhering to software development best
practices, such as those listed in the OWASP Top 10, will significantly
reduce your risk of being susceptible to successful cyber attacks.
Bad code is the root cause of most web
The majority of data breaches lies within the application code
that is written by developers. Vulnerabilities are created when developers either
make coding errors or do not grasp the importance of using robust coding
techniques. For instance, writing code that sanitizes input field values
to only allow the application to accept and process the expected
characters. This is a simple enough coding technique, but if missed can allow an attacker to take advantage of an input field to execute a SQL
database instruction. The hacker can then return the entire database of customer
information, including names, email addresses, and even credit card
numbers. Such vulnerabilities are easy pickings for cyber criminals, as
they can quickly monetize the information on the underground markets of
the dark web. To avoid damaging security flaws, software developers need
to understand the security risks and be instructed on how to write secure
code where necessary, and applications must be robustly tested for the
present of application layer vulnerabilities.
OWASP Top 10 — Web app security
The Open Web Application Security Project
(OWASP) is an open source community, formed in 2001 that freely
produces guidance on application security risks. OWASP maintains the OWASP
Top 10, a list that identifies the most critical application security
risks. The list is regarded as industry best practice in preventing web
app vulnerabilities, and is referenced by major security organizations and
security regulations, such as PCI DSS, FTC, MITRE, and most web
app-penetration testing providers.
The OWASP list is ordered by the most critical vulnerability type first,
and the list is updated on a 3-4 year cycle, with the latest Top 10
list that was released in November 2017. While the OWASP list does not include all
application vulnerabilities, the Top 10 vulnerabilities that are listed
by OWASP are by far the most common application failings that are
currently exploited by malicious cyber criminals.
Injection flaws are always one of the most critical and commonplace
security vulnerabilities for web applications. So it is no surprise that injection tops
the OWASP list. There are various injection flaw types, but by far
the most infamous is SQL injection, which has been successfully exploited
by hackers for well more than a decade. SQL injection involves an attacker
appending SQL database commands within an input field. If the web
application code does not sanitize the input, it can allow SQL commands
to be executed on the web server, allowing an attacker to bypass network
DMZ security, and directly interrogate the back-end database. With SQL
injection, an attacker is able to return and steal tables of information,
change records, or even delete the entire database.
Example of a simple SQL injection
The following example was performed against a vulnerability-testing website
from IBM: http://www.altoromutual.com. The company, Altoro Mutual, is
fictitious, but the attack method that’s demonstrated is real and is one of the
most common techniques that are used by hackers to steal web application-controlled
data on mass. See the following figure below.
The example web app provides a function to allow a user to list
transactions between specific dates. The date input field does not
sanitize the value entered, so it is vulnerable to a SQL injection attack.
The following input value injects a command that returns the contents of
the database fields, including account user names and passwords:
1/1/2010 union select userid,null, username+' '+password,null from users--.
Figure 1. Web app returning data following
The first part of the entered value in the field is the date, which is the
expected value by the application. This ensures that the application
processes the date data together with the rest of the injected command.
Following the date the term “union” signals the start of the SQL command.
It is essentially saying “Here is the expected date and ….” Through
trial and error, the attacker is able to work out the name of the
user account table, called
users, and the number of fields
within the user’s table. The attacker then uses this information to write
select command, which instructs the return of record data
from the user’s table. The table information, including account user names
and passwords, is displayed within the web page’s transaction form.
This is a basic example of SQL injection. In the real world, injection
attacks are far more sophisticated, with hackers using specialist
tools, helping them automate their attacks.
2. Broken authentication and session
The second most critical vulnerability on the 2017 OWASP list relates to how the
web application authenticates and protects each user web session. There
are several potential vulnerabilities with authentication and session
management if not managed correctly by the application; one of the most
common is session hijacking.
An attacker may seek to steal (hijack) a web session by learning a victim’s
secret session ID. Knowing a user’s session ID can allow an attacker to
impersonate the user’s authenticated connection with the web server, and
to compromise the user’s account. If the web app manages session IDs
poorly, such as displaying a session ID within a URL instead of using a
cookie, it can be a fairly simple for an attacker to swipe the session ID
by tricking the user.
to obtain session IDs directly from the user’s locally stored cookie
files, by tricking users into running covert scripts. A simple script can
reveal the session ID stored within a cookie — for example, typing
the following script in a vulnerable search field reveals the session ID:
Figure 2. A sample script can reveal a session ID stored in
Secure coding techniques and modern developer frameworks can be used to
beef up application authentication and session management. These include
combining the source IP address of the user with the session ID and
requiring user re-authentication before allowing any changes to key
account details, such as changes to passwords and email addresses. Changes
like these are a common first action by hackers upon hijacking a web
session, but forcing re-authentication terminates the hijacked session
— a simple coding technique to reduce risk.
Terminating sessions after a timed period of user inactivity is another
simple coding technique that should not be overlooked. For example, once a
user hits a time limit of five minutes of website inactivity, the
application terminates the session, forcing the user, and any attacker, to
re-authenticate when they want to continue. This is another simple measure
that reduces the risk of session hijacking and is a technique you will
experience with most online banking web apps.
3. Sensitive data exposure
Sensitive information, such as personally identifiable information (PII), medical
data, and financial records, must be safeguarded by the application to
prevent data theft and malicious modification, and unintentional
unauthorized access and accidental modification. Applications should be
designed and developed to utilize robust access control management and
industry-recognized encryption algorithms with encryption key management
functionality, to ensure sensitive data is protected while in transit and
while at rest, including when data is exchanged between the application
and a user’s web browser.
To ensure applications are developed with the appropriate level of security
and functionality to prevent sensitive data exposure within the Software
Development Lifecycle’s design stage, include a sensitive data impact
Sensitive data impact
A sensitive data impact assessment starts with documenting and evaluating
all the data that is intended to be accessed and processed by the application, and
then assigning a data type classification (such as personal data, financial
data). Following this, the application’s security controls and functions
should be reviewed by a subject matter expert for each data classification
identified. For instance, if the application is intended to process
PII, the review should involve either a Data
Privacy Officer or a data protection legal expert to ensure the
application’s security controls and measures complies with data protection
laws—which, in the case of data protection, varies from
country to country.
Application testing is the other key element in preventing sensitive data
exposure, using application security vulnerability scanning tools, such as
IBM Rational AppScan, will help to ensure the application does not
expose any sensitive data.
4. XML external entity (XXE)
Applications that accept XML are at risk of injection attacks, if the
XML parser not sanitize and validate the externally provided XML input.
Such injection attacks can lead to the disclosure of sensitive data,
denial of service attacks, server-side request forgery, remote code
execution, and even be used to perform network port scanning of the
application hosting server.
To prevent XXE attacks, disable XML external entity and DTD processing on
all parsers that are used by the application, and use “whitelisting” input
validation, filtering or sanitization—this will prevent maliciously
injected XML code that is processed by the application when placed within
XML documents and headers by attackers.
It is also essential to ensure the latest XML processors, libraries, and
SOAP used by the application are patched to the latest versions available.
Updated versions of software and libraries are regularly released by
vendors to resolve newly discovered security flaws. Attackers are aware
of the organizations that do not patch their systems proficiently and are quick
to act in taking advantage of newly discovered vulnerabilities.
Deploying a Web Application Firewall (WAF) to block malicious XML input can
provide an additional level of defense in preventing XXE attacks.
5. Broken access control
Access control security weakness can lead to the unauthorized disclosure,
editing, and deletion of sensitive data. User authentication is not enough to prevent a lower-level privileged user from gaining higher-level
privileged account functions and unauthorized access to sensitive data.
Poor design or misconfiguration of data objects, such as file, directory,
and database key, can result in lower-privilege users being able to bypass
application access controls by changing parameter values to directly refer
In the following example in the figure below, we see a broken access
control attack. After
the attacker successfully authenticates with the application by using a
low-level privilege user account, the attacker changes the URL reference
and is able to access the application’s administration page.
Figure 3. Broken access control example
Attackers attempt to access privileged account functions by guessing the
calls of the application’s higher functions and URLs, and often automate
such attacks by using scripts.
Developers can safeguard against such attacks by ensuring access control
checks are invoked with all user access to objects. Setting permissions to
all non-public resources to “deny all” by default. And ensuring web server
directory listings are locked down and metadata is not present at the web
server’s root directory. ”
6. Security misconfiguration
Security misconfiguration can occur with any of the web application
components and dependencies, including with the platform (operating
system), web server (Struts, APS.NET), libraries, and databases. Common
issues include leaving unnecessary services running, not changing the
default administrator credentials, and not adequately restricting server
directory listings and file permissions from public access. A favorite of
hackers is the mishandling of error messages by applications.
Figure 4. Error messages provide hackers with vital clues
Not disabling application error messages provides an attacker with the
information to better understand the application and database structure,
which in turn aids an attacker in their trial-and-error hacking approach.
In the example, the error message that is returned by the application informs the
hacker the name of the table is correct, but the number of table fields
guessed within the SQL injection command was incorrect. Therefore, the
hacker keeps guessing the number of database fields with additional SQL
commands by using a script until the error message confirms a correct guess.
Now the attacker knows the name of the table and the number fields it has,
the attacker can perform more sophisticated SQL injection commands to
steal or change the data within the table.
In addition to disabling all error messages, ensure all components that are
with web application hosting are hardened and regularly patched.
Use a network vulnerability scanning service and web application
vulnerability scanner to check that the application-hosting environment remains
7. Cross-site scripting (XSS)
Cross-site scripting (XSS) is another common web app attack that has been
around for many years. If a web app is vulnerable to XSS, an attacker can
introduce a malicious script within a web page, which executes once the
page is accessed by visitors.
XSS attack example
In this example, the web application provides the visitor with the ability
to post a question or comment about company products. The comments field
is vulnerable to XSS. The example text comment
(This is a great product <script>document.write('<img
inserts an XSS script onto the page, which will attempt to steal each
visitor’s session ID.
In the example, the comment field allows the insertion of HTML code. After
the comment is posted, the text comment and the XSS code are appended into
an html of the product’s website.
Figure 5. Example review comment that inserts an XSS script
onto a web page
Visitors to the product’s website would then observe the comment “This is a
great product,” but have no sight of the malicious HTML script, which is
executed by their web browser and sends the user’s cookie information
(including the session ID) to the attacker’s website, “evilsite.” The
attacker can use the stolen session ID to hijack the victim’s web session
and to compromise the user’s account. Attackers use such tactics to enable
them to steal sessions from thousands of user accounts at a time.
By default, most modern browsers protect against XSS attacks. For instance,
Explorer defaults in a protection mode, which prevents XSS
scripts from executing when present in website pages. However, XSS still
remains a serious application vulnerability, given that some users are
still using outdated web browsers.
8. Insecure deserialization
Serialization is the process of converting an application object state into
binary data or text data, and deserialization is opposite process,
creating an object state from binary data or text data. The function is
used by applications to allow object states to be efficiently shared or
stored. However, the deserialization process can be taken advantage of by
hackers, by creating malicious deserialized objects that can cause remote
code execution and data tampering upon serializing by the application.
Distributed applications and APIs that use object serialization from
untrusted sources are particularly prone to deserialization attacks.
To prevent deserialization attacks, the application should be configured to
not accept any deserialized input from untrusted sources, or to only use
serialization mediums with primitive data types. If those measures are not
possible, enforce constraints types during deserialization ahead of object
creation, run deserialization in low privilege environments, such as
temporary containers and restrict network connectivity to servers that
deserialize. Hostile object creation and data tampering can also be
prevented by using encryption or integrity checks such as digital
9. Using components with known
All web applications rely on various software components that are developed and
provided by third parties, both open source and commercial. It is
important to document all third-party software components that are used by the
application in a software asset list, which includes the software version
number. Then implement a procedure to continually monitor vendor websites
and software vulnerability alerting sources, such as CVE & NVD, for
notifications of new security vulnerabilities and for releases of new
versions or patches that address security vulnerabilities.
For instance, the OpenSSL library is an open source web application
component used to manage many website’s encrypted sessions (https). In
April 2014, several versions of the OpenSSL library were identified as
having a critical security vulnerability: CVE-2014-0160, referred to as
the Heartbleed bug. Organizations that use a documented software asset list
and monitoring vulnerability-alerting services, were quickly aware
of the Heartbleed vulnerability, and instantly knew whether or not any of
their web applications were using a vulnerable version of OpenSSL. They
were then able to take quick actions to upgrade to secure versions of
Ensuring that third-party web app components are free from known vulnerabilities
requires a continued process of monitoring for notification of new
security vulnerabilities and new releases of security patches and a
program of regular vulnerability scanning.
10. Insufficient logging and
A sufficient level of logging and monitoring ensures that organizations are
quickly informed and can react to cyber attacks against the application,
whether they are successful or not.
“If logging and monitoring is
inadequate, attacks can go undetected for days, months, and in some cases
Avoiding detection allows attackers to steal larger volumes of
data and gives them the time to experiment with more sophisticated and
damaging attacks. Detection avoidance also means that stolen data maintains at
a higher value to cyber criminals, as data owners are unaware their
data was compromised and they are unable to adopt counter measures or
provide warnings to help prevent stolen data and account credentials
Enabling a thorough and detailed level of system audit logging provides
essential intelligence for incident response and forensic investigations.
Audit events are centrally aggregated, analyzed, and filtered with
smart-automated monitoring tools that provide incident-response and management
teams with the intelligence to quickly detect and understand the causes of
security incidents, and to rapidly contain and defend against a cyber
attack in real time.
In additional to applications, it is also important to ensure APIs are
monitored for suspicious activity.
The following measures are recommended with audit logging:
- Use a separate and dedicated security-hardened server-platform to
capture and store audit log events. Use either syslog or a commercial
audit logging solution to centrally store, anaylze, and monitor audit
- Use network time synchronization technology, Network Time Protocol
(NTP), to ensure all system clocks on all servers, including the audit
log server, are continually maintained to the exact same time. This
provides an accurate timeline of events when analyzing audit logs
collated from multiple systems—this is key information for incident
investigators. It also allows sophisticated automated monitoring tools
and intrusion detection/prevention systems to spot cyber attacks by
analyzing patterns of events that occur across multiple systems in real
- Ensure the audit log tool and server uses strong access control based
on a job-related need, as attackers, which may well include
maliciously minded internal staff, often attempt to alter or delete
audit logs to hide their actions.
- Enable and capture audit log events to include all:
- Successful and failed access to systems, data and
- Input validation events.
- Error messages.
- Changes to the system configuration.
- High-value transaction events.
- Successful and failed access to systems, data and
- Each audit log event should detail:
- A user account identification where possible.
- The type of event.
- A time and date the event occurred.
- A success or failure indication.
- The origin and identity of any data or system component
- Network layer details where possible (source & destination
IP addresses, ports used).
- Keep audit log events for at least one year, and have at least three
months of audit data kept immediately available to aid rapid incident
Consider the following measures with security alert monitoring:
- Prepare to respond to cyber attacks by creating a formal incident
response plan, by doing the following:
- Document each member of the incident management team’s
responsibilities and contact details. Ensure that team members
are familiar with their expected duties within the team.
- Document the incident response procedures for specific types
of cyber attacks.
- Ensure any potential business impact and losses due to
security incidents are kept to a minimum by regularly risk-assessing business resilience. Include business recovery and
continuity procedures as part of the incident response plan
and test regularly.
- Test the incident response plan and the incident management
team’s ability on a regular basis by simulating various cyber
- Ensure “lessons are learned” from all test simulations and
actual incidents, and update the incident response plan
- Document each member of the incident management team’s
- Given web applications are “24/7” in nature, and attacks can occur at any
time, designate specific personnel to be available on a “24/7” basis to
monitor and to respond to security alerts.
- Use an alert-monitoring tool to automatically analyze and communicate
alerts by email and/or SMS to the designated alert-monitoring staff.
- Determine the types of security events and alerts, which will generate
staff alert notifications, and will require responsive staff action.
Make time to baseline the audit log events and then set the
appropriate thresholds for generating alerts when suspicious
activities are detected. Ensure that alerts are notified and responded to
by staff within an acceptable time period.
- Regularly verify the log monitoring analysis and alert thresholds, and
the communications channels used for alerts.
Avoiding unnecessary costs in web
application vulnerability mitigation
Developing and releasing web applications with vulnerabilities is expensive
and time consuming. Even fixing a single line of code post-release can
equate to hundreds of hours of labor in rewriting and retesting. Testing
and resolving code vulnerabilities early within the application
development lifecycle is the most efficient and cost-effective method.
Using third-party penetration testing has its place in proving the web app
is secure, but using penetration testing and subsequent retesting as a
process to find and mitigate web app code vulnerabilities is
time consuming and a needless expense.
“Vulnerabilities should be weeded
out much earlier in the software development cycle. When developers go
wrong with secure coding, they need to be properly educated to ensure that
such errors are not repeated. ”
The average penetration test report provides
very little education for developers and code writers.
AppScan concisely explains any web app vulnerability it finds, including
providing the full details of the actual test it conducted to find the
vulnerability — a degree of detail seldom found in a penetration
test report. AppScan is particularly helpful when it comes to explaining
vulnerabilities to developers, educating those who write the code using
simple text explanations and video tutorials, and even providing examples
of code developers can copy to resolve the vulnerability. This level of
information and assistance to developers not only helps them better
understand the importance of web app security but it educates developers
to code better, reducing the likelihood of future vulnerabilities within
the web app.
Ensuring web app security
AppScan has extensive reporting capabilities and comes with various
industry-standard, application vulnerability report types, which can be used to
provide evidence and assurance that a web app is
Analysis reports can prove web app vulnerability fixes,
while reports against the OWASP Top 10 and PCI DSS demonstrates the
security of developed web apps to auditors and customers.
Underestimating the importance of web app security is a ticking cyber time
bomb. A single web app vulnerability can cause a monumental
data breach that can shake even the largest of businesses down to its
foundation, leading to worldwide negative media headlines, hefty financial
penalties, and the loss of public trust. Investing in assuring the
security of web applications by adopting industry best app-development
practices, like the OWASP Top 10, and using web app vulnerability scanning
tools is an essential software development