IV96845: Ability to bypass security and use unauthorized functions


Testers found that they had the ability to add reports to the My Reports page in TRIRGA, even though the links for New, Copy, Delete, Copy as Community Report, and Share Report were not present for the read-only users.

Moving forward, an privilege escalation issue in Report Manager has been resolved.

[Admin: To see other related posts, use the Vulnerability tag or CVE tag.]

Continue reading

IV93762: Privilege escalation vulnerability in Report Manager


The IBM TRIRIGA application is vulnerable to a privilege escalation vulnerability. Specifically, IBM TRIRIGA Report Manager contains a vulnerability that could allow an authenticated user to execute actions to which they should not have access.

Continue reading

UX: Why is WebViewSync giving an unauthorized exception?


I’m having an issue with pulling and syncing from one environment. It’s TRIRIGA 3.5.0.1 and I’m running WebViewSync.jar Version 1. I pulled the space assessment from a different environment and then performed an init to the new environment. When I sync, I encounter the following error. Has anyone had this issue before?

Waiting for changes to sync...
Signing On To TRIRIGA [success]
[2016-08-02 15:12:20] [push] /triview-space-assessment.html [!ERROR!]
Signing On To TRIRIGA [success]
[2016-08-02 15:12:21] [push] /triview-space-assessment.html [!ERROR!]
Exception in thread "main" java.lang.RuntimeException: com.ibm.tririga.webviewsync.serveroperation.domain. UnauthorizedException
...
Caused by: com.ibm.tririga.webviewsync.serveroperation.domain. UnauthorizedException
...
Signing Out Of TRIRIGA [success]

Try using sync with a URL that includes a fully qualified domain name (FQDN).

[Admin: This post is related to the 06.01.16 post about using WebViewSync.]

Continue reading

How do you set WAS traditional to allow basic authentication?


I’ve created a standalone EAR deployed on WebSphere that simply makes a SOAP call to TRIRIGA’s Connector for Business Applications (CBA). From the log file, it seems as though the basic authentication header is being ignored by TRIRIGA.

When deployed on WebSphere Liberty with the same version of TRIRIGA, I do not have this unauthorized problem, so it seems to be a security configuration disparity between WebSphere 8.5.5.6 traditional and WebSphere Liberty (tested on 8.5.5.5 and 8.5.5.8).

From the SecurityLogger, the platform is correctly identifying the user. However, the status is Failed. Can anyone shed some ideas as to why there is a difference in security settings between Liberty and traditional? And how can I configure WebSphere traditional to allow basic authentication?

Continue reading

IV83657: Cross-site request forgery (CSRF) vulnerability


A CSRF attack forces an authenticated victim’s browser to send an unauthenticated request to a vulnerable web application, which then performs unauthorized action on behalf of the attacker. This issue has been identified in various places throughout the application. This APAR is meant specifically for the example below.

Steps to replicate:

  • 1. Set the KNOWN_REFERRER_LIST to the hostname.
  • 2. Restart the TRIRIGA application server.
  • 3. Navigate to Configure > People > Employees.
  • 4. Select any existing employee.
  • 5. Click on the Delete button and intercept the form.
  • 6. Change the “sNo” field in the form to that of another user.
  • 7. Save the form as an HTML file, and open it in the browser, where you are currently logged in to TRIRIGA.
  • 8. Submit the CSRF form and see that the other user is deleted.

[Admin: This post is related to the 03.16.16 post and 04.04.16 post about another cross-site request forgery (CSRF) attack vulnerability (IV82436).]

Continue reading