You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2023/01/31 16:57:00 UTC
[jira] [Commented] (IMPALA-11856) Loglevel endpoints don't follow API best practices
[ https://issues.apache.org/jira/browse/IMPALA-11856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17682655#comment-17682655 ]
ASF subversion and git services commented on IMPALA-11856:
----------------------------------------------------------
Commit 86d33a0a3dca40d452e5a5868c399df2238fa934 in impala's branch refs/heads/master from Michael Smith
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=86d33a0a3 ]
IMPALA-11856: Use POST requests to set log level
Set and reset loglevel handlers now require a POST. Implements
Cross-Site Request Forgery (CSRF) prevention in Impala's webserver using
the Double Submit Cookie pattern - where POST requests must include a
csrf_token field in their post with the random value from the cookie -
or a custom header.
CSRF attacks rely on the browser always sending a cookie or
'Authorization: Basic' header.
- With cookies, attacks don't have access to default form values or the
original cookie, so we can include the cookie's random value in the
form as a cross-check. As the cookie is cryptographically signed, they
also can't be replaced with one that would match an attack's forms.
- When not using cookies, a custom header (X-Requested-By) is required
as CSRFs are unable to add custom headers. This approach is also used
by Jersey; see
http://blog.alutam.com/2011/09/14/jersey-and-cross-site-request-forgery-csrf
In a broader implementation this would require a separate cookie so it
can be used to protect logins as well, but login is handled external to
Impala so we re-use the cookie the page already has.
Cookies are now generated for the HTPASSWD authentication method.
Authenticating via JWT still omits cookies because the JWT is already
provided via custom header (preventing CSRF) and disabling
authentication (NONE) means anyone could directly send a request so CSRF
protection is meaningless.
We also start an additional Webserver instance with authentication NONE
when metrics_webserver_port > 0, and the Webserver metric
"impala.webserver.total-cookie-auth-success" can only be registered
once. Additional changes would be necessary to make metric names unique
in Webserver (based on port); for the moment we avoid that by ensuring
all metrics counters are only instantiated for Webservers that use
authentication.
Cookie generation and authentication were updated to provide access to
the random value.
Adds flag to enable SameSite=Strict for defense in depth as mentioned in
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis.
This can be enabled if another CSRF attack method is found.
Verified that this prevents CSRF attacks by disabling SameSite=Strict
and visiting (via https://security.love/CSRF-PoC-Genorator):
```
<html>
<form enctype="application/x-www-form-urlencoded" method="POST"
action="http://localhost:45000/set_glog_level">
<table>
<tr>
<td>glog</td>
<td><input type="text" value="1" name="glog"></td>
</tr>
</table>
<input type="submit" value="http://localhost:45000/set_glog_level">
</form>
</html>
```
Adds tests for the webserver with basic authentication, LDAP, and SPNEGO
that authorization fails on POST unless
- using a cookie and csrf_token is correctly set in the POST body
- the X-Requested-By header is set
Change-Id: I4be8694492b8ba16737f644ac8c56d8124f19693
Reviewed-on: http://gerrit.cloudera.org:8080/19199
Reviewed-by: Impala Public Jenkins <im...@cloudera.com>
Tested-by: Impala Public Jenkins <im...@cloudera.com>
> Loglevel endpoints don't follow API best practices
> --------------------------------------------------
>
> Key: IMPALA-11856
> URL: https://issues.apache.org/jira/browse/IMPALA-11856
> Project: IMPALA
> Issue Type: Bug
> Affects Versions: Impala 4.2.0
> Reporter: Michael Smith
> Assignee: Michael Smith
> Priority: Major
>
> The log level endpoints
> * {{/set_glog_level}}
> * {{/reset_glog_level}}
> * {{/set_java_loglevel}}
> * {{/reset_java_loglevel}}
> don't follow API best practices. They use a GET method to manipulate server-side state and can be replayed by another site.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org