New issue
Advanced search Search tips

Issue 676581 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Aug 20
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature



Sign in to add a comment

Add support for CSRF tokens

Project Member Reported by emso@chromium.org, Dec 22 2016

Issue description

Comment 1 by emso@chromium.org, Jan 11 2017

Labels: Tricium

Comment 2 by emso@chromium.org, Jan 11 2017

Labels: -Pri-2 Pri-1
Labels: Pri-2
If this is really a Pri-1, find an owner and update the priority.

This is the result of a bulk edit that moved high priority available bugs to a lower priority in an attempt to be more honest with bug filers.
Project Member

Comment 4 by sheriffbot@chromium.org, Feb 15 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: vadimsh@chromium.org
Labels: -Pri-2 -Hotlist-Recharge-Cold Pri-3
Status: Available (was: Untriaged)
As far as I understand this right now, "support for xsrf tokens" means something like:

 (1) All web UI forms have a hidden xsrfToken field
 (2) All handlers that handle POST requests from web UI forms must check XSRF tokens, and if the token isn't valid, abort and serve a 403. Checking XSRF tokens means adding WithTokenCheck to the middleware chain when setting up handling for POST requests. (But I think this is only required for POST requests that always come from the web UI.)

Vadim, is it true that internal POST routes that handle pRPC requests don't need to check xsrf tokens? That seems to be how it is in code I've seen so far, e.g. https://cs.chromium.org/chromium/infra/go/src/infra/appengine/luci-migration/app/handlers.go?l=230
Any handler that checks headers (other than Cookies) doesn't need a xsrf token, because it's not possible to send a custom header from another domain (unless CORS is used, which is not the case).

Internal GAE routes must use RequireCron [1] or RequireTaskQueue [2] middlewares that check X-Appengine-* headers. luci-migration doesn't, it is a bug.

pRPC routes check 'Authorization' header, since they use OAuth2 for authorization, not cookies.

Here's another example of using xsrf token in luci-go:
1. Template: https://cs.chromium.org/chromium/infra/go/src/go.chromium.org/luci/server/portal/internal/assets/pages/page.html?type=cs&sq=package:chromium&l=102
2. Handler that generates the page: https://cs.chromium.org/chromium/infra/go/src/go.chromium.org/luci/server/portal/settings.go?l=90 (notice XsrfTokenField).
3. Routes for handlers that check the token: https://cs.chromium.org/chromium/infra/go/src/go.chromium.org/luci/server/portal/handlers.go?l=89

--

[1] https://godoc.org/go.chromium.org/luci/appengine/gaemiddleware#RequireCron
[2] https://godoc.org/go.chromium.org/luci/appengine/gaemiddleware#RequireTaskQueue
Components: Infra>Platform>Tricium
Components: -Infra>CodeAnalysis
Labels: -Tricium
Status: WontFix (was: Available)
Closing since it looks like we won't be including any handlers that require XSRF tokens.

Sign in to add a comment