john_roberts

Just a quick follow up.. The POST cleaning snippet in Sam's link did the trick for thwarting my immediate "cross site scripting" vulnerability. My website is now passing PCI compliance tests. I realize this is an ongoing process, so thank you all for the help and good info. John Roberts PS: I found several routines that use POST, to input data that weren't flagged as problems by the PCI scan. I went ahead and protected everything I could find.

Thank You Sam.. I had already made some of those patches. I didn't recall seeing that _post cleaner. But I am learning as I clean.... I just dropped that " clean posted vars" snippet into my two login files and it looks like it is working.. Time for another PCI compliance scan. Finally some visible progress. More work to go, but thanks again.. John Roberts

I think I'm getting the picture. Security pro protects GET My webstore uses POST. Wrong tool for my problem. Thanks John Roberts

Thus my quandry. I installed it. I turned it on in Admin. I still fail PCI compliance due to XSS vulnerability ======== I really appreciate being able to talk to the man who wrote this. Thank you for your response. I have just run some more experiments and using the "[w](o)%3Cr%3Ek|i*n^g" test string I can only get a cleaned ("working") result when I enter this into the credit card name field, at check out from the shopping cart. Every other entry data field I tested remains uncleaned. This proves that the routine works, it just isn't being called for every input data capture. My compliance test is identifying the (customer and admin) login routine for XSS vulnerability. Does any of this make sense? My assumption is that it would clean more than that one field. (I have no files excluded in admin.) I guess I need to dig back into the PHP code and see what is different about the CC name field that allows it to work, and everything else that doesn't? I believe there are some specialized validation routines to test CC numbers etc. Thanks for any help. John Roberts

I have been wrestling with PCI compliance and cross site scripting is my last major nut to crack. This white-file(?) replacement is exactly what I need. (Thank You) I am not very fluent with PHP code, but I have managed to get most add-ins to work over a few years. I am having no success with this FWR security pro add in. I have run the install program . I have put the security.php file in ...(formerly called catalog)/includes/functions I have added the new code in ...(formerly catalog)/includes/application_top.php I have turned security pro on (true) in admin configuration I get no cleaning of entered text. It's not [w](o)%3Cr%3Ek|i*n^g I tried uninstall and re-ran install program. I have added some echo code in application_top to confirm that security pro is "true", it is.. I added and removed some echo code in application_top to confirm that cleaning function exists and is found. it does in security.PHP I conformed that !array is true. I repeat I am not very competent with PHP code so I may be missing something simple. My "catalog" directory goes by another name, but this is reflected in configuration area and (AFAIK) the store has been working fine for years. When I type fwrtest=[w](o)%3Cr%3Ek|i*n^g in browser string, I get fwrtest=[w](o)<r>k|i*n^g response. I am working beyond my ability to debug in PHP. Anything simple I may be overlooking? My head hurts. John Roberts Note: still running 2.2rc2a but corrected for deprecated PHP functions when upgraded server to newer version PHP in PCI compliance process. May still be a few clinkers, but don't get any deprecated function errors.