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
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.
Bookmarks