I ran a pen-testing app and it found a ton of XSS errors, specfically, I’m guilty of echo’ing unverified data back to the browser through the querystring.
Specifically, running this puts javascript into my page. http://www.mywebsite.com/search.php?q=%00” [ScRiPt]%20%0a%0d>alert(426177032569)%3B[/ScRiPt].
Thankfully, no where do I let users save data to a database and display back to other uesrs, so I THINK people would only be able to hack themselves with this problem, but I still want to fix it.
The recommendation is to do this:
echo htmlentities($_POST[‘input’], ENT_QUOTES, ‘UTF-8’);
But currently I need to get this patched up asap, then go fix on a case by case basis. I have a header file I include on every page on the site, I know it’s bad form, but what could blow up if I did:
array_walk($_POST, 'htmlentities');
I’ll need to do it for COOKIE and GET as well. I never use _REQUEST.
Thanks
HTML-escaping on the way in is obviously The Wrong Thing, but could be a temporary fix until you replace the code with something proper. In the long term it would be unmaintainable and you’ll have loads of weird application-level errors anywhere you start doing substring manipulations (including truncation, which your database may do automatically) across &-encoded characters. It’s not that likely to lead to security breaches, although you can’t tell without looking at the app in a lot more detail.
If you start encoding things in $_SESSION each time, you’ll get multiply-encoded too-long strings like & very quickly.
Or, an attacker on another web page could redirect or iframe to yours, with enough script injected to display a fake login box that looks just like your site’s, harvest the username and password or automatically delete their account. Stuff like that. Not very good.
No need for htmlentities and all those parameters – use htmlspecialchars.
You can save yourself a few keypresses using something like:
It’s really not that much extra hassle.