Web Attacks

This blog post was contributed by Vaibhav Rastogi.

The web is one of the most common interfaces between an organization and the outside world and so web attacks, or attacks on web applications, are a fairly frequent attack scenario. They have been studied for decades, projects such as OWASP Top Ten have been there to create awareness about these attacks, and there are numerous tools, which can be used to detect and mitigate common web application vulnerabilities. Here, we outline some of the common categories of attacks on web applications.

Injection attacks

Such attacks happen when untrusted data is incorporated into the server-side application logic without proper sanitization. These attacks can use a variety of vectors: for example, unsanitized input can make its way into a SQL query to result in a so-called SQL injection. Similar attacks can result with injection into noSQL database queries, and into server-side scripts (e.g., a PHP script that evaluates some untrusted input, which then gets executed as code).

These attacks can result in exposure of confidential data or a compromise of data integrity. Ways to prevent these attacks involve proper placement of sanitizers in the server-side logic so as to never let unsanitized, untrusted data reach places where it could execute as part of application logic.

Cross-Site Scripting (XSS)

Cross-site scripting is similar to injection attacks in that the some untrusted input is interpreted as the application logic, but this time the attack happens in the browser rather than the server. Specifically, the attack happens when an attacker injects into the webpage markup data, that is interpreted by the browser as a script (typically, Javascript) and executed.

As an example, consider an attacker inserting a script element (Javascript code enclosed in <script></script> tag) in an input field that requires their name. Upon submission, the data in the field is then stored in a server-side database. An unsuspecting user viewing the names of all people in the database through a web interface then gets the attack script in lieu of the attacker's name. This attack script is then executed by the browser.

Cross-site scripting can again lead to compromise of confidentiality and integrity. The primary way of preventing cross-site scripting to insert sanitizers that modify the inputs in ways such that the browser does not interpret them as executable code. Another line of defense comes from the so called content security policies in web browsers. These policies specify where content (including executable content) can come from (e.g., from specific domains or specially marked-up elements). The browser then ignores any content that has not been white-listed in this manner. We will discuss CSP in greater detail in a future blog post.

Authorization and Authentication Flaws

This category represents several scenarios. For example, an object may be publicly accessible though a URL while it should have been accessible only to authenticated users, who have the right privileges. Another example could be bypassing highjacking an authenticated session by merely using the URL of the authenticated session. To elaborate, suppose a session is authenticated through a session ID, which is present in the URL. An attacker could entice a victim to send them an authenticated session URL and use the session ID-containing URL to get the victim's session. Failure to enforce strong passwords or the use of insecure authentication practices, e.g., authenticating a user based on secret question/answers in lieu of passwords are also authentication flaws.

Man-in-the-middle Attacks

With the client-server communication happening over an unencrypted channel, the data is open to sniffing and spoofing attacks while in transit. This can most easily be fixed with by using HTTP over TLS or HTTPS. HTTPS encrypts the communication channel and provides authentication of the server (i.e., the connected example.com is indeed example.com) and integrity and confidentiality of the data. TLS configuration errors can sometimes result in weakened security. It is therefore important to choose a strong default configuration for your web server.

Cross-Site Request Forgery (CSRF)

In this, the attacker exploits the browser to send a request to the server on victim's behalf. The victim is typically logged-in into the website and so the request is processed in an authenticated context. For example, consider a user logged into their bank website and in a separate browser tab clicking on an attack link that directs the bank website to transfer money from the victim's account to the attacker's account. The main issue here is that the server has no way to tell if the victim created this request or the attacker did it from the victim's browser.

Common ways of dealing with CSRF attacks include the server sending a nonce (a random, unpredictable token) to the client, which is then embedded in every legitimate request to the server. Any attacker-created request will not have the nonce and hence can be rejected by the server.

The above is only a very short summary of the attacks. There are many details we have skipped, including variations on these attacks, and how to prevent them effectively. We will cover some of these attacks in detail in future posts.