-
1. Re: jboss-4.2.2.GA XSS vulnerability
peterj Apr 30, 2008 1:18 PM (in response to ltgoof)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 May 1, 2008 5:33 PM (in response to 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 May 2, 2008 2:29 PM (in response to ltgoof)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 May 5, 2008 10:54 AM (in response to ltgoof)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 Jun 3, 2008 5:30 PM (in response to 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 Jun 3, 2008 5:47 PM (in response to 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 Jun 3, 2008 6:03 PM (in response to ltgoof)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.