I’m designing a RESTful API for my organization. We do use password-based authentication, which generates tokens. One part of our API requires that the users be physically in the office, i.e. there is no use case where someone would need to be using those particular endpoints while working remotely. (It has to do with a physical check-in card-scanning scenario.)
We’re writing the REST API in ASP Web API, so my first inclination was simply to check the Request object to see what the remote IP address is, and only allow access to the given resource if that IP address falls within a whitelist. (For those calls which should be restricted)
My co-worker, however, believes this to be insecure. He believes there are ways to abuse HTTP in such a way that a malicious client could cause ASP.NET to report the incorrect remote IP address; therefore, he feels as long as someone knows the valid range of addresses (e.g. a worker could simply “ipconfig” on their machine while in the office to determine a valid IP), that person could abuse the API and access it from anywhere.
He suggests, instead, depending solely on a client secret. We’re already using password authentication, so that’s not the issue. What I’m not sure of is how we’d implement a client secret in such a way that 1. it could not be copied from one machine to another, and 2. that it couldn’t be accidentally removed. Obviously anything client-side would be in JavaScript so the “dev tools” console is the equivalent of a disassembler.
I have to feel that a combination of the two methods is at least a start – perhaps make the client secret involve the IP address in question, and then have the remote API check the client secret against the IP that the request appears to be coming from. (However, if a user can somehow copy the client secret, that won’t help anyway since they could just combine both hacking methods…) This also still does not answer how we would “pre-install” a client secret into the client. If we had the REST API provide a secret for later use, you’re back where you started – a malicious hacker could (apparently) spoof their IP and retrieve a secret they’re not supposed to have.
My understanding of TCP/IP tells me that it’s not possible to spoof your source IP address to anything you want and obtain a successful TCP connection. Since we’re using a whitelist, someone would have to somehow be able to spoof their IP from the outside to appear to be on our network and engage in a full TCP connection to the HTTP server. I don’t even think this is possible, but my co-worker still believes there’s a way to abuse the IP whitelist.
Which one of us is right? Or are neither of us right at all and there’s a completely different and better approach?
4
I believe IP spoofing is possible, but it is very difficult. You either need administrator access in one of the servers in the same subnet as the client, or access in one of the router between your server and the end server.
If you use HTTPS, the password based authentication would be enough, no one could capture the password in transit (assuming SSL vulnerabilities such as Heartbleed doesn’t apply to your server)
If don’t use HTTPS consider adding something extra, like token based authentication that combines hidden secret with some timestamp. OAuth as a standard could be used, but if you just need quick security you could think of your own simpler token-signing method.
2
I think that IP spoofing is much easier than explained in the other answer. This can be achieved without any admin right on your network. Just the right software (or some consumer grade devices). Even hardware MAC address isn’t reliable to whitelist devices. No, this approach isn’t protecting anything.
The client secret that you are talking about looks pretty much like a client certificate. You could opt for a hardware certificate (i.e. on an USB key), or a commercial certificate installed for the user account in a protected “certificate store”, or a temporary certificate (that’s acquired during the sign-on process, but this requires a local ca authority and is more complex to set-up).
Of course, such a client certificate makes only sense if nobody can intercept parts of it over the net. So this requires the set-up of a secured HTTPS communication (i.e. HTTP with TLS or SSL, which could also take care of client authentication).
Further reading:
- Open Web Application Security Project: REST security cheat sheet
- Authentication and security of a rest API using TLS
2
One way you can prevent this scenario is quite heavy handed.
You could introduce minimum latency for outbound connection, say 30 ms.
Within your internal network, you need to make sure that you do a series of cryptographic requests and response to measure latency, such that the access card must respond below the latency limit.
Thus the card has to be connected directly from inside your network for the scan to succeed.
Ways this could still be subverted:
- The rogue could install their own internet access point inside your network, bypassing the mandatory latency
- The rogue can extract the secret from the access card
Problems:
- Many legitimate applications are latency sensitive, or had worse experience with even minimal latency increase. For example, ssh, VoIP.
- The card has to be performant enough to do cryptographic operations within the time limit
- Adding even small latency can increase router hardware requirement
Personally, I wouldn’t bother with these.