5

I have two services - A and B - which both expose a HTTP/REST API. Service A is exposed to the public and authenticates its users. It delegates part of the workload to service B which also has to know the identity of the authenticated user and perform some access control. Service B has no public IP address and only accepts connections from services in the same internal network (service A being one of them).

As I consider the connection between A and B trusted (they are both behind two firewalls), I simply pass the user identity in a custom HTTP header. Are there vulnerabilities in this setup I'm not thinking of? Are there standard ways of passing the user identity instead of using a custom HTTP header?

2

I have almost exactly the same issue with two services of mine.

I'm taking a slightly different route to solve it due to the following train of thought: What happens if due to some misconfiguration of the firewall or a router, service B suddenly becomes available on the internet, or on the internal network of my company? We've had firewall rules change without being told about the changes in the past; so I've grown careful.

Here's what I'm currently doing: Service A and B share a secret password which only they know. I use it to build an hmac over a small json structure (my "access token") on service A which basically contains the user name of the authenticated user, a nonce and an expiry date. I pass the access token and the hmac to service B (as a long base64-encoded string in the standard Authorization header). Service B then validates the access token using the hmac and if it checks out, it can be reasonably sure that the access token it received was from service A. All that remains is to make sure that the access token has not expired.

You could do the same with a JWT, and with public key cryptography to digitally sign the access token, instead of what I'm doing with an hmac.

This isn't so much different from what you're doing - building my access token (just once, when the user logs in on service A) isn't much work, and neither is verifying the token on service B, but it does add some additional security, compared to your solution.

Just like you, I'd be interested in answers which describe a generally accepted way of solving this issue - I've always thought my solution was a bit too home-grown, and might suffer from problems I can't immediately see.

  • Thanks! So my current understanding is that in an ideal world my setup is "safe" as such but in practice it makes sense to guard against human errors - or vulnerabilities in other parts of the system - by introducing something like JWT. – Muton Mar 3 '17 at 6:33
0

'Defense in depth' is about planning on failure. In this network model, a server-side request forgery (SSRF) vulnerability would be extremely valuable to an adversary.

Keep in mind, no developer intends to implement insecure software, and yet these issues are rampant.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.