Taking a Closer Look at Security Bugs in Web Apps

Introduction

Having read many articles about cybersecurity, I found that most of them fail to offer a realistic or practical overview of real-world attack scenarios. Rather than going astray by providing vague details about topics, I am going to focus on specific, real-world scenarios surrounding security bugs and threats.

In the following article, I am going to discuss the most common security flaws that I have discovered in web applications over the course of years of research and how to mitigate them. I have come across many developers who have absolutely no idea what blunders they've made in terms of security. Overall, it's shocking to see how they don't want to acknowledge the fact that they lack the overall competency or the required understanding to address and fix security bugs. By remaining ignorant, they leaving application security to the mercy of their attackers, who may be exploiting private data without them even realizing it. Even the smallest mistake on your part can lead to the biggest losses for your app and its parent company — both in terms of legally binding terms and contracts, as well as it's own business reputation as a whole. On this date, companies like Uber and Facebook have paid over millions in bug bounties to security researches and what does that signify?

In this article, I will try to make sense of the concepts of web application security. It might seem overwhelming at first to developers with little to no experience in application security models, but, eventually, it will all start to make more sense.

Case Studies

UI-Redressing Attack 

A while back, I discovered that all versions of PrestaShop were vulnerable to Clickjacking and UI-redressing attacks, which got assigned CVE-2018-7491 by the Mitre Corporation. Here's the relevant pull request in the PrestaShop repo. Any remote attacker could successfully induce its victim and be an administrator or an unknowing user of the PrestaShop instance, performing unintended state changing actions on an insecure PrestaShop version. With the help of this, as an attacker, you could have caused monetary or administrative losses to the victim user. This needs little user interaction when the attack is triggered successfully. The attacker would have exploited this by tricking the user to click on a redressed UI button with real PrestaShop UI buttons beneath the fake UI — it could have been very difficult for the user to recognize whether it's a phishing or attacking site.

Mitigation 

To avoid these subtle, hard-to-defeat, and hard-to-detect attack methodologies, one may add the following server-side response header to your server configuration.  Content Security Policy frame ancestor  directive or X-Frame-Options: SAMEORIGIN directive successfully helps stop this attack from happening by ensuring that the browser won't display your web app within frames or iframes.

So, how would the attacker have exploited this security flaw?

In the code snippet given below, I have shown how an attacker can embed malicious iframes, which look very similar and behave the same as the original site — http://original-prestashop.instance.

iframe tags), I have shown how an attacker can embed malicious iframes, which look very similar and behave the same as the original site —   

CSRF

Never under-estimate CSRF attacks. I have spotted several CSRF bugs in various web apps and have earned a decent bounty from Google — even this year for reporting CSRF-based security flaws.

Ever noticed that fb_dtsg value in cookies and forms on Facebook's websites?

Wonder why it's there, and why it keeps changing with each page reload?

What Are They?

CSRF attacks happen while forms or POST requests sent from your web app are not validated by the server for a one-time security token. This is all you hear about it. But, really, what happens?

Suppose Mr. A has a social networking site that doesn't have any CSRF protection being built on old frameworks that have not been updated recently. This caught the glance of an attacker B. Attacker B notices that Mr. A's site has millions of active users each day.

In the sections below, we will take a look at some specific attack cases.

Private Data Exposure Through CSRF

Fast forward to an attack vulnerable endpoint that the attacker quickly notices as /user.json.  This returns all third-party API keys and private information belonging to the user via the site's API, and it allows requests without any security tokens. The ACAO or Access Control Allows Origin headers to be returned by the server have a wildcard or *  value. The server's response can be read and the data sent by it is accessible by another website/domain because of this wildcard. Now, on a side note, the developer must take care of this while using ACAO headers.   Now, the attacker, after they make a POST request to the endpoint,/user.json, extracts that data by reading it and logging it in some way into their malicious website.

Sensitive State-Changing Attack Cases Leading to Account Takeovers — PayPal and Facebook

This has happened in case of Facebook, Paypal (paid out $30k to an independent researcher for discovering CSRF attack vector in 2018) and many other companies.

Let's suppose the attacker finds an /email endpoint that is not CSRF protected and issues a POST request with a JSON-encoded email address (under his control) to the website to which the victim user is logged in. The attacker, thus, successfully changes the victim's email via the CSRF attack. Next, the victim's account doesn't have 2FA (most users don't have it). Because of this, the attacker successfully gains access to the victim's account by resetting his password on the targetted CSRF-vulnerable site. Now, do you get the idea of how sensitive CSRF attacks can be in your application's context?

How Is the Entire Attack Executed?

The attacker makes the victim visit a malicious website in a logged-in state to target the website on which the victim user has an account. The victim user performs a state-changing action or is made to perform state-changing actions owing to the POST request or GET request-based forms/endpoints unprotected with CSRF tokens.

Mitigation Against CSRF

Using middlewares or secure frameworks, like Django, Rails, and Laravel, which have CSRF protection enabled by default, can help with mitigation against CSRF, implementing your own CSRF protection mechanism in web applications.

Brute Forcing or Rate Limiting: Self-Explanatory

Attack goal: Leads to user account takeover or DoS attacks both on a network and the application layer. This can cause:

• Mitigation against brute force attacks

• Enable rate limiting your application or web server

XSS Attacks

An attacker can execute malicious scripts in your user's browser context, thereby gaining access to a user account by stealing CSRF tokens and another session ID from cookies. In particular, CSS pre-processors, like LESS and Templating engines like Angular, have many XSS vulnerabilities in general so proper care should be taken.

Mitigation 

Apart from sanitizing user inputs, you must add this server-side response header to your web server config, X-XSS-Protection:1;mode=block . You can further use these cookie tags Secure,HttpOnly in the Set-Cookie header to help mitigate XSS and other attacks aimed at stealing user cookies. 

Further Reading 

https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

https://www.andmp.com/2018/02/advisory-for-PrestaShop-all-versions.html