跨站点历史操作解决方案

Question

We have developed a new application, and before moving the changes we did a static scan of code using checkmarx. There is a medium level vulnerablity that is found in the code named Cross Site History Manipulation.

This is detacted in the JSP page where I am validating the session values :

if(request.getSession().getAttribute("sesStrUID")!=null)

Can you please help me understand this vulnerabilty and what should be done to eliminate this?

Answer 1

This is more a browser vulnerability than a website vulnerability in Internet Explorer from 2010 :

Checkmarx Research Labs has identified a new critical vulnerability in Internet Explorer (other browsers are probably exposed the same way) that would allow hackers to easily compromise web applications.

This is a violation of the Same Origin Policy by the browser and it is not something you should be fixing in your web application. The vulnerability reported is probably referring to a redirect you are doing based on your

request.getSession().getAttribute("sesStrUID")!=null

condition. It is saying that if you're redirecting server side based on the session sesStrUID value, then an attacker could IFrame your website, and if it detects that you are redirecting it can infer whether sesStrUID is null or not.

This is only a problem if your users are using a broken browser. If your users are using modern browsers then this is not worth fixing IMO. If you want to be extra safe and also protect against clickjacking attacks, you could output the X-Frame-Options: DENY HTTP header to prevent framing. Please note that this would only protect you against the IFrame version of the attack. For other attack vectors discussed in depth, check out this XSHM paper .

Edit after @adar's answer :

Adar's answer is very similar to mine and contains much the same information, except that the poster states that this is still an issue.

However, XSHM is not a problem if you are redirecting server side via the location HTTP header . HTTP 3xx redirects do not cause the value of history.length to be increased in modern browsers, so this cannot be used to determine whether the user is logged into a particular site.

If you are outputting JavaScript code to redirect after your

 
 
 
  
  if(request.getSession().getAttribute("sesStrUID")!=null)
 
  

code then XSHM is an issue, if you are redirecting server side

 
 
 
  
  <% String redirectURL = "http://example.com/myJSPFile.jsp"; response.sendRedirect(redirectURL); %>
 
  

then you are not vulnerable.

Edit after @adar's answer II :

@adar is correct: If you try the following attack scenario:

1. Open Login.jsp in an IFrame - history contains Login.jsp .
2. Open ShowSecretInfo.jsp - if the server then redirects to Login.jsp with HTTP 3xx, then history.length will remain the same, if a server shows ShowSecretInfo.jsp - history.length will be increased by 1.

Therefore if history.length increases, you can determine that the user is logged in. I could recreate the above with IE 11 and Firefox 33.1 on Windows 7. Chrome 39 is not vulnerable in this way from my tests, but it is in another:

Assuming that /ShowSecretInfo.jsp redirects to /Login.jsp (with no query) if the user is not logged in.

1. Open /ShowSecretInfo.jsp in an IFrame - history contains /ShowSecretInfo.jsp .
2. Set the IFrame src to /Login.jsp - if history.length does not increase, then you know the user is logged in.

It appears that Chrome does not try to redirect if the src is already set to the current URL. I could also recreate this in IE and Firefox.

Answer 2

Here's the answer I got from Alex Roichman, Chief Software Architect @ Checkmarx :

Cross-site history manipulation is a browser same origin policy breach where it's possible to know a state of a condition from another origin. For example, many sites check if a user was authenticated prior to showing them his private data. This can be done by following code:

If (!IsAuthenticated())
          Redirect “login.jsp”

By using XSHM it's possible from another site to know if a user is currently authenticated to that site.

Now let's look for a given line:

if(request.getSession().getAttribute("sesStrUID")!=null)

This line seems to check if a user has a session or even already authenticated. Since inside 'if' statement there is 'redirect', it's possible for any other site to know that request.getSession().getAttribute("sesStrUID")!=null or if a user was already authenticated.
Thus this result is true and it has nothing with old or modern browsers: all modern browsers provide an access to history.lengh, this property can lead to privacy violation via XSHM, and there is no simple fix because of backward compatibility issues.

X-Frame-Options: DENY can protect against the IFrame version of XSHM, but old browsers don't support this option.

Edit after SilverlightFox's answer

I agree we have very similar answers.

Still, concerning:

"3xx redirects do not cause the value of history.length to be increased in modern browsers"

This is right and XSHM is based exactly on this.

Look for the following attack scenario:

1. Open 'Login.jsp' in an IFrame - now history contains 'login.jsp' on top of it.
2. Open 'ShowSecretInfo.jsp' - if a server will redirect to 'Login.jsp' with 3xx, then history.length will remain the same, if a server will show 'ShowSecretInfo.jsp'- history.length will be increased by 1.

and this means that an attacked user is authenticated – privacy violation.

Answer 3

From OWASP Site

Cross-Site History Manipulation (XSHM) is a SOP (Same Origin Policy) security breach. SOP is the most important security concept of modern browsers. SOP means that web pages from different origins by design cannot communicate with each other. Cross-Site History Manipulation breach is based on the fact that client-side browser history object is not properly partitioned on a per-site basis. Manipulating browser history may lead to SOP compromising, allow bi-directional CSRF and other exploitations such as: user privacy violation, login status detection, resources mapping, sensitive information inferring, users' activity tracking and URL parameter stealing.

With request.getSession().getAttribute("sesStrUID") , you are not doing anything that goes to browser history, So looks like its wrong detection