You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "kirby zhou (Jira)" <ji...@apache.org> on 2022/02/22 08:55:00 UTC
[jira] [Comment Edited] (RANGER-3635) REST-API security risk, cookie hadoop.auth is often ignored, web session works instead, timeout is broken.
[ https://issues.apache.org/jira/browse/RANGER-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495900#comment-17495900 ]
kirby zhou edited comment on RANGER-3635 at 2/22/22, 8:54 AM:
--------------------------------------------------------------
In RangerKrbFilter.java, it only call createAuthCookie when a new token created or allowTrustedProxy.
So if create a request with "Hadoop..Auth"
{code:java}
public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain)
throws IOException, ServletException {
...
// Extract and verify token from "hadoop.auth"
token = getToken(httpRequest);
...
if (token == null) {
if (LOG.isDebugEnabled()) {
LOG.debug("Request [{}] triggering authentication", getRequestURL(httpRequest));
}
// Do auth with kerberos
token = authHandler.authenticate(httpRequest, httpResponse);
if (token != null && token.getExpires() != 0 &&
token != AuthenticationToken.ANONYMOUS) {
token.setExpires(System.currentTimeMillis() + getValidity() * 1000);
}
newToken = true;
}
...
if ((newToken || allowTrustedProxy) && !token.isExpired() && token != AuthenticationToken.ANONYMOUS) {
String signedToken = signer.sign(token.toString());
// create token and add "Set-Cookie" to response
createAuthCookie(httpResponse, signedToken, getCookieDomain(),
getCookiePath(), token.getExpires(), isHttps);
}
// call RangerKRBAuthenticationFilter::doFilter
doFilter(filterChain, httpRequest, httpResponse);
}
{code}
In RangerKRBAuthenticationFilter.java doFilter
Code only checks "Set-Cookie" in response header to get userName. So the userName is null when a request with "hadoop.auth" coming, and no authentication object is created to enable the request to be processed.
{code:java}
protected void doFilter(FilterChain filterChain,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
String userName = null;
if(checkCookie){
Collection<String> authUserName = response.getHeaders("Set-Cookie");
if(authUserName != null){
Iterator<String> i = authUserName.iterator();
while(i.hasNext()){
// extract userName from response.getHeaders("Set-Cookie")["hadoop.auth"]
userName = s.substring(ustr+2, andStr);
}
}
}
// Because we only check "Set-Cookie" above, so the userName is null when a request with "hadoop.auth" coming
if((isSpnegoEnable(authType) && (!StringUtils.isEmpty(userName)))){
Authentication existingAuth = SecurityContextHolder.getContext().getAuthentication();
if(existingAuth == null || !existingAuth.isAuthenticated()){
// if we get the userName from the token then log into ranger using the same user
final Authentication finalAuthentication = new UsernamePasswordAuthenticationToken(principal, "", grantedAuths);
Authentication authentication = authenticationProvider.authenticate(finalAuthentication);
authentication = getGrantedAuthority(authentication);
SecurityContextHolder.getContext().setAuthentication(authentication);
} else {
try{
super.doFilter(filterChain, request, response);
}catch(Exception e){
throw restErrorUtil.createRESTException("RangerKRBAuthenticationFilter Failed : "+e.getMessage());
}
}
} else {
// continue without setAuthentication, a request with "hadoop.auth" go here
filterChain.doFilter(request, response);
}
}{code}
As described above, "hadoop.auth" was not successfully used as authentication credentials at all.
As for allowTrustedProxy == true, it should be another story.
was (Author: kirbyzhou):
In RangerKrbFilter.java, it only call createAuthCookie when a new token created or allowTrustedProxy.
So if create a request with "Hadoop..Auth"
{code:java}
public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain)
throws IOException, ServletException {
...
// Extract and verify token from "hadoop.auth"
token = getToken(httpRequest);
...
if (token == null) {
if (LOG.isDebugEnabled()) {
LOG.debug("Request [{}] triggering authentication", getRequestURL(httpRequest));
}
// Do auth with kerberos
token = authHandler.authenticate(httpRequest, httpResponse);
if (token != null && token.getExpires() != 0 &&
token != AuthenticationToken.ANONYMOUS) {
token.setExpires(System.currentTimeMillis() + getValidity() * 1000);
}
newToken = true;
}
...
if ((newToken || allowTrustedProxy) && !token.isExpired() && token != AuthenticationToken.ANONYMOUS) {
String signedToken = signer.sign(token.toString());
// create token and add "Set-Cookie" to response
createAuthCookie(httpResponse, signedToken, getCookieDomain(),
getCookiePath(), token.getExpires(), isHttps);
}
// call RangerKRBAuthenticationFilter::doFilter
doFilter(filterChain, httpRequest, httpResponse);
}
{code}
In RangerKRBAuthenticationFilter.java doFilter
Code only checks "Set-Cookie" in response header to get userName. So the userName is null when a request with "hadoop.auth" coming, and no authentication object is created to enable the request to be processed.
{code:java}
protected void doFilter(FilterChain filterChain,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
String userName = null;
if(checkCookie){
Collection<String> authUserName = response.getHeaders("Set-Cookie");
if(authUserName != null){
Iterator<String> i = authUserName.iterator();
while(i.hasNext()){
// extract userName from response.getHeaders("Set-Cookie")["hadoop.auth"]
userName = s.substring(ustr+2, andStr);
}
}
}
// Because we only check "Set-Cookie" above, so the userName is null when a request with "hadoop.auth" coming
if((isSpnegoEnable(authType) && (!StringUtils.isEmpty(userName)))){
Authentication existingAuth = SecurityContextHolder.getContext().getAuthentication();
if(existingAuth == null || !existingAuth.isAuthenticated()){
// if we get the userName from the token then log into ranger using the same user
final Authentication finalAuthentication = new UsernamePasswordAuthenticationToken(principal, "", grantedAuths);
Authentication authentication = authenticationProvider.authenticate(finalAuthentication);
authentication = getGrantedAuthority(authentication);
SecurityContextHolder.getContext().setAuthentication(authentication);
} else {
try{
super.doFilter(filterChain, request, response);
}catch(Exception e){
throw restErrorUtil.createRESTException("RangerKRBAuthenticationFilter Failed : "+e.getMessage());
}
}
} else {
// continue without setAuthentication, a request with "hadoop.auth" go here
filterChain.doFilter(request, response);
}
}{code}
As described above, "hadoop.auth" is never used to "hadoop.auth" was not successfully used as authentication credentials at all.
As for allowTrustedProxy == true, it should be another story.
> REST-API security risk, cookie hadoop.auth is often ignored, web session works instead, timeout is broken.
> -----------------------------------------------------------------------------------------------------------
>
> Key: RANGER-3635
> URL: https://issues.apache.org/jira/browse/RANGER-3635
> Project: Ranger
> Issue Type: Bug
> Components: admin
> Affects Versions: 3.0.0, 2.2.0, 2.3.0
> Reporter: kirby zhou
> Priority: Major
>
> Now, a successful REST-API call will set 2 cookies:
> A. "hadoop.auth" by RangerKrbFilter::createAuthCookie
> B. "RANGERADMINSESSIONID" by tomcat http session system
>
> Only B works, and configuration property "ranger.admin.kerberos.token.valid.seconds" is meaningless for REST-API.
>
> Explains:
>
> By default, "hadoop.auth" will have a domain set by conf
> "ranger.admin.kerberos.cookie.domain" which have a default value "" in "ranger-admin-site.xml". So it sets "; Domain= " in http response by the following codelet:
>
> {code:java}
> if (domain != null) {
> sb.append("; Domain=").append(domain);
> } {code}
> But "; Domain= " is invalid in a lot of client systems due to security concerns.
> So, "hadoop.auth" cookie is ignored by them.
> But tomcat will set a session by cookie "RANGERADMINSESSIONID", our client didn't find anything unusual. And session timeout (default 60m)is controlled by web.xml which is not in out conf/ directory. So our defuat conf ranger.admin.kerberos.token.valid.seconds = 30s (second) is meaningless.
> Unfortunately there is some security risk with session mechanism. Apache Tomcat session timeout mainly occurs due to longer idle sessions.
> So if we auth a client by kerberos, the session mechanism can lead it keep login by ever. Even the kerberos ticket is outdated.
>
> Example:
>
>
> {code:java}
> ]$ curl -v -c cookies -u: --negotiate --resolve kirbytest01.sa:6080:10.10.137.131 'http://kirbytest01.sa:6080/service/plugins/secure/policies/download/hdfsdev'
> ...
> < HTTP/1.1 200 OK
> < WWW-Authenticate: Negotiate oYHtMIHqoAMKAQChCwYJKoZIhvcSAQIComoEaGBmBgkqhkiG9xIBAgICAG9XMFWgAwIBBaEDAgEPokkwR6ADAgEXokAEPufXDNr8Trp6CFHt1x/cszrgBFvRJVpBOM+YQZjXQBkTwo08e3cDHYvbBgUBfR0ZSSGEPBShs4OZaoW+x4qdo2oEaGBmBgkqhkiG9xIBAgICAG9XMFWgAwIBBaEDAgEPokkwR6ADAgEXokAEPufXDNr8Trp6CFHt1x/cszrgBFvRJVpBOM+YQZjXQBkTwo08e3cDHYvbBgUBfR0ZSSGEPBShs4OZaoW+x4qd
> * skipped cookie with bad tailmatch domain:
> < Set-Cookie: hadoop.auth="u=freeman&p=freeman@SA&t=kerberos&e=1645499352543&s=IHkDgmx2XOY+gqXA28wFRPwl8HnLyFkI3Ky9ifIzyyY="; Path=/; Domain=; Expires=Tue, 22-Feb-2022 03:09:12 GMT; HttpOnly
> * Replaced cookie RANGERADMINSESSIONID="1D2AD847382F6FCC66E37C63533FA297" for domain kirbytest01.sa, path /, expire 0
> < Set-Cookie: RANGERADMINSESSIONID=1D2AD847382F6FCC66E37C63533FA297; Path=/; HttpOnly
> ]$ cat coookies
> # Netscape HTTP Cookie File
> # https://curl.haxx.se/docs/http-cookies.html
> # This file was generated by libcurl! Edit at your own risk.
> #HttpOnly_kirbytest01.sa FALSE / FALSE 0 RANGERADMINSESSIONID 1D2AD847382F6FCC66E37C63533FA297
> ]$ watch -n 10 curl -v -b cookies --resolve kirbytest01.sa:6080:10.10.137.131 'http://kirbytest01.sa:6080/service/plugins/se^Cre/policies/download/hdfsdev' -o /dev/null
> 200 OK ## forever
> {code}
>
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)