Cross site

Question

We developed a new application, and before moving the changes, we performed a static code scan using checkmarkx. There is a mid-level vulnerability that occurs in code called Cross Site History Manipulation.

This is deactivated on the JSP page, where I check the session values:

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

Could you help me understand this vulnerability and what needs to be done to eliminate this?

Answer 1

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

Checkmarkx Research Labs has identified a new critical vulnerability in Internet Explorer (other browsers probably display in the same way), which will allow hackers to easily compromise web applications.

This is a violation of the same browser origin policy, and this is not something you should fix in your web application. The reported vulnerability probably refers to the redirect you do based on

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

state. He says that if you redirect the server side based on the sesStrUID session sesStrUID , then the attacker can IFrame on your website, and if he detects that you are redirecting, he can conclude whether sesStrUID null or not.

This is only a problem if your users use a broken browser. If your users use modern browsers, then it is not worth fixing IMO. If you want to be more secure as well as protect against click attacks, you can output X-Frame-Options: DENY HTTP header to prevent cropping. Please note that this will only protect you from the IFrame attack version. For other attack vectors discussed in detail, check out this XSHM paper .

Edit after @adar answer :

Adar's answer is very similar to mine and contains a lot of the same information, except that the poster claims that this is still a problem.

However, XSHM is not a problem if you redirect the server part through the location HTTP header . HTTP 3xx redirects do not increase the value of history.length in modern browsers, so it cannot be used to determine whether a user is logged on to a particular site.

If you send JavaScript code to redirect after

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

then XSHM is a problem if you redirect the server side

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

then you are not vulnerable.

Edit after @adar II answer :

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

• Open Login.jsp in an Login.jsp - the history contains Login.jsp .
• Open ShowSecretInfo.jsp - if the server then redirects to Login.jsp using HTTP 3xx, then history.length will remain the same, if the 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 this is different:

Assuming /ShowSecretInfo.jsp redirected to /Login.jsp (without request) if the user is not logged in.

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

It seems like Chrome is not trying to redirect if src already set to the current URL. I could also recreate this in IE and Firefox.

Answer 2

Here is the answer I received from Alex Roichman, Chief Software Architect @ Checkmarx :
<sh> The cross-site history manipulation is the same initial political violation of the browser, where you can find out the state of the state from another source. For example, many sites check to see if the user has been authenticated before showing them their personal information. This can be done using the following code:

 If (!IsAuthenticated()) Redirect "login.jsp" 

Using XSHM, it can be obtained from another site to find out if the user is being checked on this site.

Now let's look at this line:

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

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

X-Frame-Options: DENY can protect against the IFrame version of XSHM, but older browsers do not support this option.

Edit after SilverlightFox answer

I agree that we have very similar answers.

However, regarding:

"3xx redirects do not increase the value of history.length in modern browsers"

That's right, and XSHM is based on that.

Find the following attack scenario:

• Open 'Login.jsp in an IFrame - now the story contains' login.jsp on top of it.
• Open 'ShowSecretInfo.jsp - if the server is redirected to' Login.jsp with 3xx, then history.length will remain the same, if the server displays' ShowSecretInfo.jsp-history.length will be increased by 1.

and this means that the attacked user is authenticated - a violation of confidentiality.

Answer 3

From OWASP Website

Cross-page Manipulation (XSHM) is a SOP (Policy of Same Origin) Security breach. SOP is the most important security concept in modern browsers. SOP means that web pages from different design sources cannot communicate with each other. Manipulation using cross-reference violation is based on the fact that the browser history object on the client side is not properly distributed across each site. Manipulating browser history can lead to SOP compromise, allow bidirectional CSRF and other exploits, such as: violation of user privacy, login status detection, resource mapping, determination of confidential information, user activity tracking and URL theft.

With request.getSession().getAttribute("sesStrUID") you are not doing anything in the browser history, so it looks like an incorrect detection