Help resolving vulnerability

I could use some help resolving this vulnerability

Vulnerability, TEN-47831: The remote web server hosts CGI scripts that fail to adequately sanitize request strings of malicious JavaScript. By leveraging this The remote web server hosts CGI scripts that fail to adequately sanitize request strings of malicious JavaScript. By leveraging this issue, an attacker may be able to cause arbitrary HTML and script code to be executed in a user's browser within the security context of the affected site. These XSS are likely to be 'non-persistent' or 'reflected'.

Using the GET HTTP method, Nessus found that : + The following resources may be vulnerable to cross-site scripting (comprehensive test) : + The 'server' parameter of the /login_proceed.jsp CGI : /login_proceed.jsp?login=&password=&sched_type=jscheduler&server=%FF%FE% 3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%32%30%33%29%3C%2F%73%63%72%69% 70%74%3E -------- output -------- <tr> <td><font><strong>Unable to connec t to ??<script>alert(203)</script> on port 1097. Verify that the server name is correct, the 24x7 server is configured for remote control, and t he firewall isn't blocking connections on that port</strong></font></td> </tr> ------------------------

any idea what to add to the web.xml in order to resolve this?

Thank you

Thank you for sharing it. Investigating...

	SysOp wrote:
	Thank you for sharing it. Investigating...

Hi There have you had a chance to look into this?

Thank You

The investigation is still ongoing. I might be able to provide some preliminary results very soon

The preliminary result that report is a false positive. In a nutshell it says that an attacker might be able to use "server" parameter for cross-site scripting. That might be the case if the server value was used in a web context. Quoting it here "an attacker may be able to cause arbitrary HTML and script code to be executed in a user's browser within the security context of the affected site."

That's not the case here, the server value isn't used in a web context. It's used as is, as a name of the server running 24x7 Scheduler, basically an end-point to which the console is going to try to connect to using non-web based protocol. Your DNS server will try to resolve that name to a TCP/IP address, there is no HTML or script interpretation from the given value and no redirection or cross-site references of any sort. The value isn't passed to any other web page too, sort of a one way street.

SysOp wrote:

The preliminary result that report is a false positive. In a nutshell it says that an attacker might be able to use "server" parameter for cross-site scripting. That might be the case if the server value was used in a web context. Quoting it here "an attacker may be able to cause arbitrary HTML and script code to be executed in a user's browser within the security context of the affected site."

That's not the case here, the server value isn't used in a web context. It's used as is, as a name of the server running 24x7 Scheduler, basically an end-point to which the console is going to try to connect to using non-web based protocol. Your DNS server will try to resolve that name to a TCP/IP address, there is no HTML or script interpretation from the given value and no redirection or cross-site references of any sort. The value isn't passed to any other web page too, sort of a one way street.

I have a question from my colleague if you wouldn't mind taking a look.

Thank you

"Just to understand what they mean, they are saying the server itself isn't parsing the commands we are sending to the webpage? Are they saying since it is a server basically running an application the server is sending the commands itself to the application and not the web portion of the site?"

Please disregard the above preliminary results. It has been confirmed that the vulnerability report is correct. The results can be reproduced with older versions of the Web Console. The initial test was performed with the latest 7.5 release.

How to resolve it:
Option 1: Upgrade web server to the latest version of Apache Tomcat 9.x release branch. Here is a link to the download page https://tomcat.apache.org/download-90.cgi
Get .zip or .tar.zip file, and extract it to the current installation, for example (c:\home\WebConsole or /home/24x7/WebConcole)

Option 2: Version 7.5 is supposed to be released next week. Upgrade to that version. Allow setup to upgrade the existing Web Console, that will upgrade Tomcat to 9.0.98 release

After upgrade the vulnerability test should result in a page error with org.apache.jasper.JasperException exception, which is ok. It won't let the bad value in the server parameter to pass through, and that would cause an error downstream, which is expected.

SysOp wrote:

Please disregard the above preliminary results. It has been confirmed that the vulnerability report is correct. The results can be reproduced with older versions of the Web Console. The initial test was performed with the latest 7.5 release.

How to resolve it:
Option 1: Upgrade web server to the latest version of Apache Tomcat 9.x release branch. Here is a link to the download page https://tomcat.apache.org/download-90.cgi
Get .zip or .tar.zip file, and extract it to the current installation, for example (c:\home\WebConsole or /home/24x7/WebConcole)

Option 2: Version 7.5 is supposed to be released next week. Upgrade to that version. Allow setup to upgrade the existing Web Console, that will upgrade Tomcat to 9.0.98 release

After upgrade the vulnerability test should result in a page error with org.apache.jasper.JasperException exception, which is ok. It won't let the bad value in the server parameter to pass through, and that would cause an error downstream, which is expected.

I think I will just wait for the new release. It would be good to know how to upgrade just the tomcat though. is it jsut a matter of unzipping the files and placing them into the webconsole folder? or is there more to it.

Backup files, stop service, unzip, restart service should be sufficient. If anything, restore files from backup (step 1)

	SysOp wrote:
	Backup files, stop service, unzip, restart service should be sufficient. If anything, restore files from backup (step 1)

I just tried that and migrated the server and web.xml files over and when i go to the URL i get the Apache 9.0.100 welcome page "If you're seeing this, you've successfully installed Tomcat. Congratulations!"

SysOp wrote:

Please disregard the above preliminary results. It has been confirmed that the vulnerability report is correct. The results can be reproduced with older versions of the Web Console. The initial test was performed with the latest 7.5 release.

How to resolve it:
Option 1: Upgrade web server to the latest version of Apache Tomcat 9.x release branch. Here is a link to the download page https://tomcat.apache.org/download-90.cgi
Get .zip or .tar.zip file, and extract it to the current installation, for example (c:\home\WebConsole or /home/24x7/WebConcole)

Option 2: Version 7.5 is supposed to be released next week. Upgrade to that version. Allow setup to upgrade the existing Web Console, that will upgrade Tomcat to 9.0.98 release

After upgrade the vulnerability test should result in a page error with org.apache.jasper.JasperException exception, which is ok. It won't let the bad value in the server parameter to pass through, and that would cause an error downstream, which is expected.

I am still getting flagged for this vulnerability on v7.5.

Thank you