Cross Site History Manipulation resolution

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.