Of course, that’s the last thing we really want to happen since an attacker has now posed as a logged-in user and changed that user’s email address. The browser says “oh! I have a cookie for this website, let me helpfully attach it to this request!” So while the user is on, the website shoots off a post request to our website’s /profile endpoint. The attacker knows enough about our website to know we have a /profile endpoint that accepts post requests, and that if a user posts a new_email to that endpoint, that user’s account email is changed. User navigates to an attacker’s website, which makes a POST request to your backendĪt some point, the user navigates to an attacker’s website (let’s say … sounds menacing, right?). The client now starts making requests to the backend, sending the sessionId cookie along as it goes. Our server validates this information and sends a cookie called sessionId to the client. User logs in to your site and interacts with it normallyĪ user navigates to our website and submits thier email address and password to our server. Let’s go through the motions of what a CSRF attack might look like. This attack is possible because browsers will “helpfully” include cookies with any request to your site, regardless of where that request originated from. What is a CSRF attack?Ī CSRF attack is when an attacker website is able to successfully submit a request to your website using a logged-in user’s cookies. Today we’ll gain a better understanding of CSRF and why cookie-based CSRF tokens are a good option for Single Page Applications (SPAs). The Cross-Site Request Forgery (CSRF) attack vector is often misunderstood.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |