ZCS-12917: Fix "An unknown error has occurred" raised when zimbraMailURL is configured

[k-kato]

Issue:
When zimbraMailURL is changed from / to /test/path, for example, and user accesses https://host/ (without the path), login fails with an error "An unknown error has occurred."

Steps:

1. set zimbraMailURL to /test/path
2. access https://host/
3. login to Classic UI. It succeeds at this time. The URL changes to https://host/test/path/?client=advanced
4. log out. The URL is https://host/test/path/?loginOp=logout
5. access https://host/ without the path
6. try to login, but it fails.

Easier way:

1. set zimbraMailURL to /test/path
2. access https://host/test/path
3. access https://host/
4. try to login, but it fails.

Root cause:
When login page accessed, ZM_LOGIN_CSRF is created on a browser. The path of the cookie depends on the access URL.

• https://host -> the path of the cookie is /
• https://host/test/path -> the path of the cookie is /test/path

When a browser has the both cookies, login from https://host fails because (param.login_csrf eq cookie.ZM_LOGIN_CSRF.value) returns false. cookie.ZM_LOGIN_CSRF refers a cookie for /test/path, not for /. Then it falls back to c:otherwise block.

at line 145
<c:when test="${(not empty param.login_csrf) && (param.login_csrf eq cookie.ZM_LOGIN_CSRF.value)}">
   // zm:login process
</c:when>
<c:otherwise>
	<!-- on failure of csrf show error to user -->
	<c:set var="errorCode" value="unknownError"/>
	<fmt:message var="errorMessage" key="unknownError"/>
</c:otherwise>

Fix:

• Specify the path / explicitly for ZM_LOGIN_CSRF and ZM_TEST cookies

[secure-code-warrior-for-github]

Micro-Learning Topic: Cross-site request forgery (Detected by phrase)

Matched on "CSRF"

What is this? (2min video)

Session-related but not session-based, this attack is based on the ability of an attacker to force an action on a user’s browser (commonly in the form of a POST request) to perform an unauthorized action on behalf of the user. This can often occur without the user even noticing it… or only noticing when it is too late. The root cause is that browsers automatically send session cookies with all requests to a given domain, regardless of where the source of the request came from, and the application server cannot differentiate between a request that came from pages it served or a request that came from an unrelated page.

Try a challenge in Secure Code Warrior

Helpful references

• Securing Rails Applications - Cross-Site Request Forgery (CSRF) - A Rails Guide that describes common security problems in web applications and how to avoid them with Rails.
• Spring Security - Cross Site Request Forgery (CSRF) - A Spring Security article that describes Spring support for protecting against Cross Site Request Forgery attacks.
• csurf Node.js CSRF protection middleware - Documentation on CSRF protection provided by the csurf middleware for Express.
• XSRF/CSRF Prevention in ASP.NET MVC and Web Pages - A detailed Microsoft article on how to prevent cross-site request forgery in ASP.NET MVC and Web Pages.
• Django Documentation - Cross Site Request Forgery protection - Documentation on CSRF protection provided by the Django framework.
• OWASP Cross-Site Request Forgery Prevention Cheat Sheet - This cheatsheet is focused on providing clear, simple, actionable guidance for preventing cross-site request forgery flaws in your applications.
• Laravel Docs - CSRF Protection - Documentation on CSRF protection provided by the Laravel framework.
• OWASP Cross Site Request Forgery (CSRF) - OWASP community page with comprehensive information about cross-site request forgery, and links to various OWASP resources to help detect or prevent it.
• Preventing Cross-Site Request Forgery (CSRF) Attacks in ASP.NET MVC Application - A detailed Microsoft article on how to prevent cross-site request forgery in ASP.NET MVC.

[k-kato]

I found that ZM_LOGIN_CSRF cookie was not removed after login at line 154-156. I will fix it and update the PR.

[k-kato]

I added a commit.
@silentsakky please review it again.