The main you need to know about cross site scripting is that any time a form submits data or a query contains data which is then displayed on the page, that data should first be escaped in some way before being displayed. The main functions used for this are:

1. strip_tags() to remove HTML characters in favor of plain text
2. htmlspecialchars() or htmlentities() to display HTML in a way that is readable, but won't be interpreted by the browser.

The other big thing is that you should keep the register_globals in php.ini turned OFF. It is off by default now days, but it didn't used to be, and a lot of servers still keep it on. This was a very poorly thought out directive as it allows anyone to take over any empty variable on the page by simply querying it ?var=value.

XSS, if successful, lets malicious users do all sorts of nasty things.

Originally Posted by chrishirst

No no, it's because "product_page.php" is there.

Passing a target page is what makes it potentially a weakness, because an "attacker" could replace "product_page.php" with "remoteURI.tld" and if you have failed to "sanitise" the GET parameters, could be including the content from or redirecting to that remote URI.

Ok, a long shot but...

Would adjusting the code that generates the buy button that TAKES you to the basket stop the "product_page" from being inserted?

** EDIT **

Ive now got the URL displaying as basket.php?src=Array&productID=123456

Would this be any better PCI wise??

It should be because possible hackera can now only alter the product IDs, and provided your receiving code "cleans" the values for injection attacks there is limited scope for hijacking or malicious attacks.

Wow! may be getting somewhere here!

Running another scan so I'll let you know!

Indy-Dance.gif

Nope.... scans finished and Still comes back as a security fault...

Are you processing card information on your own site or are you using a payment gateway?

PCI is all about protecting financial data inside your own systems both online and offline.
If you change domains to process the card data it may be possible that the test process could be detecting this as a possible XSS vulnerability.

Processing on own site. (info being sent to us, then manually running through PDQ terminal.)

On the SQL injection side of this, these two videos may help you to understand what this threat is all about a little better:

Part 1: http://www.youtube.com/watch?v=YyaQw0ae_7I

Part 2: http://www.youtube.com/watch?v=e4EYkoLlSq0

again... a long shot but...

Could I use ModRewrite to change the url to something better??

Originally Posted by rolda hayes

again... a long shot but...

Could I use ModRewrite to change the url to something better??

You can, absolutly, but it wont remove the risk of someone injecting into your variables. You will still need to clean the input and do some data validation/sanitisation.

Originally Posted by rolda hayes

again... a long shot but...

Could I use ModRewrite to change the url to something better??

You can and does disguise the nature of the URL somewhat so it may well fool the scanner

Originally Posted by Phunk Rabbit

You can, absolutly, but it wont remove the risk of someone injecting into your variables. You will still need to clean the input and do some data validation/sanitisation.

Agreed. No matter what method is used to construct the URIs, user input should be "cleaned". Especially when passing data via a GET method.

Ok, an update on things...

I've added:

PHP Code:

$_POST = filter_var_array($_POST,FILTER_SANITIZE_STRING);
$_GET = filter_var_array($_GET,FILTER_SANITIZE_STRING); 


to the top of the page, and this is stopping the pop up window injection when testing the URL.

What they are (now) saying... is that indeed the url must be cleaned and it should not show in the href= of the page.

so I need to remove the end of the generated URL:

basket.php?src="><script>alert(123)<%2Fscript>&amp =&productID=1126558"



Any ideas now where to go??

All the link should need (and have) is the product ID ref

I don't think that the filter_var_array() function is going to be enough to sanitize your data. I'm fairly certain that you'll still be open to SQL Injection. From what I can tell, you're just basically using it to strip tags, which isn't enough. You'll want to use mysql_real_escape_string() for anything that you're putting in a database query. You'll find the PHP Security Consortium a very helpful resource as it will explain about the different types of attacks and how to prevent them. There are quite a few that this code is vulnerable to and I'd suspect that you'll have to look at every single file individually. It only takes one vulnerability to compromise a site, so you could be 99% covered and it doesn't matter if an attacker finds that last 1%.

I AM PCI COMPLIANT!!!!!

A big thanks to everyone who has contributed to this thread!!!


Indy-Hat-Tip.gif