Hi Ralf:

In message <1732543729.53.0.967849195543.issue2551372@roundup.psfhosted.org>,
Ralf Schlatterbeck writes:
>When looking at the REST documentation the small section 'Preventing
>CSRF Attacks' only lists the X-REQUESTED-WITH header as required. But
>it seems the Origin header is also mandatory, at least on
>updates. The config option "csrf_enforce_header_origin" has no
>influence on this.

I think Origin is the only other one because it has to be checked
against allowed_api_origins if the request is not a GET. (I guess your
update is a PUT/PATCH/POST.)

Technically the Origin header is not a CSRF header in this role. It's
an API authorization header. The allowed_api_origins setting is
documented in the CSRF attacks section with:

  If you want to allow Roundup's api to be accessed by an application
  that is not hosted at the same origin as Roundup, you must permit
  the origin using the ``allowed_api_origins`` setting in
  ``config.ini``.

How about adding this sentence:

  If you access the REST interface with a method other than GET, you
  must also supply an origin header with a value that is permitted by
  ``allowed_api_origins``.

Does this provide you with the info?

>When recently upgrading a tracker at a customer, one client can no
>longer run their scripts (which do an update) because they get
>"Required Header Missing". Unfortunately it doesn't even tell *which*
>header is missing.

It should be logged at error level. It is not displayed to the client
intentionally.

However, this code in handle_rest:

        # verify Origin is allowed on all requests including GET.
        # If a GET, missing origin is allowed  (i.e. same site GET request)
        if not self.is_origin_header_ok(api=True):
            if 'HTTP_ORIGIN' not in self.env:
                msg = self._("Required Header Missing") (*)
            else:
                msg = self._("Client is not allowed to use Rest Interface.")

is missing code after (*) like:

  logger.error("Origin header missing or unauthorized for REST request.")

This might be more useful if it also logs the method (get, post ...)
and the authenticated user.

>Two things should be done:
>- Mention all required and optional headers in the REST-API CSRF
>  section, in particular the headers that are needed even if turned off
>  in config.ini

Origin is the only one I can think of. IIRC the X-REQUESTED-WITH
header check can be turned off. The allowed_api_origins can't be
turned off.  If empty it has the value of the origin from the
tracker.web setting (i.e. self).

>- Maybe mention *which* header is missing in the error message
>  returned to the user. I'm not sure if this would constitute a
>  security issue but I think not.

The missing headers should be logged on the server. Recommendations on
reporting the missing header to the client was mixed when the code was
originally written. More sources were against reporting the missing
header to the attacker who could use a non-browser originated REST
request to probe the app.

OSWAP also comes down on the do not report side as well.

https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html#error-handling

  * Respond with generic error messages - avoid revealing details of
    the failure unnecessarily.

details like the header name.

Thoughts?