Skip to content

CSRF vulnerability #114

@ewjoachim

Description

@ewjoachim

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&section=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 be Lax. 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

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions