The pros and cons of modern web application security flaws and possible solutions

Table of Contents

Abstract

Acknowledgement

1. Introduction

2. Background
2.1. Application Security Risks

3. Conclusions

Bibliography

Abstract:

Modern web applications have higher user expectations and greater demands than ever before. The security of these applications is no longer optional; it has become an absolute necessity. Web applications contain vulnerabilities, which may lead to serious security flaws such as stealing of confidential information. To protect against security flaws, it is important to understand the detailed steps of attacks and the pros and cons of existing possible solutions. The goal of this paper is to research modern web application security flaws and vulnerabilities. It then describes steps by steps possible approaches to mitigate them.

Acknowledgements:

We would like to thank everyone who has contributed in some way to this work.

Firstly, we would like to thank USA and its staff for making this learning experience possible. We would like to specially acknowledge all the lecturers and assistants who have participated in different courses of the MSc. Computer Science Program, including the students I’ve had the opportunity to work with. The diversity of backgrounds and the participation of both on-campus and distance students have made this learning journey very enriching.

Secondly, we would like to express our sincere gratitude to Md. Tomig Uddin Ahmed for being the supervisor of this work.

Lastly, we would like to thank my family for their support and especially recognize our friends Abdullah and Emran Karim for their interesting comments and discussions.

1. INTRODUCTION:

Web applications are computer programs those utilize web browsers and web technology to form tasks over the Internet [13].

illustration not visible in this excerpt

Figure-1: How web application works

Millions of businesses use the Internet as a cost-effective communications channel. It lets them exchange information with their target market and make fast, secure transactions. However, effective engagement is only possible when the business is able to capture and store all the necessary data, and have a means of processing this information and presenting the results to the user.

Web applications use a combination of server-side scripts (PHP and ASP) to handle the storage and retrieval of the information, and client-side scripts (JavaScript and HTML) to present information to users. This allows users to interact with the company using online forms, content management systems, shopping carts and more. In addition, the applications allow employees to create documents, share information, collaborate on projects, and work on common documents regardless of location or device.

Web applications must be secure, flexible, and scalable to meet spikes in demand. [14] As with any new class of technology, web applications have brought with them a new range of security vulnerabilities. The set of most commonly encountered defects has evolved somewhat over time. New attacks have been conceived that were not considered when existing applications were developed. Some problems have become less prevalent as awareness of them has increased. New technologies have been developed that have introduced new possibilities for exploitation. Some categories of flaws have largely gone away as the result of changes made to web browser software.

[14] The most serious attacks against web applications are those that expose sensitive data or gain unrestricted access to the back-end systems on which the application is running. High-profile compromises of this kind continue to occur frequently. For many organizations, however, any attack that causes system downtime is a critical event. Application-level denial-of-service attacks can be used to achieve the same results as traditional resource exhaustion attacks against infrastructure. However, they are often used with more subtle techniques and objectives. They may be used to disrupt a particular user or service to gain a competitive edge against peers in the realms of financial trading, gaming, online bidding, and ticket reservations.

Throughout this evolution, compromises of prominent web applications have remained in the news. There is no sense that a corner has been turned and that these security problems are on the wane. By some measure, web application security is today the most significant battleground between attackers and those with computer resources and data to defend, and it is likely to remain so for the foreseeable future.

In particular, this topic focuses on 10 modern and significant web security pitfalls to be aware of, including recommendations on how they can be mitigated. The focus is on the Top 10 Web Vulnerabilities [1] identified by the Open Web Application Security Project (OWASP), an international, non-profit organization whose goal is to improve software security across the globe.

2. BACKGROUND:

Insecure web application is undermining our financial, healthcare, defense, energy, and other critical infrastructure. As our application becomes increasingly complex, and connected, the difficulty of achieving application security increases exponentially. The rapid pace of modern web application development processes makes the most common risks essential to discover and resolve quickly and accurately. We can no longer afford to tolerate relatively simple security problems like those presented in this OWASP Top 10 [1].

2.1 Application Security Risks

Attackers can potentially use many different paths through application to do harm to business or organization. Each of these paths represents a risk that may, or may not, be serious enough to warrant attention [15].

illustration not visible in this excerpt

Figure-2: Flow of application security risks

Sometimes these paths are trivial to find and exploit, and sometimes they are extremely difficult. Similarly, the harm that is caused may be of no consequence, or it may put you out of business. To determine the risk to the organization, you can evaluate the likelihood associated with each threat agent, attack vector, and security weakness and combine it with an estimate of the technical and business impact to the organization. Together, these factors determine your overall risk.

Common web application vulnerabilities can be classified into three types: Injection Vulnerabilities, Business Logic Vulnerabilities and Session Management Vulnerabilities. The following diagram shows a classification of several types of attacks that are commonly used to exploit each type of vulnerability [12].

illustration not visible in this excerpt

Figure-3: Web application vulnerabilities classification

Injection Vulnerabilities: An injection occurs when an attacker sends untrusted data as part of an apparently legitimate command or query in order to trick the interpreter of the application and execute unintended commands. Most common types of injections are SQL injection, Cross Site Scripting (XSS) and LDAP injection.

Business Logic Vulnerabilities: Business Logic Vulnerabilities allow malicious attackers to manipulate the legitimate logic of the application and execute illegitimate transactions. These vulnerabilities are usually exploited by modifying parameters, bypassing authentication and authorization constraints and violating the normal flow of an application.

Session Management Vulnerabilities: Session Management Vulnerabilities allow attackers to read or manipulate session variables that are used to keep the state of web applications (e.g. state that a user is logged into the application and has certain authorization rights). Session hijacking and fixation attacks target on the session ID of the user whereas Cross Site Request Forgery (CSRF) and click jacking aim the client’s browser to submit requests that the legitimate user would not want to submit.

The OWASP Top 10 document [16] [17] is commonly referenced when mentioning the most common web application security flaws. The document describes the 10 most common flaws based on data collected from hundreds of organizations and over 50,000 applications and APIs, and it classifies them based on their prevalence and consensus estimates of exploitability, detectability and impact. The OWASP Top 10 document also gives mitigation recommendations aiming to help developers and organizations to better protect their applications. The OWASP Top 10 2013 and 2017 documents classify the top most common flaws into 10 categories that are summarized below.

illustration not visible in this excerpt

Table-1: OWASP Top 10 2017 security flaws

The 2017 version merges previous A4 and A7 categories into a renamed “A4 - Broken Access Control” category, drops the “Invalidated Redirects and Forwards” category and introduces 2 new categories: “A7- Insufficient Attack Protection” and “A10- Under protected APIs”. It is significant to note that the top three categories remain unchanged (Injection, Broken Authentication and Session Management and Cross Site Scripting (XSS) and they keep being considered as the three most important web application security flaws according to the OWASP nonprofit organization.

Information about the OWASP web application flaws categories is summarized below.

Injection:

[2] An application is vulnerable to attack when:

- User-supplied data is not validated, filtered, or sanitized by the application.
- Dynamic queries or non-parameterized calls without context aware escaping are used directly in the interpreter.
- Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.
- Hostile data is directly used or concatenated, such that the SQL or command contains both structure and hostile data in dynamic queries, commands, or stored procedures.

Some of the more common injections are SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection. The concept is identical among all interpreters. Source code review is the best method of detecting if applications are vulnerable to injections, closely followed by thorough automated testing of all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs. Organizations can include static source (SAST) and dynamic application test (DAST) tools into the CI/CD pipeline to identify newly introduced injection flaws prior to production deployment.

Example:

Scenario #1: An application uses untrusted data in the construction of the following vulnerable SQL call:

String query = "SELECT * FROM accounts WHERE custID-” + request.getParameter(”id”) + ;

Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g. Hibernate Query Language (HQL)):

Query HQLQuery = session.createQuery(”FROM accounts WHERE custID-'” + request.getParameter(”id”) + ”'”);

In both cases, the attacker modifies the ‘id’ parameter value in their browser to send: ' or '1'='1. For example:

http://example.com/app/accountView7id-' or '1'='1

This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify or delete data, or even invoke stored procedures.

Prevention: Preventing injection 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 "whitelist" 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: [3] Confirmation of the user's identity, authentication, and session management are critical to protect against authentication-related attacks. There may be authentication weaknesses if the application:

- 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 "Password 1” 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 (see A3:2017-Sensitive Data Exposure).
- 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.

Example:

Scenario #1: Credential stuffing, the use of lists of known passwords, is a common attack. If an application does not implement automated threat or credential stuffing protections, the application can be used as a password oracle to determine if the credentials are valid.

Scenario #2: Most authentication attacks occur due to the continued use of passwords as a sole factor. Once considered best practices, password rotation and complexity requirements are viewed as encouraging users to use, and reuse, weak passwords. Organizations are recommended to stop these practices per NIST 800-63 and use multi-factor authentication.

Scenario #3: Application session timeouts aren’t set properly. A user uses a public computer to access an application. Instead of selecting “logout” the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and the user is still authenticated.

Prevention:

- Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks.
- Do not ship or deploy with any default credentials, particularly for admin users.
- Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords.
- Align password length, complexity and rotation policies with NIST 800-63 B's guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence based password policies.
- Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
- Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
- Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts.

Sensitive Data Exposure: [4] The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly

[...]