The problem is that anyone can spoof the chrome proxy server so I can’t trust it. I can’t white list the chrome proxies because that would allow spammers to use it without being checked.
The issue is that the HTTP_X_FORWARDED_FOR meta information is not trustworthy and a programmer can put any value that she wants in it. The only choice is to not check for spoofing, but then the chrome IP addresses are probably listed in SFS and Honeypot because spammers have been using chrome.
This one of the many reasons that I have stopped developing this plugin. There are too many issues with things like this. IP address is a good way to identify a spammer until it isn’t.
Cloudflare has a plugin that verifies the cloudflare proxies. I don’t know if there is the chrome proxy equivalent.
Keith
Hi Keith,
It’s a pity that you stopped developing the plugin. ‘Stop Spammers’ is nice and powerful.
In our case would be fine to have an option to disable check for spoofing or disable IP address check at all. We rely more on email verification. Because I believe that we should not complicate life of users with captcha and in case of any moot point we should rely on presumption of innocence.
Btw, IP whitelisting does not work in case of spoofed IP.
Best regards,
Eugene
I have contacted somebody at Google. If they respond with the information they have requested then I could have a Chrome Data Compression Proxy plugin to fix the issue in a few hours.
If they don’t respond, we are all SOOL.
I will add the switch to turn off the feature when I get a chance.
My concern now is that the Google SPDY architecture is starting to proliferate and I think it does the same kind of proxy compression stuff.
The spammers are still winning.
Keith
Eugene Ionichev wrote:
Btw, IP whitelisting does not work in case of spoofed IP.
How do you spoof an IP on TCP? It requires a three-way handshake.
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment
It can only be spoofed if the plugin is using headers to try and determine the actual IP, which I do not believe it is doing anymore as Keith previously mentioned.
The IP isn’t spoofed, but the X-FORWARDED-FOR header can be spoofed with a fake IP.
I have a not-so-good solution for whitelisting proxy servers, suggested by someone at google who doesn’t understand the security issues. I have not released it because it is easy enough to take the spoof a little farther – raising the spoof to the next level. I had still hoping that Google has a way of proving that a particular IP is owned by google. They won’t publish a whitelist for me.
I might release a chrome compression proxy fix plugin, but not until I am a little more confident in it.
Keith
Ok. Till a brilliant idea comes, we have applied a following easy patch:
wp-content/plugins/stop-spammer-registrations-plugin/includes/stop-spam-reg-checks.php:
609a610
> /*
615a617
> */
As I mentioned above I believe that much better to pass some spammers than to kick some users.
I am rethinking the whole http-rewarded-for spoof thing. The real danger is that people will report invalid IP addresses to SFS. I should make it so that the ip will not be reportable.
That way, a spammer can still spoof the IP and leave spam, but the technology to spoof headers is still not a thing to worry about. Eventually all the spam bots will doing it, but for now it is not a real problem.
I am trying to find a list of the IP address of popular proxy servers so that I can check to see that the x-forwarded-for at least comes from a proxy server.
Google blew me off with some stupid remarks on the Chrome compression proxy. Obviously they could care less that their proxy could be used for spamming. Their response to me indicated that they did not even understand that their was a problem. This is the problem with using “Use Case” analysis. Someone postulates a simple “use case” concept and then nobody takes it any further. I had enough of that while working at IBM.
Keith
I’ve been following this thread with great interest. This plugin is the only one that has provided a rational solution to the onslaught of spammer registrations we get. Unfortunately we’ve been getting a ton of “Spoofed IP” false positives lately, and the captcha page doesn’t play nice with one of our plugins (CiviCRM specifcally).
I had to disable the plugin as a workaround, and I’m super bummed because until now it has been a lifesaver for us. I know you’re stopping development on this in favor of other projects, but the option to disable the “Spoofed IP” check would be a much appreciated work around until we can find another solution.
The current version on http://www.blogseye.com has the spoof ip feature switch.
I added the option to use the proxy server IP, but using it disables the ability to report to SFS. This will prevent spoofed ips from being registered at the spam databases.
You can use the proxy server meta info for the IP or you can block spoofed IPs, but not both. There are a few other features that have been added.
I am still testing this, but it seems to be doing things right.
Keith