WorldPay Module version 2.0 - Support thread

I also emailed Worldpay support just to see what the progress was on this base href tags and this is the response I received:

We are still looking at the possibility of allowing base href tag. I will keep you updated once I get any information from our technical team in UK.

I will give them a week but after being on the verge of launching for my site a while now as I wait to know all the changes needed to take place, I guess I better start looking for alternatives.

I did notice though they changed the whitelist date to October 14th.

I will let you guys know if I hear anything further. And Philip, thanks again for all the effort you have put into making the module work.

Khalil

since they pull the page from "a domain" then it would be trivial to complete a pattern match to limit the base href to "a domain". The other thing that is going to really put a spanner in the works is for people with customised templates, since they are killing javascript, so bang goes any drop down menus, and if I recall, the xml spec that was posted killed external stylesheets, now I know a lot of people don't do this, but there are accessibility issues then for the disabled or even for printing out the page as a "receipt".

What I find remarkable is that I think these modifications are entirely unnecessary. The main use of an XSS attack would be present false information to the user (I have some knowledge of this and you may want to read this article about me :smartalec: and the concept from last week)

http://www.theregister.co.uk/2009/08...mail_xss_flaw/

To achieve an XSS attack on the WorldPay website in the manner they are trying to avoid, one would have to send out a mass email getting someone to go to a shop, buy something, pay for it, then either

• have the vicitims cookies stolen on a successful transaction and then a naughty hacker who had penetrated the website already (because they'd have needed to plant the tags to execute the cookie stealing code) would change the delivery address. This is exceptionally unlikely since the attacker/ cracker/ bad guy (my colleagues berate me for using the term hacker incorrectly) would already have been able to plant information, read data form the database by reading includes/configure.php so it would be a big waste of time and not very productive, it;s much easier to redirect the WorldPay/ other payment module form if one is on the server to complete a transparent man in the middle attack)
• present information under the WorldPay URL in the browser window that would be used to con people out of money which is very very unlikely since the victim would already have handed over the money. This attack relies on drawing in the information from a third party, but the cracker's already had access to the shop server so...

There's an easier way to do this which worldpay would have no defence against. One would create a "fake shop" or steal one, offering bargain goods, the attackers in this case would then be the shop owners or someone that had hijacked the shop complete with WorldPay details.

Instead of the "success" page one would swap it out for a totally new page that would say "your Mastercard secure code has not been accepted, please enter your details again". That new page could be correctly referenced without the need for a base href, would be displayed under the WorldPay URL and would pass all of their OWASP checks as it's not even cross site scripting, it would be a form (** see note at bottom) which would then post all of the data to Mr Bad Guy. Now that is a believable and real attack scenario.

This smacks of somebody not thinking things through, incorect interpretation of a middle management instruction or misunderstanding the concepts. Someone may want to point WorldPay in the direction of this post since I do not have a WP merchant account and therefore no phone contact.

Philip.

** from their antisamy xml specification

HTML Code:

---

<tag name="form" action="validate">

---

which means they allow it through.:oops:

Philip,

I responded to their email and basically told them that this decision is a make or break for me, because the resulting web page looks totally unprofessional. Their response was:

I will feedback your concern to our technical team in UK. My apologies for causing you inconvenience.

In all fairness to the guy I am in contact with, he is just a middle man.

However, I have copied your reply verbatim and asked him to forward it to their technical team for comment. I will let you know what kind of response I get.

Thanks again,
Khalil

I do know that you Khalil have the coding skills to be implement a page without needing the base href tags, but most shop owners will not be able to.

Below are images from the RBS worldpay site. These are XSS vulnerabilities on their very own website which took me less than 10 minutes to find this morning. :oops:

You'll see an Iframe with this thread appearing in it

[SCR]http://www.3xlock.com/rbs_xss.png[/SCR]


and then a JavaScript alert which means that the site could be entirely under the control of a "bad guy".

[SCR]http://www.3xlock.com/rbs_xss1.png[/SCR]

They should consider solving their own real problems before pointing the finger at other people's products.

Philip.

Hi Philip,
I've installed the latest module and all is working fine apart from the return page from worldpay.
The return page is stripping out the:
<base href="http://binderee.deewhy.ie/" />
Therefore some of the images are missing. I've fixed the stylesheets by forcing the complete url in the header but the site is not looking right at all.
The site url is http://binderee.deewhy.ie
Any help would be appreciated.

Thanks,
Philip Hayes

I you read the previous page, you'll find that tis was a recent worldpay development where some idiot in the RBS decided to implement a stupid policy that acheives no useful purpose.

The only suggestion that anyone can make is that you manually link every item and link in your templates because unfortunately there's bugger all the module can do to things once they are over worldpay's side.

Philip (the very p*ssed off module maintainer).

Thanks for the quick reply, I missed that from the previous threads.
I'll try and hardcode all the problematic links.
Great module btw, thanks for all your hard work on this.

Philip

Thanks again Philip,

I got a little impatient and emailed them again asking for an expected date on the decison whether they will or will not fix this. Here is the response I got:

I can confirm that this issue has been raised with our IT department along with some other changes we have raised with the whitelist and we are still awaiting a definite response on each of these issues.

We would expect to hear back on these certainly before September 23rd when the whitelist goes live however I cannot give you an ETA on this.

I would also suggest looking into changing the URL's on the result page to absolute URL's if possible as this will resolve the issue without the need for the base href tag in the meantime.

My apologies for the inconvenience caused by this.

I guess if I want to continue with Worldpay and launch sometime this century I will have to make the necessary change. I just wonder what else they may have in store down the road...

Khalil

I had already implemented this change of doing absolute URL's .....but for it me it still didnt quite fix as Worldpay were not pulling in the closing tags of <li>'s or <options>'s so the CSS was still not working correctly!!

I raised this with them ages ago as you have done......and i also get the same responses, about they are looking into it and everything!....I will be chasing them again myself next week probably and seeing what response i get.

If you do decide to do the absolute URLs way, i would still recommend checking that it is pulling in all the other closing tags etc.



The worst thing for me is, i have just had a new client come on the books who already has a worldpay account, but is unaware about the problems they have been having! So looks like im going to have another Worldpay site to try and fix! ....uh oh

Hello,

are the following changes included in Version 2.10?

"Reminder: Technical Changes Affecting Payment Processing
Dear Customer,

We would like to remind you of several service updates that we have previously notified you about.

PCI DSS changes - technical changes occuring between the 16th September and 27th September:


16th September: Payment Notification (Callbacks) IP Address Changes
17th September: Secure Test Environment and the Payment Page Editor will be unavailable for up to (approx) 4 hrs (rescheduled from 10th September)
26th September: Risk Management Service will be unavailable for up to (approx) 2 hrs
27th September: Recurring Payment Service (FuturePay) will be unavailable for up to (approx) 2 hrs
Subsequent changes / maintenance slots that have previously been communicated have also been rescheduled – more information on our Business Gateway Service News & Updates Page
Payment Pages - technical changes on 23rd September:


technical change that could affect display of RBS WorldPay payment pages

Please Get Ready: It's important you review these changes and, where indicated, cascade the information to those responsible for your website and its technical set-up beforehand, in order to ensure you can continue to accept payments without disruption when we make the changes."