DAST Vulnerabilties - WCC - CSRF (Cross-site Request Forgery)

Products

• Autosys Workload Automation

Issue/Introduction

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.
For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.
In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.
Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.
Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.
Recommendation
Web sites have various CSRF countermeasures available:

• Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site cannot put the right token in its submissions
• Requiring the client to provide authentication data in the same HTTP Request used to perform any operation with security implications (money transfer, etc.)
• Limiting the lifetime of session cookies
• Ensuring that there is no clientaccesspolicy.xml file granting unintended access to Silverlight controls
• Ensuring that there is no crossdomain.xml file granting unintended access to Flash movies

An easy and effective solution is to use a CSRF filter such as OWASP's CSRFGuard. The filter intercepts responses, detects if it is a html document and inserts a token in to the forms and optionally inserts script to insert tokens in ajax functions. The filter also intercepts requests to check that the token is present.

 
Proof
Referer: https://hostname:8443/wcc/quickview/pages/main.jsf?AntiXSRFToken=2CBC4&OWASP-CSRFTOKEN=ZLZ6-YF6M-9KFD-QQ63-YSBK-4EII-CFO5-LAXU
 
Proof Description
The server returned the same response to an attack request as original response.

Environment

Release : 11.3.6

Component : WORKLOAD CONTROL CENTER

Resolution

The WCC uses the AntiXSRFToken for the session and also a Unique CSRFGuardtoken generated for every page level request.

The product engineering identified this explanation is not a vulnerability or of very low severity.