7 Replies Latest reply on Jun 3, 2008 6:03 PM by peterj

    jboss-4.2.2.GA XSS vulnerability

    ltgoof

      Hi I'm new to JBoss, I dowloaded and implemented jboss-4.2.2.GA. I applied for an electronic payment validation solution. To comply, the solution provider evaluated our website by doing a scan.

      To cut the story short, they game me a report that our website is NON-COMPLIANT due to Application Server XSS Vulnerability. And advised me to get a patch from our vendor. Since I'm using an open source version, I check JBoss.org website if there is a new release or patch for this and found nothing.

      Is there any patch to resolve this?

      Thanks for your help.

        • 1. Re: jboss-4.2.2.GA XSS vulnerability
          peterj

          It would help if they told you which app has the XSS issue.

          Also, have you locked down the server? See http://wiki.jboss.org/wiki/SecureJBoss

          • 2. Re: jboss-4.2.2.GA XSS vulnerability
            ltgoof

            Thanks Peter J.

            On the report it says "HTTPD server can be used as a relay for Cross Site Scripting attacks." I think they are pertaining to Tomcat.

            "Solution: See your vendor for an upgrade or patch. The nature of the solution will depend on the affected web server."

            Hope that says a lot as the report wordings seems to be so general and vague.

            Thanks also for the link, on how to lockdown jboss.

            Regards,

            Mylon

            • 3. Re: jboss-4.2.2.GA XSS vulnerability
              peterj

              The report makes no sense. Adding the Apache HTTP Server (I think this is what they meant by HTTPD) into the mix will not stop XSS attacks (unless that Server has some XSS filters I don't know about). But then, it is fairly easy to build XSS filtering into any app. And it is applications, and not application servers, that have the XSS vulnerability.

              The OWASP site contains a fairly good description on what makes up an XSS vulnerability and how to prevent it: http://www.owasp.org

              • 4. Re: jboss-4.2.2.GA XSS vulnerability
                jfclere

                Without a complete description of the XSS, the report
                you have is useless. Once you have a complete description send it to security@tomcat.apache.org.

                • 5. Re: jboss-4.2.2.GA XSS vulnerability
                  ltgoof

                  Thanks again for all your inputs. Here is the part of the PCI scan report that I got. Hope this helps.

                  Applications:
                  Port Service Applications
                  80 HTTP Apache Tomcat HTTP
                  80 HTTP Spidered Web Pages
                  443 HTTPS Apache Tomcat HTTP
                  443 HTTPS HTTP-Based Application
                  8080 HTTP Apache Tomcat HTTP
                  8080 HTTP HTTP-Based Application
                  8443 HTTPS Apache Tomcat HTTP
                  8443 HTTPS Spidered Web Pages

                  Vulnerabilities:
                  HTTPD Cross Site Scripting
                  CVSS Score: N/A PCI Score: 4 IP360 Score: 347 nCircle ID: 1601 Port: 8080 Not Compliant
                  Description
                  HTTPD servers can be used as a relay for a cross site scripting attacks. The vulnerability can occur in a wide variety of http
                  servers; the reporting of this vulnerability indicates that a web server has been demonstrated to be vulnerable. Cross site
                  scripting occurs when a web form or error page returns user-specified data in its response. This can allow a malicious user
                  to create a link to that page or form that can allow arbitrary script code to be run in a third-party user's browser through a
                  web link. The third-party user will most likely be induced to click on this link from another website, instant message, or
                  email. This type of attack can allow the stealing of credentials, cookies, or other sensitive data by the creator of the web
                  link. For example, consider a link off of a page from a hostile website: http://TrustedServer. If a user clicks on the link specified above, the script will get passed in the
                  http request from the client to TrustedSite. TrustedSite will then return the script as part of the error message. The client,
                  receiving the error page containing the script, will then execute it and assign to it all rights granted to content from
                  TrustedSite. More information about cross site scripting vulnerabilities is available at
                  http://www.cgisecurity.com/articles/xss-faq.shtml.
                  Solution
                  See your vendor for an upgrade or patch. The nature of the solution will depend on the affected web server.
                  Advisories
                  nCircle CVSS Base Vector: (AV:N/AC:M/Au:N/C:P/I:P/A:N), nCircle CVSS Base Score: 5.8, nCircle CVSS Temporal
                  Vector: (E:F/RL:U/RC:C), nCircle CVSS Temporal Score: 5.5

                  Page 3

                  HTTPD Cross Site Scripting
                  CVSS Score: N/A PCI Score: 4 IP360 Score: 347 nCircle ID: 1601 Port: 443 Not Compliant
                  Description
                  HTTPD servers can be used as a relay for a cross site scripting attacks. The vulnerability can occur in a wide variety of http
                  servers; the reporting of this vulnerability indicates that a web server has been demonstrated to be vulnerable. Cross site
                  scripting occurs when a web form or error page returns user-specified data in its response. This can allow a malicious user
                  to create a link to that page or form that can allow arbitrary script code to be run in a third-party user's browser through a
                  web link. The third-party user will most likely be induced to click on this link from another website, instant message, or
                  email. This type of attack can allow the stealing of credentials, cookies, or other sensitive data by the creator of the web
                  link. For example, consider a link off of a page from a hostile website: http://TrustedServer. If a user clicks on the link specified above, the script will get passed in the
                  http request from the client to TrustedSite. TrustedSite will then return the script as part of the error message. The client,
                  receiving the error page containing the script, will then execute it and assign to it all rights granted to content from
                  TrustedSite. More information about cross site scripting vulnerabilities is available at
                  http://www.cgisecurity.com/articles/xss-faq.shtml.
                  Solution
                  See your vendor for an upgrade or patch. The nature of the solution will depend on the affected web server.
                  Advisories
                  nCircle CVSS Base Vector: (AV:N/AC:M/Au:N/C:P/I:P/A:N), nCircle CVSS Base Score: 5.8, nCircle CVSS Temporal
                  Vector: (E:F/RL:U/RC:C), nCircle CVSS Temporal Score: 5.5

                  HTTPD Cross Site Scripting
                  CVSS Score: N/A PCI Score: 4 IP360 Score: 347 nCircle ID: 1601 Port: 8443 Not Compliant
                  Description
                  HTTPD servers can be used as a relay for a cross site scripting attacks. The vulnerability can occur in a wide variety of http
                  servers; the reporting of this vulnerability indicates that a web server has been demonstrated to be vulnerable. Cross site
                  scripting occurs when a web form or error page returns user-specified data in its response. This can allow a malicious user
                  to create a link to that page or form that can allow arbitrary script code to be run in a third-party user's browser through a
                  web link. The third-party user will most likely be induced to click on this link from another website, instant message, or
                  email. This type of attack can allow the stealing of credentials, cookies, or other sensitive data by the creator of the web
                  link. For example, consider a link off of a page from a hostile website: http://TrustedServer. If a user clicks on the link specified above, the script will get passed in the
                  http request from the client to TrustedSite. TrustedSite will then return the script as part of the error message. The client,
                  receiving the error page containing the script, will then execute it and assign to it all rights granted to content from
                  TrustedSite. More information about cross site scripting vulnerabilities is available at
                  http://www.cgisecurity.com/articles/xss-faq.shtml.
                  Solution
                  See your vendor for an upgrade or patch. The nature of the solution will depend on the affected web server.
                  Advisories
                  nCircle CVSS Base Vector: (AV:N/AC:M/Au:N/C:P/I:P/A:N), nCircle CVSS Base Score: 5.8, nCircle CVSS Temporal
                  Vector: (E:F/RL:U/RC:C), nCircle CVSS Temporal Score: 5.5

                  HTTPD Cross Site Scripting
                  CVSS Score: N/A PCI Score: 4 IP360 Score: 347 nCircle ID: 1601 Port: 80 Not Compliant
                  Description
                  HTTPD servers can be used as a relay for a cross site scripting attacks. The vulnerability can occur in a wide variety of http
                  servers; the reporting of this vulnerability indicates that a web server has been demonstrated to be vulnerable. Cross site
                  scripting occurs when a web form or error page returns user-specified data in its response. This can allow a malicious user
                  to create a link to that page or form that can allow arbitrary script code to be run in a third-party user's browser through a
                  web link. The third-party user will most likely be induced to click on this link from another website, instant message, or
                  email. This type of attack can allow the stealing of credentials, cookies, or other sensitive data by the creator of the web
                  link. For example, consider a link off of a page from a hostile website: http://TrustedServer. If a user clicks on the link specified above, the script will get passed in the
                  http request from the client to TrustedSite. TrustedSite will then return the script as part of the error message. The client,
                  receiving the error page containing the script, will then execute it and assign to it all rights granted to content from
                  TrustedSite. More information about cross site scripting vulnerabilities is available at
                  http://www.cgisecurity.com/articles/xss-faq.shtml.
                  Solution
                  See your vendor for an upgrade or patch. The nature of the solution will depend on the affected web server.
                  Advisories
                  nCircle CVSS Base Vector: (AV:N/AC:M/Au:N/C:P/I:P/A:N), nCircle CVSS Base Score: 5.8, nCircle CVSS Temporal
                  Vector: (E:F/RL:U/RC:C), nCircle CVSS Temporal Score: 5.5

                  • 6. Re: jboss-4.2.2.GA XSS vulnerability
                    ltgoof

                    What confuses me is the Solution provided, that issue can be addressed by a patch.

                    I have purchased JBoss Application Platform 4.3.GA_CP01 hoping that this issue will be resolved by the current release/patch but still I got the vulnerablity issue.

                    I have read the example given on the link and most of them are on the application side, filtering metacharacters that user/client sends to the server.

                    I have also created a case on JBoss Security, and they are looking at this.

                    Please help.

                    • 7. Re: jboss-4.2.2.GA XSS vulnerability
                      peterj

                      The report is useless. Telling you what an XXS attack is and saying "go get a patch" is not help. An XSS attack requires that a particular web page not filter out input from a user, and when that input get displayed, the XSS attack occurs. Without knowing which pages the tool checked, nothing can be done.

                      It seems to me as if the tool is saying "hey http is open, and Tomcat has it opened, and Tomcat doesn't do anything by itself to stop XSS, so **FAIL***".

                      As far as I know, no HTTP server actively filters user input. Though I do know of at least one product that will do this for JBossAS. I image that you could also write a filter for Tomcat to do this.