-
-
Notifications
You must be signed in to change notification settings - Fork 21
Closed
Description
I have discussed with @Mariatta privately, and I was told to open a public issue, so here it is.
The view that launches blurb_it doesn't protect itself against CSRF attacks.
This means if I have a session on https://blurb-it.herokuapp.com/, and I visit, say, attacker.com
which contains the following script:
fetch("https://blurb-it.herokuapp.com/add_blurb", {
"credentials": "include",
"headers": {
"Content-Type": "application/x-www-form-urlencoded",
},
"body": "bpo_number=1&pr_number=1§ion=Security&news_entry=yay",
"method": "POST",
"mode": "cors"
});
then a blurb would be silently created.
I guess that this it not critical, given it would be reviewed before it's merged into CPython but still, that could make things strange for the victim who would have a blurb on their PR that they didn't create.
Mitigations would include:
- Adding a CSRF token: a random string stored in the session, and added as
<input type="hidden>
in the form. It's value would be checked on POST and if the form and the session differ, the POST would be rejected. This requires code, but would be enough on itself. - Making the aiohttp session cookie
SameSite
attribute beLax
. This is discussed upstream in aiohttp & aiohttp-session: the option to pass a value for SameSite has been merged but not released yet in aiohttp and a ticket for making this available in aiohttp-session is openned. This would solve the problem on modern browsers, but old browsers would still be vulnerable. That being said, the target users of blurb_it most probably use modern browsers.
Metadata
Metadata
Assignees
Labels
No labels