Hacker News new | ask | show | jobs
by simonw 4118 days ago
This could be really useful for sending outbound webhooks, if it grew a couple of extra features:

1. "Fire and forget" ability. It would be great if I could send a request through Templar with an X-Templar-Fire-And-Forget: 1 HTTP header which means "deliver the request in your own time, but return a 200 OK to my client straight away so I don't have to wait for it.

2. It would be great if it could "validate" the URLs going through it somehow. When sending webhooks, it's important to be sure that they are going to the rest of the internet and not being used to probe internal IPs/hostnames of your own infrastructure. This is a bit of a fiddly problem, which is why it would be nice to have a proxy like Templar take it on. Take a look at the blocked_hosts section in http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.02/lib... for an example. I'm not sure how this would translate into X-Templar HTTP headers though.

1 comments

Fire-and-Forget is on the todo list. Since you're asking about it I'll bump it up. The later, Templar could have an option that tell it to only connect to public ips. Would that do it for ya?
Yes, that would be excellent - do you mean just public IP ranges?

One possible snag: I heard from a co-worker that if you are running on EC2 and you make an HTTP request to another site that coincidentally is also hosted on EC2 that traffic can sometimes be routed over a private IP range.

Looking at that CPAN module, it wouldn't be hard at all to add a blacklist to Templar via a config file that is checked. The EC2 => EC2 issue is probably the biggest stumbling block to getting what you want. I'll have to investigate that, it seems like that would only happen if internal to EC2 they do ICMP redirects...
That's good point actually, I could see that happening.

What is your concern about the url used? That they point at something a user is trying to coerce you to hit? If so, that could be a public IP too..

It's more about hitting internal services, where there may not be adequate protections in place. There's some earlier discussion here: https://news.ycombinator.com/item?id=7139176
Ah! Ok, I got it. Feels like the right way to handle this is the allow a blacklist to be defined via config file, then applied as request, something like "X-Templar-Blacklist: internal". The list would be a set of ip ranges and thus you'd have to construct the list so that the EC2 => EC2 problem doesn't crop up, but it's doable!