New answers tagged

0

Correct me if I misunderstood the question.But here's what I have understood. Browser sends all the cookie values to the server when you open this HTML. This is the default nature of browser to append all the cookies with the request. If browser has some cookies of a particular host, it will send these with every request pointing to the same host.


0

But how does it determine JSESSIONID? I can log in and close the browser windows and the page still works as long as my session is still valid. Seems the server is telling the browser what its JSESSIONID is? The server sends JSESSIONID to the browser in an http response with a set-cookie header. Here is an example: HTTP/1.1 302 Found Server: ...


3

I think you are misunderstanding how an CSRF-attack works, and why CSRF-tokens protects against them. So lets begin with how one works. The attacker fools the victim to visit http://evil.com that contains a form that automatically does a POST to http://bank.com/transfer?to=evilHacker&amount=1000000. If the victim is already logged in to her bank, the ...


0

TL;DR A JWT, if used without Cookies, negates the need for a CSRF token - BUT! by storing JWT in session/localStorage, your expose your JWT and user's identity if your site has an XSS vulnerability (fairly common). It is better to add a csrfToken key to the JWT and store the JWT in a cookie with secure and http-only attributes set. Read this article with ...


3

As this question mentions, a single random unguessable token per session is sufficient. When you start generating tokens per-page or per-form, you're simply limiting the impact of a CSRF token being leaked. Singular token leakage cases are relatively rare bugs, but XSS is obviously a common vector. In certain cases it does indeed make sense to have a ...


0

Consider what you're protecting against: an attacker tricking a user into making a request they don't think they're making. How would multiple different tokens on the page protect against that any more than a single one?


2

First, a definition from Chrome: Same-site cookies (née "First-Party-Only" (née "First-Party")) allow servers to mitigate the risk of CSRF and information leakage attacks by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain. So what does this protect against? CSRF? Same-site cookies can ...



Top 50 recent answers are included