Cross Site Request Forgery (CSRF) is one of the web vulnerability in web applications. Liferay implemented a mechanism to prevent CSRF attack. In liferay all URLs will generate with one of the request parameter called p_auth. The p_auth token is embedded in both GET and POST URLs which is not what OWASPs recommends.
Our security audit team has prevented us from getting liferay up and running because of the p_auth token embedded in every GET requests. Is there anything that Liferay Team knows about that we can use to quickly get this implemented rather than creating a hook for every portlet and re-writing the entire forum, document, wiki portlets.
OWASP states the following about CSRF Token in Get headers -
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
Disclosure of Token in URL
Many implementations of this control include the challenge token in GET (URL) requests as well as POST requests. This is often implemented as a result of sensitive server-side operations being invoked as a result of embedded links in the page or other general design patterns. These patterns are often implemented without knowledge of CSRF and an understanding of CSRF prevention design strategies. While this control does help mitigate the risk of CSRF attacks, the unique per-session token is being exposed for GET requests. CSRF tokens in GET requests are potentially leaked at several locations: browser history, HTTP log files, network appliances that make a point to log the first line of an HTTP request, and Referer headers if the protected site links to an external site.
The ideal solution is to only include the CSRF token in POST requests and modify server-side actions that have state changing affect to only respond to POST requests. This is in fact what the RFC 2616 requires for GET requests. If sensitive server-side actions are guaranteed to only ever respond to POST requests, then there is no need to include the token in GET requests.
