NuSOAP - SOAP Toolkit for PHP

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 [at] 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['PHP_SELF'] 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)

Patch: http://git.mantisbt.org/?p=mantisbt.git;a=commitdiff_plain;h=edb817991b99cd5538f102be26865fde7c6b7212 MantisBT bug report (for feedback on the patch and the initial discovery of this issue): http://www.mantisbt.org/bugs/view.php?id=12312 RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=629585 Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595248

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

Is there really a need for keeping the things that may be appended to index.php to access the index.php?wsdl (hence using htmlentities() or htmlspecialchars() ) ? Me thinks that just doing : $PHP_SELF = substr($_SERVER['PHP_SELF'], 0, (strlen($_SERVER['PHP_SELF']) - strlen($_SERVER['PATH_INFO']))); could be fine. See my proposed patch : http://git.debian.org/?p=users/olberger-guest/nusoap.git;a=blob;f=debian/patches/595248.patch;h=6af3d725fe74d839764d9755c5bb18458a192518;hb=268f03b88c6900d1a87b17734c248c705c22cb07

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.

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.

I haven't checked in detail the other variables that are echoed, but I think they're there to provide the docs for the web service in the page, so I think they're generated from the program's API and thus harmless XSS-wise. But just my guessing having read quickly through. I've now prepared a patched Debian package that will hopefull include the following patch (both for 0.7.3 and 0.9.5) : see latest commits in http://git.debian.org/?p=users/olberger-guest/nusoap.git;a=shortlog;h=refs/heads/testing-security and http://git.debian.org/?p=users/olberger-guest/nusoap.git;a=shortlog;h=refs/heads/debian Hope this helps. Best regards,