CODEWITHSUNDEEP
apihttphttps
ilasno
ilasno

Reputation: 724

What are the security ramifications of checking security with an HTTP call to an external server?

I was discussing development of an API with a colleague, and the following proposal has made me wonder about the securability of it.

Scenario:

There is a web application that is running on server A that (in addition to other functions) allows the admin user to specify arbitrary URLs, and security for the users within their account related to each URL. So basically:

URL:"/foo/bar", UserID:1234, AllowedToView:true

The admin user then has their own web application running on their own, separate server B. And they want to check if their end users that have logged in on that server B application have access to a particular URL on that server B application by checking against the API on server A.

This check could come in 2 forms:

  1. A server-side HTTP call (from server B to server A) that happens within the context of a user requesting a url from server B, so this would look like:

     User requests "/foo/bar" with their client from server B
 During the processing of that request on server B, it makes an HTTP call to server A to check if that user has access to the requested URL
 With the response from server A, server B can then either allow the user to access or redirect, send 403 access denied, etc.

  2. An AJAX request from the end user's client directly to server A and utilizing the response with JavaScript. An issue of cross-domain scripting could be problematic here.

One challenge that comes to mind immediately is that there would have to be a way for the admin user to directly associate the end user that is accessing their web app on server B with the UserID that is associated with that user in the web app on server A. But let's assume that has been solved elegantly somehow :-D.

My question related more to the inherent (in)security related to a scenario like this. If the requests that are being made to server A (in both 1 and 2 above) are made with https, then can the integrity of the responses be counted on?

Upvotes: 1

Views: 37

Answers (2)

Rotem Hermon
Rotem Hermon

Reputation: 2147

You can't rely on client side validation if you really want to secure your server B. That is, your second scenario - calling server A from the client side to see if it can access resources - is not a secure method. You need to count on the client to behave nicely, which of course leaves you open to attacks.

You first scenario - server to server call is a secure and preferred method. You will still need to secure your call using signing or just passing the shared secret itself to validate the origin of the call (using HTTPS).

That said, there are ways to secure a flow that goes through the client, but it will usually involve signing the data on the server since you can't have your client sign it (you can't place your secret in the client).

Upvotes: 1

John Sheehan
John Sheehan

Reputation: 78132

HTTPS makes sure the message can't be read or tampered with any relaying parties (proxies, etc.) but it doesn't guarantee the source of the data is trusted. If another service can determine the other URL and wire format they could spoof a request to it. This is generally where something like request signing comes into play using a shared-secret signing mechanism. Twilio's API uses this method to prove to you that they're actually calling your servers. HTTP Signatures is a proposal for a standardized way of doing this.

Upvotes: 1

Related Questions