"Illegal URL format"

I'm not sure I'd recommend against using any component with such little information, but they're their own company.

Anyways, no, I've not heard of that before. I'm curious to know when this happens. Is it after you actually use your Facebook credentials to log into the site, and upon redirection back to your site? There's only a little control we have over the return URL as some of it's generated by Facebook itself. If you could give me a the offending URL, we'd gladly dig into it further to see if we're doing anything that we could be doing better.

If there's any information that security people can provide as to 'what' is illegal about the URL, that would help too. The web is built on standards, but browsers (and therefore developers like us) can not always do things by-the-standards because until we know about it, it isn't really a problem. Hope that makes sense.

Anyways, we'll get you up and running, don't worry about that.. might just take a little extra effort

Thanks for the description. I missed above where you mentioned the 'return' variable.

I'm still kind of unsure where the issue is coming from. Variables in URLs can be named any ASCII values (ex. return) and the value of that variable can be BASE64 encoded (which is what we're doing). While BASE64 can be used for nefarious things since it obfuscates the real value, it's not a direct security risk. Additionally, Joomla uses base64 throughout in URLs and POST forms.

If you have any more info from the vendor, or can pass this info along, we'll definitely do what we can to get to the bottom of it. It's trivial for us to change the variable name of 'return' to 'gotolocation', but if that's the problem, that doesn't seem like it's very proactive security. As for using BASE64 encoding, there's not much we can do about that as we need to hand Facebook a URL which it, eventually, needs to hand back to us so that we can get the user back to the correct page on your site after logging in.

Keep us posted, and if you can't get anywhere with the security vendor, let us know and we'll contact them. We don't like people recommending 'not' to use us

Yes, we definitely base64 encode the URL. Otherwise, it simply wouldn't work.

I'm not sure how the plugin ordering would affect this because I'm not sure how their plugin operates (scans the HTML on the page, looks at the incoming URL, looks at POST/GET variables, etc), but hopefully their solution works.

Definitely let us know how it goes.

That URL that's been denied is from Facebook itself. We have no control over it. The variables that are passed in that URL are what let's your site ultimately get an authorization token for the user to interact with your site through Facebook.

I've never heard that multiple forward slashes are a security risk, and I'm not sure why 2 is ok, but 3+ is bad. A quick search didn't turn anything up either, but that's a hard question to search for.

As for converting the data from a GET to a POST, again, we have no control over it. Also, again, I'm unsure why that parameter would be considered "safe" in a POST value but not a GET value when it contains the same data.

Sorry for the non-helpful answers. We know Facebook Connect works on many servers with other Joomla Firewall solutions, Suhosin PHP (secure PHP), CSF/LFD (common Linux Firewall). I'm not sure why Security Live is protecting these URLs. I completely agree with all the secruity you can get, but it doesn't seem correct both from what I've read and from the fact that no other security providers seem to lock down these URLs.

Feel free to post anything else you figure out, but from our end, I don't think there's much more we can do. The next step would be to contact Facebook, if they really are providing non-conformant URLs. Even if they are though, I don't think they'd be too receptive to correcting it.