I’m 1 vulnerability away from achieving PCI compliance per McAfee’s scan. The dubious “open redirect” remains.

My EE/CartThrob add to cart form returns to “/checkout/review”, but McAfee’s scanner sees that as a vulnerability, whereby a nefarious user changes that url to SomeBadURL.com without the user knowing what occurred.

Medium User specified URL redirection (Open Redirect) 80/tcp Web Application Fail Description A parameter has been identified that can be modified to redirect clients to a user controlled page. An attacker could potentially construct a URL that will redirect a victim to a site that they control. This type of attack is typical seen in phishing attacks where the user is presented with a valid link on the site (i.e. http://www.mcafeesecure .com/main.jsp?state=4&page=http://mcafeesecure-evilsite.com) and mcafeesecure.com redirects the user to mcafeesecure-evilsite.com (T he site the attacker controls). The fact that the server name in the modified link is identical to the original site helps the attacker by giving his phishing attempts a more re liable appearance. CVSS Score 4.3 CVSS Fingerprint AV:N/AC:M/Au:N/C:N/I:P/A:N Solution Remove the parameter that allows redirection from your site. If the parameter is required for operation then construct a list of valid links tha t the user can be redirected to [White List] and any other links that are specified the user will not be redirected to.

Relevant Form Code:

<form method="post" acti  addFormSubmit()" >
<div class='hiddenFields'>
<input type="hidden" name="XID" value="cc7bade5265c13b73a6393f3e0b2db391bd9fdaa" />
<input type="hidden" name="ACT" value="22" />
<input type="hidden" name="RET" value="http://MyDomain.com/MySegment1/MySegment2" />
<input type="hidden" name="URI" value="MySegment1/MySegment2" />
<input type="hidden" name="FRM" value="f9cb7fd2ec650ab25efd8be6e1c59edb" />
<input type="hidden" name="return" value="checkout/review" />
<input type="hidden" name="secure_return" value="yes" />
<input type="hidden" name="AUP" value="WfGXMcTWPOx1XVmFt6LvlI2aYd+YVbZxexIi7hSShFylpXgvWrYjuNLJOB5OY2+BoZWFRV2ZQxxVlW5Ds0pD2g==" />
<input type="hidden" name="AUS" value="fLSHnnXdrpDnGlbvirXr2Z6/4Hg6o/DaSovhbCDs6BK1Me1qV3HHtKD9+DAcDb7RnuEylWkHFN+v0mYiHDoH4w==" />
<input type="hidden" name="AUW" value="FVT0uiqYd/WKlwoJEHb6mvxxD0J8su77K03FcJx8Z49iomBhCmGzlzvplboiFxCXmGIW0oDBXNDWjVTpI/1icQ==" />
<input type="hidden" name="OTF" value="ksN4R7uwmGvsP9G5z+aRoD25vvgiijPjryLML2QAZX8oDM9fpXUrczcqbIMyTY/lWhaui0i7WdF6FrjM5X5qNg==" />
<input type="hidden" name="JSN" value="uYa6FVq5nf8lhBvSBI2gfa4BIw1RJahHoB6xgPGwytgq56MKs9QoRuouIfUYb5jMsXHbiaZftDuJ2DQML7JXtg==" />
<input type="hidden" name="NTX" value="5HSxCqnvnmVKqDz47jAEnMkL06VTktf5VpOzWZ7VOQ2FnGBcm6O+Qmof1a6x7TYmhVKnr9aia7F41IcpQL1d6Q==" />
<input type="hidden" name="NSH" value="4WarxeRUR3TVn1xKBwFgxyWaByb40ZYeMiIx0npn3E+Ng2NEYhkac7r0UNz75+etGeea0iJdBta62f16cWxUXg==" />
<input type="hidden" name="ERR" value="csHkHXrepr1d3tkjOXErV5ovWAU9HjZFWcgVO/Qna4jn/gkb2hCqXiCaOPoR2U+nTJW2MQKhRrqXgbdsSAN0zA==" />
<input type="hidden" name="RLS" value="Kf2tDiVLXg82Dc2z3iQ+IhzTWfltitqVgB7GPCMyh04ytU1DaxkjXxzDY6SA1vD/rPLxTbVYFfpi3SBFIx6p1w==" />
<input type="hidden" name="site_id" value="1" />

McAfee is hung up on this particular line:

<input type="hidden" name="return" value="checkout/review" /> 

I can’t see any obvious EE resources (or Cart Throb) that address this issue.

Does anyone know of a workaround?

  • Seems like it would work 100% if it were just an encrypted value like the others. Only way I know how to work around this is to hack the CT code, or write an extension to encrypt that string and decrypt after the form processes. Would be interested to see what others say though. Sep 13, 2013 at 15:06
  • 1
    Which version of EE are you using? This came up for us recently with some non-cartthrob forms on our site. It's to do with the return parameter. EllisLab provided us a fix, but we haven't been able to test it yet because we're waiting on some other updates. But i believe they also added the patch into EE 2.7. I was surprised the no-one else had ever come across the problem before as it is a pretty big deal for EE security. Sep 19, 2013 at 15:04
  • 1
    This one is 2.5.5. I have a CartThrob site on 2.7 that I'll try - good call! Oct 9, 2013 at 2:08
  • 2
    @user1763, did updating to EE 2.7+ fix this for you? Oct 30, 2013 at 12:10

1 Answer 1


One workaround I can think of is to use Cartthrob's very own encrypted string.

This may work whereby you would encrypt both or either parts of the segment in the return value, then decrypt them when displaying the entry. Or at least make it more secure if the message still exists. See http://cartthrob.com/docs/tags_detail/view_encrypted_string/ and http://cartthrob.com/docs/tags_detail/view_decrypted_string/index.html

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.