DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Penetration Testing: A Comprehensive Guide
  • AI and Cybersecurity Protecting Against Emerging Threats
  • What Is Pen Testing?
  • How Backdoor Attacks Facilitate Data Poisoning in Machine Learning

Trending

  • How to Migrate Vector Data from PostgreSQL to MyScale
  • Creating a Custom Starter With Spring Boot 3
  • Memory Management in Java: An Introduction
  • Information Security: AI Security Within the IoT Industry
  1. DZone
  2. Data Engineering
  3. Data
  4. CSRF Vulnerability Allowed Attackers To See Sensitive Data of Grammarly's Customers

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

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...

Ziyahan Albeniz user avatar by
Ziyahan Albeniz
·
Jan. 19, 18 · Analysis
Like (2)
Save
Tweet
Share
5.01K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Data (computing) Vulnerability Web Service

Published at DZone with permission of Ziyahan Albeniz, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Penetration Testing: A Comprehensive Guide
  • AI and Cybersecurity Protecting Against Emerging Threats
  • What Is Pen Testing?
  • How Backdoor Attacks Facilitate Data Poisoning in Machine Learning

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: