search

kiwix / web

Bugs, enhancements, ideas for our Web presence
https://kiwix.org
7 stars 7 forks source link

User complains about catpcha on www.kiwix.org #97

Closed kelson42 closed 4 years ago

kelson42 commented 4 years ago

I was quite surprised to read that a user had - I guess under special conditions - to answer a captcha on our official Web site. image

@martin8032 Do you know what happened here?

martin8032 commented 4 years ago

This comes from https://www.imunify360.com, the web application firewall (WAF for short) of our hosting provider. It protects our website from a variety of attacks.

I did not install this myself, but I highly recommend that we use it. And I don't see a reason for users to complain about it: If there is a lot of traffic from their IP address then it's the most natural thing to check if there is a bot at work – and solving a CAPTCHA should not be a big deal.

kelson42 commented 4 years ago

@martin8032 I catches normal trafic and the captcha does not display properly for this user (I guess it relies on some kind of proprietary code/tracker etc...). Do we have a way to report that this stuff catch legitimate users or maybe deactivate this protection (I don't see why we should have a problem with bots)? Do we also have a way to know how this tool is configured (I ask the user because the user might use Tor)?

martin8032 commented 4 years ago

There is no way to prevent that the WAF presents the CAPTCHA to human users – because that's what a CAPTCHA is all about: to test if a user is human or not (which the WAF cannot know upfront).

Obviously there was a lot of traffic from that IP before this request, so the WAF decided to activate the CAPTCHA for all further requests from the same IP. This is a common practice and makes absolutely sense.

We will NOT deactivate the WAF: Every website has a problem with bots, and kiwix.org has even a higher risk of being attacked for political reasons. This complaint might be legit – but it might just as well be an attempt to weaken our server protection as part of an attack.

So the only thing we need to discuss is the broken CAPTCHA. As far as I can tell from https://www.google.com/search?q=immunify360+captcha the Imunify360 CAPTCHA is based on Google's reCAPTCHA. So the CAPTCHA is probably not coming from the same server as the WAF, and my first guess would be that the user has something installed/configured on this machine that suppresses third party components on a webpage.

Bottom line: I don't see anything that we should or could do on our side.

kelson42 commented 4 years ago

@martin8032 Thx for confirming my guesses about all of that. This is really a pity we can not control this part of the infrastructure. Not only it impairs the visit of legitimate users but also because it looks like it leaks information to a corporation specialised in surveillance (same problem as Google Analytics BTW, but if Google Analytics is blocked by the browser, the page still displays properly, which is not the case here). Not good. Lets hope this user complain won't be repeated... really sad it comes from one of our most prominent user.

martin8032 commented 4 years ago

@kelson42 While there are obviously pros and cons when using a Google service for the CAPTCHA, having a WAF (and therefore having some kind of CAPTCHA) is absolutely mandatory, and showing the CAPTCHA to legitimate users as well is inevitable, as discussed before.

If there is something to complain about, then it's the fact that malicious people are trying to hack other people's websites, but not the fact that our hosting provider is protecting our website. In fact, we are able to turn the WAF off, but by this we would take huge risks for all of our users just to satisfy a few complaining users.

kelson42 commented 4 years ago

@martin8032 Yes, this is a trade-off. My general feeling is that WAF are usually overrated. Just as an example, AFAIK Wikimedia does not have one... and they face stronger security challenge than we do.

ultrachrisp commented 3 years ago

I'm posting this for Richard Stallman who does not have a github account.

I wouldn't mind answering a CAPTCHA. I'm human, so I should be able to answer the questions, if I could see them.

I can't see them because they don't appear on my screen. The site tries to display them by sending nonfree software to my browser. I've set my browser to refuse to run nonfree software, because (1) software that the users don't control is an injustice, and (2) it is typically designed to mistreat the users.
(See https://gnu.org/philosophy/free-software-even-more-important.html.)

The hosting company ought to send a non-JS version of the CAPTCHA on request. And maybe we can pressure the company to implement that if we try.