Businesses are constantly “shifting left” and taking advantage of the innovative customer and employee experiences delivered by cloud-driven applications. At the same time, malicious perpetrators are also continually revising their attack strategies to suit this shift.
To preserve data privacy and security, it is imperative that businesses seek protection against these 22 common web application vulnerabilities.
-
Damaged access control
Access controls are responsible for how users interact with resources and data, as well as what they can edit and/or read. A faulty access control vulnerability is possible when the user is able to engage the data in a manner that is really unnecessary. For instance, if the user should only be capable of reading payment details but actually has the ability to edits them, such a situation exemplifies a broken access control. Malicious attackers take advantage of this vulnerability to obtain unauthorized access to software, networks, and systems. They can then exploit the situation, grant the user ID more access within the infrastructure, to compromise data availability, confidentiality, or integrity.
-
Damaged authentication
Web application vulnerabilities associated with damaged or broken authentication also stem from user access. In this case, however, malicious attackers negatively impact the data that confirms the identity of a user, such as through hijacking session tokens, keys, or passwords. The malicious attacker obtains unauthorized access to the software, systems, and networks because the organization was unable to properly set adequate identity and access management controls.
-
Carriage Return and Line Feed (CRLF) Injection
Carriage return acts as a command which denotes the beginning of a line of code, typically indicated as /r. Line feed on the other hand is a command which denotes the end of a line of code, typically indicated as /n. Like several other software, each operating system utilizes varying combinations of carriage return and line feed. When malicious attackers are involved in CRLF injections, the inputted code alters the manner in which the web application reacts to commands. This may be used to either disclose sensitive data or execute code.
-
Cipher transformation insecure
Cipher, which is a standard term for “encryption algorithm”, is actually the mathematics behind an encryption or decryption process. Transformation refers to the outline of operations carried out on input to deliver the expected output. Thus, a cipher transformation refers to the number of operations that covert unreadable encrypted data back to readable, decrypted data. A cipher transformation insecure vulnerability describes that the encryption algorithm can be easily broken, ultimately sabotaging the essence of encryption in the first instance.
-
Components with obvious vulnerabilities
Every web application depends on other components to function. For instance, if you are operating an application on an unpatched web or application server, the server is the part with obvious vulnerabilities. The Common Vulnerabilities and Exposures (CVE) list comprises all known security vulnerabilities. Because malicious attackers have knowledge of the list, they frequently seek components without adequate security patch updates. The moment they can infiltrate one component of the web application, they can obtain access to the data of the application, as well.
-
Cross-Origin Resource Sharing (CORS) Policy
All web-based applications make use of a URL as a medium of connecting the user’s browser to its server. The Same Origin Policy is one common protection. In line with this, the server will respond to only a URL with the same protocol, path schema, and top-level domain name. What this means is that you can access http://organization.com/page1 and http://organization.com/page2 because they both share the following:
- Protocol: HTTP
- Domain: Company.com
- Path schema: /page#
While it is secure, the Same Origin Policy is restrictive when dealing with web-based apps that require access to resources that connect to third parties or subdomains.
A CORS policy grants the browser permission to view these interrelated resources by establishing a number of permitted HTTP headers regarded to be “trusted”. For instance, an application might have to draw data from two databases on separate web servers. Drafting a particular “allowed” list becomes excessive work as you include additional servers. Since both servers are “sharing” the application, the company writes a CORS policy that allows browsers to connect to both. If a CORS policy is, however, not properly defined, then the policy may let the servers to grant access when requested by a malicious attacker.
-
Credentials management
User credentials comprise a user ID and passkey. The user has to supply both items of information into the login page before access to an application is obtained. However, databases tend to use weak encryption or keep information in plaintext. Poor credentials management allows attackers to easily steal credentials and exploit them to obtain access to web applications.
-
Cross-site request forgery (CSRF)
A CSRF attack uses social engineering methodologies to drive a user to modify information, such as passwords or usernames, in an application. A CSRF, unlike cross-site scripting (XXS) attacks or malware, requires that a user is logged into the application that makes use of only session cookies for validating user requests or tracking sessions. The moment the user performs the anticipated action, the malicious actor uses the browser to execute the remaining part of the attack, like moving funds, without the user knowing what happened.
-
Cross-site scripting (XXS)
Unlike a CSRF which requires the user to be logged in to an app to be deceived into changing certain information, an XXS attack requires the malicious attacker to input code into a webpage, typically in some components of the page such as an image. Once a user launches the webpage on their browser, the bad code begins to download and run in the browser. For instance, the malicious code may redirect the user from a credible site to an illegitimate one.
-
Directory indexing
Usually, web servers outline all the files saved on them in a single directory. When a user wants to locate a particular file in a web application, they usually add the file name in the request. In the case that the file is unavailable, the application will present the user with a list of all indexed files, so that the user has an option to select something else.
However, the files are automatically indexed by web servers. When the application presents a list of all stored files, a malicious attacker taking advantage of vulnerabilities in the directory index can obtain access to data that can give them more information about the system. For instance, they can get to know about personal user accounts or naming conventions. These two data points can be exploited to carry out credential theft attacks or unravel sensitive information.
-
Directory traversal
Also known as backtracking attack, dot-dot-slash, and directory climbing, the directory traversal vulnerability exploits the manner in which an application receives data from the webserver. Access Control Lists (ACLs) generally restrict user access to certain given files inside a root directory. Malicious attackers who use the directory traversal vulnerability mode figure out the URL format which the application uses in requesting files.
-
Encapsulation
Different from some of the other common web application vulnerabilities on the list, encapsulation vulnerability takes advantage of the flaws in the way a developer has coded the application. Encapsulation is a programming term that refers to bundling data and actions that can be performed on that data into just one unit. Encapsulation secures data by concealing information about how the code runs which delivers a better user interface. Users don’t have to know how the application delivers data to them; all they need is access to it.
For instance, an app developer can include access controls, such as read or write permissions, into the ability of an application to retrieve data. If the user requests information in the app, it delivers only the data which they have been permitted to access.
But if the developers fail to set clearly defined boundaries between the data and the actions performed across various aspects of the application, the application suffers an encapsulation vulnerability. Attackers take advantage of this by sending a request to the application, knowing such action would result in an error message. This error message provides then information regarding the structure of the application, aiding more attack strategies such as a DOS – denial of service.
-
Insecure direct object references (IDOR)
Web application URLs are capable of exposing the pattern or format employed in directing users to back-end storage locations. For instance, a URL might show the pattern/format for a record identifier in a storage system like a file system or database.
The IDOR alone might be a low-risk concern. However, when an IDOR is combined with a failed access control check, the attackers get a chance to successfully strike.
Other common web application vulnerabilities you should know are:
-
HTTP response splitting
This is a kind of CRLF injection attack. HTTP is the process through which browsers send queries and the servers send back the responses. In this web application vulnerability, the malicious attackers make use of the CR and LR notations in order to manipulate how the browsers and servers communicate with each other which delivers a request but tells the server to “divide” the response into various parts. Dividing the response into two different parts enables the malicious actor to gain control over the information the server delivers in response to the other part of the request. When such requested data is user ID data or sensitive information, the malicious actor has successfully performed the attack.
-
Injection flaw
An injection flaw allows a plethora of various attack techniques. Any application which allows users to update shell command, operating system call, or a database can suffer an injection flaw. Malicious attackers leverage injection flaws to alter the commands which develop into new and unexpected actions within the application. By taking advantage of these vulnerabilities, malicious actors are able to create, update, read, or even delete data.
-
Insecure message-digest vulnerability
This is a cryptographic vulnerability that limits the effectiveness of encryption. A message digest should comprise the cryptographic hash function. As opposed to encryption, hash functions don’t require the sender and users to use keys.
Malicious attackers thus take advantage of insecure digest vulnerabilities to perpetuate “hash collisions attack”. The objective of the attack is to find out if sending an input leads to the generation of a duplicative hash. If the malicious action forcibly generates a shared hash, then they can use this hash to present a malignant file for download. This in turn leaves the end-user with the assumption that the file is legit.
-
Insufficient transport layer protection
Transport layer security (TLS) refers to the process through which computer applications are able to securely “communicate” with one another on the internet. A number of applications only utilize TLS during the process of authentication, which leaves data and ID session information vulnerable when a person uses the application.
Attackers can take advantage of this vulnerability to divert data as it moves across the internet between the device of the user and the application server.
-
Remote code execution (RCE)
Remote code execution vulnerabilities are coding errors in web applications that enable malicious attackers to insert code notwithstanding their geographical location. RCEs fall under a wider category of web application injection vulnerabilities where attackers input their own code into an application that will not confirm user inputs, making the server view it as genuine application code. Typically, malicious attackers will take advantage of unpatched commonly known vulnerabilities and insert their code into the application.
-
Remote file inclusion (RFI)
To link common directories to an application, developers add “include” statements in their code. For instance, an application might have to draw data from a database. Rather than coding it manually to get each file, the “include” statement helps to link the whole source directory so that everything stored there can be used.
When a web application suffers an RFI vulnerability, then the attackers can manipulate the application to upload malicious code or malware to the database, server, or website.
-
Security misconfiguration
The likelihood of a security misconfiguration is indeed one of the most common web application vulnerabilities today. This vulnerability will generally occur due to an organization’s failure to modify default security settings. Common security misconfigurations are:
- Making use of default passwords or accounts
- Unpatched software
- No encryption
- Inadequate firewall policies
- Neglecting unused, resources, features, and other components
-
SQL injection
SQL, which means Structured Query Language, is a programming language used for databases. It allows for the retrieval and manipulation of data for relational databases. A SQL injection vulnerability is under a larger group of unverified user inputs. When malicious actors deliberately send false requests, the web application responds with an error message that provides them with information about the structure and protection of the database.
-
Unvalidated automatic library activation
In order to save time when coding, developers tend to use third-party libraries. In most cases, this enables them to make use of pre-tested code that accelerates the application development process. Making use of publicly available, open-source code, however, heightens security risks, including:
- The absence of documented ownership raises the risk of malignant code added
- Neglected projects that aren’t updated anymore
This particular vulnerability is increasingly prevalent, considering that several applications engage third-party library dependencies.
We hope the contents of this blog post have been indeed useful and insightful for you. Making sure you find a solution to whichever web application vulnerability applies to your case will be a game-changer in your employee and customer experiences.
