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

Meanwhile, this is the kind of "attack" they're letting go through on a Pro property with all defaults WAF activated:

>HOST: example.com/2Y8son3bwiuSuYUdBW3EAIojZc8{{41839*41587}}

Django catches this and I get notified.

EDIT: it's being passed as HTTP HOST header, not path. Obviously, `example.com/randomgibberish{{}}` is not a VALID zone/host set up on my CF account, so I'd think that they should not pass that to my backend.



I don't understand. What is the attack there, and what does Django catch? In my experience with Rails and Phoenix, I'd expect that to just 404.

But it looks like maybe you're implying the double curly braces allows someone to inject some sort of eval block. Is that a Django thing?


Potentially the path is a Jinja2 template and the product of 41839*41587 evals to a value that makes the whole path a special case? That seems dangerous to allow, AI WAF or not, so I am also not quite sure what the attack here would be.


It doesn't 404 because it's being passed at the `HOST` header, not the path.


I don’t use Django but used to write many scripts in Salt. The double curly braces are used by various templating engines to inject variables into static files.

The attack here is that an attacker can probably run unsafe code on the server and exfiltrate data or worse.

I think by default Django will throw a 404 or 400 like you mentioned. OP would have liked the request to get zapped by the WAF though.


I _think_ it's an attempt to inject a template for execution via the url, the {{}} being django's template syntax, but…?


Django will return a 404 for that in general.

The curly braces are evaluated in templates and I am guessing this path will be evaluated as a template (not a standard Django template, but another comment said this would work in Jinja templates). THis seems like a bad idea though.


  curl -H 'host: www.judge.sh' https://www.judge.sh -v
  <regular response>

  curl -H 'host: www.judge.sh/2Y8son3bwiuSuYUdBW3EAIojZc8{{41839*41587}}' https://www.judge.sh -v
  < HTTP/2 400 
  < server: cloudflare
  
  <head><title>400 Bad Request</title></head>
In my experience the host header is pretty strict on Cloudflare mostly because that's how they identify which domain to route. All CF IPs work for any CF hosted hostname; You could curl 1.1.1.1 with your own site's TLS SNI and host header value to get your site back.


Thanks, will try. Maybe they fixed it, last occurrence that I could find in my logs was Oct/23.


This is just an invalid path on the server, unless your server is bad and needs to be fixed. What's the issue?


This is being passed as the `HOST` header, not the path.


ok? If that causes a problem for your server then your server is broken.


Django raises an `Invalid HTTP_HOST header`, it's not causing an error, I meant that it's obvious wrong and that CF WAF should catch that before reaching the origin server.


Oh, I mean the default settings are to let most requests through and block ones that meet some threshold for bad. You can tweak the settings or add your own rules though. You can easily configure CF's WAF to block Host headers with invalid characters. I personally wouldn't bother.

I wouldn't read too much into the defaults. I'm sure they're aiming for a sweet spot between blocking likely attacks and generating too many support tickets from crappy apps that rely on some non-spec behavior. It's not meant to be proof a request is well formed.


if this is executed by the backend, that means something more nefarious could be executed too




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

Search: