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?
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:
Login.jsp in an IFrame - history contains Login.jsp.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.
/ShowSecretInfo.jsp in an IFrame - history contains /ShowSecretInfo.jsp./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.
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:
and this means that an attacked user is authenticated – privacy violation.
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
