issue_comments: 671070528
This data as json
| html_url | issue_url | id | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
|---|---|---|---|---|---|---|---|---|---|---|---|
| https://github.com/simonw/datasette/issues/918#issuecomment-671070528 | https://api.github.com/repos/simonw/datasette/issues/918 | 671070528 | MDEyOklzc3VlQ29tbWVudDY3MTA3MDUyOA== | 9599 | 2020-08-09T16:12:16Z | 2020-08-09T16:12:16Z | OWNER | It's worth noting that in order to exploit this issue the following would all need to be true: - A user is running a copy of Datasette protected by a cookie-based authentication plugin AND configured with at least one writable canned query - An attacker is in control of a URL that could concievably be returned on a page that is displayed as the result of submitting a read-only canned query - An authenticated user of that Datasette instance, who is running a browser that doesn't support the `SameSite=lax` cookie parameter (which is [widely supported](https://caniuse.com/#feat=same-site-cookie-attribute) by modern browsers), submits the read-only canned query form and then clicks a link to the attacker's off-site page, exposing their CSRFToken in the attacker's HTTP referer logs - The attacker then tricks that user into visiting their own malicious web page which includes a POST form that auto-submits against the writable canned query that the attacker wishes to exploit, including the CSRF token as a hidden field The attacker would need full knowledge of the URL and form layout of the Datasette instance that they are exploiting. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 675724951 |