Most Common Application Vulnerabilities and Attacks

• A recent study found that the XSS attack is the most common cyberattack making up approximately 40% of all attacks. Even though it’s the most frequent one, most of these attacks aren’t very sophisticated and are executed by amateur cyber criminals using scripts that others have created. Cross-site scripting targets the users of a site instead of the web application itself. The malicious hacker inserts a piece of code into a vulnerable website, which is then executed by the website’s visitor. The code can compromise the user’s accounts, activate Trojan horses or modify the website’s content to trick the user into giving out private information. You can protect your website against XSS attacks by setting up a web application firewall (WAF). WAF acts as a filter that identifies and blocks any malicious requests to your website. Usually, web hosting companies already have WAF in place when you purchase their service, but you can also set it up yourself.

XSS (Cross Site Scripting) – Types

• Reflected XSS (AKA Non-Persistent or Type I)

  Reflected XSS occurs when user input is immediately returned by a web application in an error message, search result, or any other response that includes some or all of the input provided by the user as part of the request, without that data being made safe to render in the browser, and without permanently storing the user provided data. In some cases, the user provided data may never even leave the browser (see DOM Based XSS below).

  Stored XSS (AKA Persistent or Type II)

  Stored XSS generally occurs when user input is stored on the target server, such as in a database, in a message forum, visitor log, comment field, etc. And then a victim is able to retrieve the stored data from the web application without that data being made safe to render in the browser. With the advent of HTML5, and other browser technologies, we can envision the attack payload being permanently stored in the victim’s browser, such as an HTML5 database, and never being sent to the server at all.

  DOM Based XSS (AKA Type-0)

  As defined by Amit Klein, who published the first article about this issue [1], DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser. For example, the source (where malicious data is read) could be the URL of the page (e.g., document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call that causes the execution of the malicious data (e.g., document.write).”

  Types of Cross-Site Scripting

  For years, most people thought of these (Stored, Reflected, DOM) as three different types of XSS, but in reality, they overlap. You can have both Stored and Reflected DOM Based XSS. You can also have Stored and Reflected Non-DOM Based XSS too, but that’s confusing, so to help clarify things, starting about mid 2012, the research community proposed and started using two new terms to help organize the types of XSS that can occur:

  • Server XSS
  • Client XSS

  Server XSS

  Server XSS occurs when untrusted user supplied data is included in an HTTP response generated by the server. The source of this data could be from the request, or from a stored location. As such, you can have both Reflected Server XSS and Stored Server XSS.

  In this case, the entire vulnerability is in server-side code, and the browser is simply rendering the response and executing any valid script embedded in it.

  Client XSS

  Client XSS occurs when untrusted user supplied data is used to update the DOM with an unsafe JavaScript call. A JavaScript call is considered unsafe if it can be used to introduce valid JavaScript into the DOM. This source of this data could be from the DOM, or it could have been sent by the server (via an AJAX call, or a page load). The ultimate source of the data could have been from a request, or from a stored location on the client or the server. As such, you can have both Reflected Client XSS and Stored Client XSS.

  With these new definitions, the definition of DOM Based XSS doesn’t change. DOM Based XSS is simply a subset of Client XSS, where the source of the data is somewhere in the DOM, rather than from the Server.

Most Commons Application Attacks – Injection

• The Open Web Application Security Project (OWASP) in their latest Top 10 research named injection flaws as the highest risk factor for websites. The SQL injection method is the most popular practice used by cyber criminals in this category. The injection attack methods target the website and the server’s database directly. When executed, the attacker inserts a piece of code that reveals hidden data and user inputs, enables data modification and generally compromises the application. Protecting your website against injection -based attacks mainly comes down to how well you’ve built your codebase. For example, the number one way to mitigate a SQL injection risk is to always use parameterized statements where available, among other methods . Furthermore, you can consider using a third-party authentication workflow to out- source your database protection.

Most Commons Application Attacks – Unvalidated Redirects and Forwards

• This category of vulnerabilities is used in phishing attacks in which the victim is tricked into navigating to a malicious site. Attackers can manipulate the URLs of a trusted site to redirect to an unwanted location.

Most Commons Application Attacks – SQL Injection

• An SQL injection attack is when attackers inject malicious SQL scripts 1 into a web application to gain access to the database stored in the ser ver. A common way for hackers to do that is by injecting hidden SQL queries 2 in web forms (e. g. login form). Usually, when a user inputs their information in the form and hits the “login” button, an SQL query would be sent to the database to request that user ’s information. However, when hackers inject a malicious SQL quer y, they could request all kinds of data from the database. By then, the hacker would be able to easily view, change, or delete data and potentially paralyze the entire system from functioning. Since most web applications have databases stored in their servers, these applications become attractive targets for SQL injection, leading to breaches of sensitive information.

SQL Injection – Types

• In-band SQLi The attacker uses the same channel of co mmunication to launch their attacks and to gather their results. In -band S QLi ’s simplicity and efficiency make it one of the most common types of SQLi attack. There are two sub -variations o f this method
• Error-based SQLi—the attacker performs actio ns that cause the database to produce error messages. The attacker can potentially use the data provided by these error messages to gather information about the structure of the database.
• Union-based SQLi—this technique takes advantage o f the UN ION S QL operator, w hichf uses multiple select statements generated by the database to get a single HT TP response. This response may contain data that can be leveraged by the attacker.

Most Commons Application Attacks – Path Traversal

• A path traversal (or directory traversal) attack is an application attack that targets the root directory of an application. Normally a result of a manipulated dot-slash sequence, path traversal attacks trick applications into allowing access into server files where all of the information within a system rests. Accessed data can include user credentials, access tokens, and even entire system backups that hold everything from sensitive data to system access controls.

Most Commons Application Attacks – Session Hijacking

• A session hijacking attack tampers with session IDs. This unique ID is used to label a user’s time online, keeping track of all activity for faster and more efficient future logins. Depending on the strength of the session ID, attackers could capture and manipulate the session ID, launching a session hijacking attack. If successful, attackers will have access to all information passed through the server for that particular session, getting a hold of user credentials to access personal accounts.

Most Commons Application Attacks – CSRF

• Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

Most Commons Application Attacks – DDoS

• The DDoS attack aims to overwhelm the target’s web server with requests, making the site unavailable for other visitors. A botnet usually creates a vast number of requests, which is distributed among previously infected computers. Also, DDoS attacks are often used together with other methods; the former’s goal is to distract the security systems while exploiting a vulnerability. Protecting your site against a DDoS attack is generally multi-faceted. First, you need to mitigate the peaked traffic by using a Content Delivery Network (CDN), a load balancer and scalable resources. Secondly, you also need to deploy a Web Application Firewall in case the DDoS attack is concealing another cyberattack method, such as an injection or XSS.

Most Commons Application Attacks – IDOR

• Insecure Direct Object Reference (called IDOR from here) occurs when a application exposes a reference to an internal implementation object. Using this way, it reveals the real identifier and format/pattern used of the element in the storage backend side. The most common example of it (although is not limited to this one) is a record identifier in a storage system (database, filesystem and so on).

Most Commons Application Attacks – CRLF

• The term CRLF refers to Carriage Return (ASCII 13, \ r) Line Feed (ASCII 10, \n). They’re used to note the termination of a line, however, dealt with differently in today’s popular Operating Systems. For example: in Windows both a CR and LF are required to note the end of a line, whereas in Linux/UNIX a LF is only required. In the HTTP protocol, the CR-LF sequence is always used to terminate a line. A CRLF Injection attack occurs when a user manages to submit a CRLF into an application. This is most commonly done by modifying an HTTP parameter or URL.

Most Commons Application Attacks – Race Condition

• Race condition attacks (also called Time of Check to Time of Use, or TOCTTOU attacks) take advantage of the need that computing systems must execute some tasks in a specific sequence. In any such sequence, there is a small period of time when the system has carried out the first task but not started on the second. If this period is long enough or the attacker is lucky and knowledgeable, a race condition vulnerability exists where an attacker can trick the system into carrying out unauthorized actions in addition to its normal processes. There are two main ways this attack is carried out: Interference by an untrusted process – The attacker inserts a piece of code in between the steps of a secure process. Interference by a trusted process – The attacker exploits two different processes that share some state in common.

Most Commons Application Attacks – Insecure Deserialization

• Insecure deserialization is when user-controllable data is deserialized by a website. This potentially enables an attacker to manipulate serialized objects in order to pass harmful data into the application code. It is even possible to replace a serialized object with an object of an entirely different class. Alarmingly, objects of any class that is available to the website will be deserialized and instantiated, regardless of which class was expected. For this reason, insecure deserialization is sometimes known as an “object injection” vulnerability. An object of an unexpected class might cause an exception. By this time, however, the damage may already be done. Many deserialization-based attacks are completed before deserialization is finished. This means that the deserialization process itself can initiate an attack, even if the website’s own functionality does not directly interact with the malicious object. For this reason, websites whose logic is based on strongly typed languages can also be vulnerable to these techniques.

Most Commons Application Attacks – XXE

• XML external entity injection (also known as XXE) is a web security vulnerability that allows an attacker to interfere with an application’s processing of XML data. It often allows an attacker to view files on the application server filesystem, and to interact with any back -end or external systems that the application itself can access. In some situations, an attacker can escalate an XXE attack to compromise the underlying server or other back -end infrastructure, by leveraging the XXE vulnerability to perform server-side request forgery (SSRF) attacks.

Most Commons Application Attacks – SSRF

• Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker’s choosing. In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization’s infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.

Most Commons Application Attacks – Command Injection

• Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation. This attack differs from Code Injection, in that code injection allows the attacker to add their own code that is then executed by the application. In Command Injection, the attacker extends the default functionality of the application, which execute system commands, without the necessity of injecting code.

Common Reasons for Existence of Application Vulnerabilities

• An application vulnerability is a system flaw or weakness in an application that could be exploited to compromise the security of the application. Once an attacker has found a flaw, or application vulnerability, and determined how to access it, the attacker has the potential to exploit the application vulnerability to facilitate a cyber crime. These crimes target the confidentiality, integrity, or availability (known as the “CIA triad”) of resources possessed by an application, its creators, and its users. Attackers typically rely on specific tools or methods to perform application vulnerability discovery and compromise. According to Gartner Security, the application layer currently contains 90% of all vulnerabilities.