That’s why cookies should be set with the __Host- prefix.
In a carefully-designed API, CORS will function as a CSRF defense, even when
the attacker is controlling a subdomain or sibling domain.
Overall, I think the first part of 6.1 makes sense, but I don’t think the
document should try to dr
Hi Neil! =)
I get your point!
I would suggest this text be written as something along the lines of:
"Additionally, the SameSite cookie attribute can be used to
prevent CSRF attacks /*but the application and API should*//*also*/
/**//**//* be written to use */anti-CSRF tokens for stateful
se
Karsten, Daniel,
Can you please address my comments in a new version of the draft to allow
me to progress it?
Regards,
Rifaat
On Mon, Sep 6, 2021 at 6:50 AM Karsten Meyer zu Selhausen <
karsten.meyerzuselhau...@hackmanit.de> wrote:
> Hi Rifaat,
>
> thank you for the shepherd's review.
>
> Tho
Technically yes, CSRF refers to cross-site attacks. However, there is a class
of attacks that are cross-*origin* but not cross-site and which are otherwise
identical to CSRF. SameSite doesn’t protect against these attacks but other
traditional CSRF defences *do*. For example, synchronizer tokens
If someone has taken over a subdomain in the ways described, that is not cross
site request forgery since the attack is occurring from within your site. It’s
more likely XSS that allows for cookie clobbering or similar, or just malicious
code injected by the malicious controller of your subdomai
In 6.1 it says
"Additionally, the SameSite cookie attribute can be used to
prevent CSRF attacks, or alternatively, the application and API could
be written to use anti-CSRF tokens.”
“Prevent” is a bit strong.
SameSite only restricts cookies sent across site boundaries Iit does not
preven
