XSS (cross-site scripting vulnerabilities)

Help
2010-09-01
2013-06-06
  • Bogdan Calin
    Bogdan Calin
    2010-09-01

    Hello!

    My name is Bogdan Calin. I'm a security researcher at Acunetix (http://www.acunetix.com).
    You can contact me at this email address: bogdan  acunetix.com

    I wanted to contact you on a private channel (because I'm reporting security issues), however the only contact information I could find was this forum.

    I would like to report a list of XSS vulnerabilities in NuSOAP.

    In various files contained in the NuSOAP library, you echo the contents of the $_SERVER variable without properly encoding it.

    Here are a few cases (I'm using the latest version of NuSOAP, version 0.9.5):
    Filename lib\nusoap.php, line 5429

    <p>View the <a href="'.$PHP_SELF.'?wsdl">WSDL</a> for the service.
    

    $PHP_SELF is initialized before as

    $PHP_SELF = $_SERVER['PHP_SELF'];
    

    Same situation in file class.wsdl.php, line 847

    <p>View the <a href="'.$PHP_SELF.'?wsdl">WSDL</a> for the service.
    

    This makes it vulnerable to XSS. By using an URL like

    http://site/filename.php/1%3CScRiPt%3Eprompt(923395)%3C/ScRiPt%3E

    it's possible to execute Javascript code.

    Our scanner found an XSS vulnerability in a popular application that is using NoSOAP and that's how we got to you.

    I hope you will fix this problem. Thanks in advance and have a nice day!
    Bogdan

     
  • (Monitoring)

     
  • Olivier Berger
    Olivier Berger
    2010-09-03

    @dhx1 Why use htmlentities() and not htmlspecialchars() ?
    Also, why not just protect the definition of $PHP_SELF instead of all of its uses ?

     
  • Olivier Berger
    Olivier Berger
    2010-09-04

    Oh, and Btw (thanks to Raphael Geissert who made me notice), the PHP_SELF use for the ?wsdl link is useless. It's enough to do …<a href="?wsdl">…

    I think that's gonna be the patch I'll include in an updated Debian package.

     
  • David Hicks
    David Hicks
    2010-09-04

    Thanks Oliver, I agree with your comments about my patch. I had made it in a hurry and as such made it overkill (htmlentities vs htmlspecialchars, escaping every variable echoed) to ensure that it was 100% safe vs the most efficient/elegant solution. The section of code affected strikes me as being hard to read/understand (joke variable names, etc) so I was trying to use the simplest approach.

    I'm not too keen on the substr() approach you've suggested as it doesn't seem to acknowledge that any part of the path could contain special HTML characters. While it wouldn't necessarily be a security issue (however it could turn into a security problem), it'd still be possible to produce invalid HTML output.

    If it's possible to remove the echoing of PHP_SELF entirely (or replace it with ?wsdl as suggested) then I'd go with that approach. I was also mindful of the other variable names that were being echoed and whether they need escaping too. Because the variable names are obfuscated I couldn't be bothered wasting time figuring out what the variables could contain (whether the user sets them, etc).

    Hopefully upstream can look into this soon.