This message was deleted.
# citrix-netscaler
s
This message was deleted.
c
Where's the 302 redirect coming from? If it's a responder policy then you may be running into a processing order issue.
j
It comes from the web server behind. Ultimately the web server shouldn't allow this, it's Apache maybe there is a setting that can do this easily. But I was asked to see if there is a way to do it in NetScaler. As it's a content switching, I just have to make sure my host is correct or then it is dropped, no default LB set for my CS. That's not too bad I guess. I am still interested to know what you think on point 1? Ta!
c
Gotcha. I could see someone considering this a security issue but I think this is more of an unexpected behavior. Technically speaking there's nothing "wrong" with this request - you're telling cURL to find the machine at myweb.domain.ie and once it's there you're asking that machine for dodgy.com/mywebapp1. cURL will automatically fill in the Host header with the info from the URL by default unless overidden but that's for convenience. If it didn't do so then you'd either have to specify it manually every time or it'd send a malformed request because there wouldn't be a Host header at all; neither are great behaviors for a default.
🙏 1
m
You could rewrite the response if the backend has a different hostname that expected in the location header. You could also stop the inbound connection from reaching the backend server
🙏 1
j
Thanks Mike, indeed I see this as unexpected behaviour, I didn't do tests against other websites but I think many are prob behaving the same. It's not a big deal but as Mads suggested and as I did, because we use a CS VIP, by checking the requested host, the one that don't match my allowed host will get a 503, prob solved and it doesn't add more load on NS. I think it is the best option.
c
I'm not sure you'd be able to use a dynamic policy to act upon a mismatch between URL and Host: header to be honest. The DNS lookup is entirely separate from the HTTP request. The http.req.hostname expression grabs the hostname from the first line of the request (which should be the Host header), and if the first line isn't the Host header it will instead select the last instance of the Host header in the request. The policy manual suggests the http.req.url.hostname acts the same way, and http.req.header("Host") just lets you retrieve the same data as a header object instead of a hostname object.
With CS vip configured as mentioned without a default vserver then NS validates only expected hostnames for the given csvip are served (i.e. if there's no policy match the request is kicked back), and if you really wanted to add an additonal layer you could use a policy on the target lb vip to validate the incoming Host headers are as expected, but consider your security posture before jumping into the weeds. You could always create a responder with a log policy that can tell you if you're getting traffic with unexpected host header values as well, get some eyes on the situation without affecting traffic yet.
j
Thanks a lot Mike, I'll have to digest that!
👍 1
I'l prob go down the road of filtering it at the CS VIP level, create a VIP for default CS with a hard redirect to the main page if host is not correct + log.