Cookie Consent by Free Privacy Policy Generator 📌 How to avoid CSRF?


✅ How to avoid CSRF?


💡 Newskategorie: Programmierung
🔗 Quelle: dev.to

Introduction

Hello, in this post, we will briefly go over what CSRF is and how you can possibly avoid your users from being victims of the such attack. Recently, I have been working on the project for creating the backend of the website for selling books. While learning about how to basically handle authentication for safely allowing users to access the sensitive information, instead of using a cookie to store the credentials of a user, the instructor decided to go for a route of using HTTP headers for sending JSON web tokens in a request. When she went for that method, I couldn't initially understand why she would ditch a cookie for the storage of tokens for manually storing tokens somewhere in the browser - such as localStorage or sessionStorage, which may be vulnerable to XSS attacks. And then I realized there must be a reason for that, which led me down the path to search for an answer as to why a cookie may not be a good candidate for storing sensitive information. That's when I came across the topic of CSRF and how it may be used to make users perform unwanted actions.

CSRF?

CSRF is essentially an attack that tricks users into unknowingly performing nefarious actions wanted by an attacker. An attacker utilizes the credentials stored in the cookies of the browser of a user, and its malicious website, to potentially trick users into submitting requests to a legitimate website using its credentials. For example, a legitimate website issues and sends tokens to a user via cookies, which get stored in the user's browser for its subsequent requests. With the tokens saved in the browser, an attacker somehow leads a victim to its website, creates a form for submitting information to a legitimate website and makes a user submit the form for whatever purposes, such as changing one's password or making a purchase. As you can see, allowing such an action to an attacker is often very catastrophic and may lead to the complete compromise of the website itself - imagine an attacker somehow tricking a user with admin privileges to perform actions.

How CSRF works

This is how it works:

  1. A user logs in to a legitimate website for whatever it intends to do.
  2. In response, a website issues tokens for allowing users to make subsequent requests to the various pages of the website. The purpose of the tokens is to allow users not to have to log in to the website every time it tries to access some pages that are only meant for authenticated users. A website issues tokens to a user via the cookies, which are stored in the browser of a user for making subsequent requests to the website.
  3. Unknowingly, an attacker lures a user to a page of the malicious website of an attacker that looks awfully similar to that of the legitimate website, and provides the form for making a POST request to the endpoint of a legitimate website. The form is meant to send data to the endpoint for changing the password of a certain user.
  4. Completely oblivious to the fact that it is on the website of an attacker, a user willfully provides the various information necessary for submitting the form. At this point, it doesn't matter what information a user provides to the form, since an attacker is completely free to change the contents of the form via JavaScript, and may provide the new password of its choice on behalf of a user.
  5. A user ultimately sends the form to a legitimate website. A legitimate website handles the form, as if a user has willfully submitted the form, and proceeds to change the password of a user with the new password provided by an attacker.

The example above is kind of a simple example of what an attacker can do to a victim with CSRF attacks, but it is still an entirely feasible scenario that may result in catastrophic results. If an attacker manages to trick an admin into performing actions vital to the management of the system itself, it may result in the complete takedown of the system. So, since we know the mechanism of the attack, how do we exactly defend our users against falling victims to such an attack?

Solutions

One thing we have to know is that problems lie in the way the system is designed, so there is no way you can deflect some of the blames to a user when this attack occurs. There is no one-size-fits-all solution for completely mitigating the CSRF attacks, but rather it requires a combination of various measures that, when used together, provides a robust defense for end users. Here are some of the solutions you may implement in your system.

1. Avoid GET requests for making changes to data

  • Stick with methods other than that of the GET for making changes to the existing information in the system. The GET method is strictly used for retrieving the information, and it shouldn't be used for anything other than that. Imagine if there was a URL for sending money to a certain user like this, http://bank.com/transfer.do?acct=MARIA&amount=100000. The URL accepts two query parameters, acct and amount, and an attacker may easily construct a URL for sending a certain amount of money to itself by replacing the acct with its value, and may attack it to a link, such as <a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">Click Here</a>. All it is left at this point is for a user to click that link and send the money to an attacker.

2. Use CORS

  • CORS allows the system to block requests from all the domains other than the ones that it is configured to accept requests from. The system often utilizes the HTTP methods such as POST and PUT to introduce or make changes to the data, and CORS essentially protects a user by filtering requests that are from the domains that are not approved by the system itself. Thankfully, the browsers nowadays are set up by default to avoid making the cross-origin requests, unless the target server allows it without any restriction.

3. Use CSRF Token

  • Provide a single-use token to a user before every POST or PUT request a user makes. For example, when a user makes changes to its password, it submits its new password alongside the token provided by the system prior to changing the password. Once the token is used, it becomes invalid and prevents itself from being reused again. In my personal opinion, I don't know how effective this method is, when frontend and backend are decoupled, but I assume this may be very useful in a case where backend serves the HTML pages. Here is how you may use it to secure your webpage from attacks. First, assign a session token to a user accessing the page. Second, with a session token provided by a user, generate a CSRF token which is essentially mapped to a session token of a user. Third, a user uses it to submit a POST or PUT request to submit information, and the system verifies the CSRF token against a session token of a user to make sure that it is indeed from a user.
...

✅ csrf-magic up to 1.0.3 CSRF Protection $GLOBALS['csrf']['secret'] cross site request forgery


📈 29.6 Punkte

✅ Intel Laptop Users Should Avoid Linux 5.19.12 To Avoid Potentially Damaging The Display


📈 20.36 Punkte

✅ Trump’s Plan to Avoid Conflicts of Interest Won’t Avoid a Thing


📈 20.36 Punkte

✅ Trump’s Plan to Avoid Conflicts of Interest Won’t Avoid a Thing


📈 20.36 Punkte

✅ How to avoid CSRF?


📈 20.05 Punkte

✅ What Is CSRF? How Can We Prevent CSRF?


📈 19.74 Punkte

✅ Online Romance Scams Take Aim at Your Heart and Identity. Avoid these Red Flags


📈 10.18 Punkte

✅ Smartphone shopping: Avoid the blues on Cyber Monday


📈 10.18 Punkte

✅ MSPs – Here’s How to Choose Good Customers and Avoid the “Wildcards”


📈 10.18 Punkte

✅ 7 steps to avoid uncoordinated vulnerability disclosure


📈 10.18 Punkte

✅ Police Warn Students To Avoid Sci-Hub


📈 10.18 Punkte

✅ How to Avoid Impediments to Migrating Critical Apps to the Cloud


📈 10.18 Punkte

✅ Anti-Vaccine Groups Avoid Facebook Bans By Using Emojis


📈 10.18 Punkte

✅ Mistakes to Avoid When Moving Your Contact Center to the Cloud


📈 10.18 Punkte

✅ Why CIOs back API governance to avoid tech sprawl


📈 10.18 Punkte

✅ Avoid Tutorial Hell: Choosing Great Learning Resources 🧠


📈 10.18 Punkte

✅ How To Avoid Infinity War Spoilers Until You See The Movie


📈 10.18 Punkte

✅ How To Avoid CyberMonday Scams


📈 10.18 Punkte

✅ Avoid getting lost in encryption with these easy steps


📈 10.18 Punkte

✅ Retailers! Avoid getting hacked during the holiday season (or any other time of the year)


📈 10.18 Punkte

✅ Common Holiday Scams and How to Avoid Them


📈 10.18 Punkte

✅ Common Container Mistakes and How to Avoid Them


📈 10.18 Punkte

✅ How to avoid interest on your credit card


📈 10.18 Punkte

✅ Added escaping to the bundle module to avoid XSS


📈 10.18 Punkte

✅ How to avoid N + 1 and keep your Ruby on Rails controller clean


📈 10.18 Punkte

✅ Searching with Umbraco Examine: Avoid these common filtering mistakes


📈 10.18 Punkte

✅ Sitemap sanitation added to avoid XSS


📈 10.18 Punkte

✅ Safe gaming: Account hijacking and how to avoid it


📈 10.18 Punkte

✅ 10 Ways How To Avoid Being A Phishing Scams Victim


📈 10.18 Punkte

✅ Businesses can avoid fines if customer data is encrypted or redacted


📈 10.18 Punkte

✅ Avoid Common Pitfalls with Next.js Server-Side Rendering


📈 10.18 Punkte

✅ 10 Common Mistakes to Avoid While Writing JavaScript Code


📈 10.18 Punkte











matomo

Datei nicht gefunden!