Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This just sounds like a way to make a proxy with Cloudflare workers, which aren’t considered by Cloudflare’s filters to be as suspicious as Tor yet. You could do the same with any new VPS/cloud function provider. Am I missing some actual bypass?

If the X-Forwarded-For value from the request is forwarded by Cloudflare’s proxies unaltered, giving special privileges to Cloudflare workers, that’s a problem, but it’s not clear whether “a site who display your headers” is protected by Cloudflare and displaying an unaltered X-Forwarded-For. I don’t expect Cloudflare to have made this oversight, and the e-mail response from them matches: “All workers subrequests go through Cloudflare again, and therefore you won’t be able to bypass any restrictions directly.”



> You could do the same with any new VPS/cloud function provider.

I'm not so sure this is true. Not long ago Cloudflare's CEO was making fun of people trying (and failing) to bypass Cloudflare's anti-bot measures. This allows to bypass this because as far as Cloudflare is concerned, the requests are coming from a trusted source. Setting up a proxy with a provider that isn't Cloudflare, means the requests aren't coming from a trusted source any more.


The thing is that it isn't being seen as a trusted source. The same global rate limits apply, and the `Cf-Connecting-Ip` (which is the one you should use for security) request header still can't be forged and is passed to the end website correctly.


I have seen workers code that appears to remove Cf-Connecting-Ip prior to a fetch(), though no idea if that works. Maybe it just gets replaced with the workers ip? Like:

  router.route('/proxy/:url', '*', async (event) => {
    event.request.headers.delete('cf-connecting-ip');
    event.request.headers.delete('x-real-ip');
    return await fetch(event.parameters.url,event.request);
Edit: Tried several variations of this. It doesn't work. The cf-connecting-ip header is always in the fetch request with the right data. It's a bit confusing because some of the Cloudflare tools don't show you all the headers.


> Cloudflare's CEO was making fun of people trying (and failing) to bypass Cloudflare's anti-bot measures

Do you happen to have a link?



Thanks!


> Am I missing some actual bypass?

No, you're not. Which is why Cloudflare were correct to say this isn't a security issue.


VPS providers are not free, and so is traffic produced by VPS. On the other hand, 100k req/day is a generous limit, easily expandable with additional accounts.


GitHub Actions and other CI, Heroku, AWS, GCP, Azure, Fly.io, etc. have free tiers. This is another one of those that, when misused enough, will develop a bad reputation too. (Except in the case of Cloudflare workers to Cloudflare bot blocking, they’re in potentially an even better position to distinguish legitimate traffic because they have information from both ends.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: