CSRF Vulnerability Allowed Attackers To See Sensitive Data of Grammarly's Customers

In the early days of the internet, privacy was easier to maintain. If a website prompted you to enter your real name when registering, you had two choices. Either you would leave instantly or you would provide a fake name if access to the website was important to you.

Generally, you were careful about when and where you used your real name online. Websites were lacking JavaScript, and every personal homepage had at least one colorful gif of a dancing animal.

The Personal Data Problem on the Internet

Now, if you try to register on one of the most popular sites on the internet with a fake name, you get instantly banned (see 'Facebook real-name policy controversy'). Messenger apps on your phone upload your whole address book to servers abroad. Many websites ask you for your name, email address, age, and gender just to show you an article about a topic of interest.

Not much of the internet we used to know is left. While this is shocking, the hard truth is, we are used to it. In our contemporary world, we sacrifice privacy for comfort and usability. Why even bother providing a fake name or using throwaway email addresses, when you can simply click 'Login with Facebook' for instant registration?

Many websites store your private data on their servers. We do not mind this because it is convenient to have it there and it makes our online lives a little bit easier. We trust the services to be careful with our data and have measures in place to ensure that no malicious third party can access it.

We actually place a vast amount of trust in the websites and services we use. One of them is a cloud service called Grammarly.

What is Grammarly?

In 2017, according to Alexa, Grammarly is among the 800 most popular websites in the US. So, what is the service it provides that helped to build such popularity?

The service provides plugins for three of the most popular browsers: FireFox, Safari, and Chrome. Grammarly uses these plugins to analyze what you write in real time, and warns you immediately if you make a spelling, grammar, or punctuation mistake. It also encourages good writing style. Here is how they describe their service on the Grammarly site:

Whether you're writing an important business email, a social media post, an essay, or an online dating profile, Grammarly will have your back...Grammarly helps you write mistake-free on Gmail, Facebook, Twitter, Tumblr, LinkedIn, and nearly anywhere else you write on the web.

How Grammarly Works

While this sounds like a useful service, it comes with a problem. In order to analyze your writing, the plugins can read your emails, instant messages, online documents, and more. Whatever you do online, Grammarly is just waiting for you to make a mistake, and show you how to correct it.

As soon as you log into the Grammarly service, the plugin starts to check what you write and saves it. It also analyses your writing and emails you a weekly summary report.

The CSRF Attack on Grammarly

It sounds harmless, doesn't it? After all, you are the only one who knows your password, and Grammarly will not share your data with anyone else.

Let's assume attackers can't guess your strong and unique password. But, they still have other ways to get your data. Attackers do not need to log into your Grammarly account. They only need to silently log you into theirs!

CSRF Attack Code

This code shows the exploit attackers could use to carry out a Cross-Site Request Forgery (CSRF) attack.

CSRF protection would normally prevent other websites from logging you out of your account and logging you into a different, attacker-controlled, one. The problem was that there was no CSRF protection on either auth.grammarly.com/v3/logout or on the auth.grammarly.com/v3/login endpoint.

Exploiting the CSRF Vulnerability in Grammarly

This is how attackers would exploit the CSRF security issue in Grammarly. They would:

1. Host the CSRF attack code on their website
2. Prompt the victim to click the link to the exploit (by sending an email, instant message, facebook post, for example)
3. Once the victim clicks the link, the code will:
   1. Log the victim out by sending a request to https://auth.grammarly.com/v3/logout (line 5)
   2. Prepare a form to submit to https://auth.grammarly.com/v3/login (line 7), which contains the attacker's email address (line 8) and his password (line 9)
   3. Automatically submit the form, without any user interaction, using javascript (line 12)
4. The victim is now logged in to the attacker's account and the attacker can use their own email and password to log into Grammarly and view sensitive data belonging to their victim

Potential Implications of the CSRF Attack on Grammarly

These scenarios are not theoretical in nature. This type of web application vulnerability was found in Grammarly a few months ago. As soon as Netsparker noticed the security flaw, we acted responsibly and reported it to the company. Grammarly reacted quickly and professionally, fixing the bug in a short amount of time.

Companies such as Grammarly, however, don't always have the luxury of knowing about web application vulnerabilities before an attack happens. In this type of CSRF attack, the user's documents are saved in the attacker's account and everything they do subsequently is actually done in the hacker's Grammarly account.

It is easy to think of scenarios where heavily sensitive data in the hands of hackers could be put to malicious use. Consider this: if you had used Grammarly, what types of documents would you have checked? If you ran a company that is planning a merger and some of your legal documentation got into the hands of hackers, might they be able to use that to publish and expose company secrets or future strategy? What irrevocable damage might that do to your plans? Might the company buying you back out of the deal?

If you are in charge of a public body that stores lots of clients' personal and health data and you were checking the content of a series of test result letters, what damage might such a breach do to public trust and credibility? Would it incur government fines or other heavy penalties, perhaps?

If your company provides services to another company, you may have employed Grammarly to check your contract renewal terms before sending. What damage might be done if those contracts, along with your pricing structure and other terms, were revealed to your competitors?

Think how many of your employees and partners use online tools. Which ones are secure?

And, if you own and run similar online services, what are you doing, first of all, to ensure that your system has a robust security posture? And, what will you continue to do to maintain it?

You can read about a similar flaw was found in the Yandex browser (' CSRF Vulnerability in Yandex Browser Allows Attackers to Steal Victims' Browsing Data').

The Need for Cross-Site Request Forgery Protection

The problem for Grammarly was that there was no CSRF protection in place. Specifically, Grammarly's online service had no CSRF protection for its login and logout functionality. Some may argue that this is not a significant issue. It can become significant, however, when combined with other vulnerabilities, particularly when these other vulnerabilities may not be otherwise reachable. There certainly was a detrimental effect in this case, where it had a direct impact on the confidentiality of users' data.

Netsparker can reliably detect Cross-Site Request Forgery vulnerabilities in login forms among others. If you are unsure whether your website is properly protected against this type of attack, download the free demo of Netsparker Desktop to see how many vulnerabilities it can identify on your websites.