Apparently 'I am vulnerable to XSS attacks' ??

[hkalchemy]

Hope someone can help me - I'm completely stuck.

My s2 member pro plugin isn't directing customers back to my site from Clickbank. I'm getting an 'Error 503.'

I wrote the the host company and this is their reply:

You really shouldn't pull in data based off what's in the URL. I assume you're using allow_url_fopen to do this and it's disabled for security reasons. If your site is using URL's like "http://effortlessabundance.com/?s2member_pro_clickbank_return=1&s2member_pro_clickbank_return_success=http://effortlessabundance.com/thanks-for-your-purchase" then you are very vulnerable to XSS attacks.

I have no idea what this means. How can I get the plugin to work? And what is an XSS attack? I assume the developers have figured all this out and that it's secure etc., but I'm just an ordinary person with no technical knowledge. I don't really want to know WHY or HOW it works - I just want it to work. Help!!

[Jason Caldwell]

Thanks for reporting this important issue.

Yes, I've seen this happen in the past. This has to do with the mod_security extension for Apache, which is sometimes paranoid about certain types of query strings. Please see this thread for further details on this topic and possible solutions: viewtopic.php?f=36&t=14787

Please understand that s2Member takes security precautions to ensure that code injections are not possible through query string data that it processes. In this specific example, there is only ONE possible exploit that I'm aware of, and that has to do with "where" a Customer is redirected to exactly.

When this URL is passed to s2Member, is it first sanitized by s2Member in case of an XSS attack. Once s2Member is finished processing the Auto-Return data from your Payment Gateway, the Customer will be redirected to the URL that you specified, so long as it did not contain any code injections. Though NOT likely, it is possible for the redirection URL to be changed to some other valid URL, leading a Customer away from your site. So this is the only method of attack that I'm aware of in this regard.

I'll see what we can do to avoid this methodology in a future release, as support for Signed URLs is added to the s2Member core. Until then, this is a low-level vulnerability, which is NOT likely to even occur, since the URL query string is formulated by s2Member itself, passed through your Payment Gateway, and only seen upon return from your Payment Gateway with an authenticated/verified transaction.

[hkalchemy]

Many thanks for your reply, Jason.

[Jason Caldwell]

Very welcome.