I have a Linux/Apache/Rails stack hosting a data service. The data service is basically a front end for multiple data sources, akin to a federated search.
Queries to the service are authenticated via PKI. When handling each request, the PKI must be forwarded to each data source appropriate for the given request - each data source uses the PKI to control data access.
I know how to access the requestor's DN from Rails, but I haven't the first clue how to access the PKI or pass it along in web requests launched by the controller when handling the request. Any suggestions?
Your description makes it a bit hard to follow the organization, but Ill try to give this a shot.
The nature of PKI makes forwarding (proxying) a connection impossible, since the two endpoints set up a secret session key known only to those parties. It seems like you have 3 parties, a Client, an Intermediate, and an Endpoint. So the client can authenticate to the intermediate, and the intermediate now knows with certainty who the client is. I think your question is how to get the endpoint to know with certainty who the client is. The method I would choose is to have each intermediate have its own certificate, and authenticate to the endpoint itself (so now the endpoint knows who the intermediate is with certainty) then just have the intermediate pass the DN as some extra field that the endpoint will trust from the intermediate.
Related
I have 2 rails apps.
App1 needs to send data that will be saved by App2.
I want to know the best way to create a secure API endpoint to do this.
How can i authenticate the requests App1 sends to App2
I have worked with other API's that require verification for the requests, such as Facebook.
With Facebook they send over in the header a token that i am able to calculate and compare to verify the request.
def verify_webhook(request)
sha1 = request.headers["X-Hub-Signature"].gsub("sha1=", "")
digest = OpenSSL::Digest.new('sha1')
request.body.rewind
data = request.body.read
# Calculate a sha1 with the app key and payload from the post request
calculated_hmac = OpenSSL::HMAC.hexdigest(digest, ENV['FB_APP_SECRET'], data)
# Computate hmac and see if verified is true
verified = ActiveSupport::SecurityUtils.secure_compare(calculated_hmac, sha1)
verified
end
I assume the solution is similar but i cant find documentation for what i am trying to do online, i am not too familiar with the terms so i might be searching the wrong things.
Can someone point me in the right direction?
When designing security-related functionality, you should first establish a threat model. This includes getting a good overview of the attack surface - are your applications communicating over the internet or just over the company network? - and making some assumptions about who would be trying to break your application and how much energy they would be willing and able to invest into that.
For low-threat environments, a pre-shared key/secret transferred in a HTTP header as mentioned by #max's comment would be enough: you just provision both applications with a key and send it in a HTTP header on each call - which should of course be made over a TLS-encrypted connection.
If your threat model includes an attacker who might be able to break that TLS-encrypted connection and gleam the pre-shared secret from there, you can take it up a notch and instead of transferring the key itself in the header, create a checksum via a HMAC and compare it on the client - just like in your example with the Facebook SDK. You might also want to add a cryptographic nonce to avoid a replay attack.
Finally, when designing security-related code you'll probably want to have it reviewed by someone who has experience with security as it's very easy to get something wrong and have all your efforts be in vain.
I couldn't find exact answer.
In similar topics, people say that without Private key you can't view HTTPS response, but I am surprised, why key needed at all? For example, when browser requests https://example.com, it can read view it's html output.
And I want the same in WireShark (one of my program reads response from https://example.com and want to view just that page's outputed HTML). However, I can't understand why Private key is needed with this simple task?
If you didn't need to know the private key, an attacker wouldn't need it either – then any HTTPS traffic including login information, credit card numbers, photos, etc could be read by anybody that is on the same network as you (somebody listening to wi-fi traffic), or anywhere between you and the server (ISPs). This would be a disaster.
HTTPS (or more specifically TLS) was created for this purpose – to be able to communicate with remote parties securely without having complete trust in every single node on the way to the remote party. It relies on public-key cryptography, which makes it so that it is easy to encrypt messages with the public key, but extremely difficult (or practically impossible) to reverse the encryption without knowing the private key.
A browser which communicates with a server via HTTPS creates a link based on keys exchanged securely. Only the server and the browser know these keys, and so only the server and the browser can send and receive messages to each other.
Wireshark, even if it is running on your computer, is not running as a part of your browser and hence does not know the keys that the server and the browser agreed on. So it is impossible for it to read the traffic.
It may be somewhat surprising to know that even if somebody (Wireshark) can read all the data your browser exchanges with a server, it will not know the keys that the browser and server agreed on.
Traditionally, secure encrypted communication between two parties required that they first exchange keys by some secure physical channel, such as paper key lists transported by a trusted courier. The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher.
Diffie-Hellman key exchange, Wikipedia
We have a JSON hash that the backend processes and serves to our frontend to calculate a map. The JSON hash is rendered from a GET request and is constantly being updated (not cached).
We need a way to lock down the route so that only the app itself can connect to it (stopping bots from pinging the URL to grab the hash). The frontend and backend are tied together in one Rails application (no separate services).
My issue is that ActionController::RequestForgeryProtection::ClassMethods does not support GET and ActionController::HttpAuthentication::Token is overkill since I need to restrict the JSON hash to the app (not to a specific user). Request.referrer can be spoofed so I hesitate in checking that.
I would appreciate any suggestions on how to reject outside GET requests to a Controller when it is not the app making the request.
Rails: 4.2.6
You won't be able to prevent arbitrary programs (ie: "user agents") from making HTTP requests against your server. You can, however, refuse to respond with useful content unless the user agent can prove that it's your app.
What you want to do is cryptographically sign your requests in your client app, then verify the signature on your server before responding. I don't know of any Ruby/Rails library to do precisely that (and I couldn't find any upon a cursory search), but it could be built from existing libraries. Here's a quick and dirty implementation concept:
Embed a secret key into the client app.
Whenever the client app makes a request, it:
Generates a UUID that will be used exactly once, ever. (A "nonce").
Generate a signiture by hashing the nonce with the secret key.
Pass the nonce and the signature with the request (probably as HTTP headers)
When the server receives a request, it generates a signature based on the incoming nonce and the secret key (which it already knows). If the signature matches, and the nonce has never been used before, then the server returns the content. If either of those conditions are not true, then the server can't guarantee that it's your client app making the request, and thus should respond with a failure.
Disclaimers:
This is entirely dependent on the security of the secret key embedded in the client app. If the key is hacked (and it will be, given enough effort on the part of the attacker), then this scheme falls apart.
If you use the same secret key for all client apps (and there's a good chance you'll need to, depending on your app architecture), then if one client app install gets hacked, you lose security on all of your installations.
This is just an illustration of the general principle, not a fully fledged secure implementation. I'm not a security expert and have not run through all of the potential attack vectors for this plan.
I also suggest reading up on how OAuth works. It solves a similar problem, and you may be able to adapt it for your purposes.
I'm trying to make a secure protocol between an iPhone app and an Arduino server. The goal is that the iPhone app makes a request to an Arduino server and the server only processes it if it has the proper credentials of one form or another. I'm not really sure how to approach this problem. Any suggestions are much appreciated!
Unfortunately there are no truly secure communication options available on Arduino. The basic problem is that SSL libraries have not been ported to this platform, partly owing to the fact that the 8-bit processors the platform is built around are not very powerful. Having said that there are some things you can do, but you'll have to do them yourself:
Basic access authentication is a very insecure method of controlling access to HTTP pages so it isn't recommended. Digest access authentication, on the other hand, employs one-way cryptographic encoding (hashing). It only requires MD5 library, which, is actually available for Arduino. What you'll need to do is modify the source code for the Web Server class to support digest access authentication: AFAIK it does not support it out of the box.
If this seems to difficult, you could implement something fairly basic (and not very secure, but better than nothing) yourself. It might look like this:
The first GET request comes in from a client
The server responds with "not authorized" response, embedding in the response a token which is related to (perhaps a hash of) the requesting IP address. You could make the original timeframe part of the hash as well, and give such tokens a limited lifetime.
If the next request from the same IP address includes a hash based on some secret code + the token sent, the next request is honored.
Now this will not protect you from IP address spoofing, and many other things I probably haven't thought of. However, it will give you a modicum of security (and a tiny bit of security through obscurity, if you believe in this sort of a thing). You could ask for (slightly) more elaborate schemes on superuser
You might be able to just use authenticated messages built on shared secrets. The message will contain [at minimum] a message type, message body, timestamp, and message digest. You create the digest by HMACing the other stuff with a shared secret. (Type HMAC Arduino into Google for libaries and code.) The message is sent over TCP or UDP (i prefer it). The Arduino computes digest of message, checks it, validates data, and then acts on message.
One thing I like to do is implement port-knocking or something at the network layer in front of the application server. This prevents unwanted traffic from reaching the custom (and possibly vulnerable) command server. This can be done stealthily (see Silent Knock) or obviously. The network protections can also be implemented by a dedicated device that does the heavily lifting and disqualifies much rogue traffic before it reaches the Arduino.
I'm trying to find my way around the OAuth spec, its requirements and any implementations I can find and, so far, it really seems like more trouble than its worth because I'm having trouble finding a single resource that pulls it all together. Or maybe it's just that I'm looking for something more specialized than most tutorials.
I have a set of existing APIs--some in Java, some in PHP--that I now need to secure and, for a number of reasons, OAuth seems like the right way to go. Unfortunately, my inability to track down the right resources to help me get a provider up and running is challenging that theory. Since most of this will be system-to-system API usage, I'll need to implement a 2-legged provider. With that in mind...
Does anyone know of any good tutorials for implementing a 2-legged OAuth provider with PHP?
Given that I have securable APIs in 2 languages, do I need to implement a provider in both or is there a way to create the provider as a "front controller" that I can funnel all requests through?
When securing PHP services, for example, do I have to secure each API individually by including the requisite provider resources on each?
Thanks for your help.
Rob, not sure where you landed on this but wanted to add my 2 cents in case anyone else ran across this question.
I more or less had the same question a few months ago and hearing about "OAuth" for the better part of a year. I was developing a REST API I needed to secure so I started reading about OAuth... and then my eyes started to roll backwards in my head.
I probably gave it a good solid day or 2 of skimming and reading until I decided, much like you, that OAuth was confusing garbage and just gave up on it.
So then I started researching ways to secure APIs in general and started to get a better grasp on ways to do that. The most popular way seemed to be sending requests to the API along with a checksum of the entire message (encoded with a secret that only you and the server know) that the server can use to decide if the message had been tampered with on it's way from the client, like so:
Client sends /user.json/123?showFriends=true&showStats=true&checksum=kjDSiuas98SD987ad
Server gets all that, looks up user "123" in database, loads his secret key and then (using the same method the client used) re-calculates it's OWN checksum given the request arguments.
If the server's generated checksum and the client's sent checksum match up, the request is OK and executed, if not, it is considered tampered with and rejected.
The checksum is called an HMAC and if you want a good example of this, it is what Amazon Web Services uses (they call the argument 'signature' not 'checksum' though).
So given that one of the key components of this to work is that the client and server have to generate the HMAC in the same fashion (otherwise they won't match), there have to be rules on HOW to combine all the arguments... then I suddenly understood all that "natural byte-ordering of parameters" crap from OAuth... it was just defining the rules for how to generate the signature because it needed to.
Another point is that every param you include in the HMAC generation is a value that then can't be tampered with when you send the request.
So if you just encode the URI stem as the signature, for example:
/user.json == askJdla9/kjdas+Askj2l8add
then the only thing in your message that cannot be tampered with is the URI, all of the arguments can be tampered with because they aren't part of the "checksum" value that the server will re-calculate.
Alternatively, even if you include EVERY param in the calculation, you still run the risk of "replay attacks" where a malicious middle man or evesdropped can intercept an API call and just keep resending it to the server over and over again.
You can fix that by adding a timestamp (always use UTC) in the HMAC calculation as well.
REMINDER: Since the server needs to calculate the same HMAC, you have to send along any value you use in the calculation EXCEPT YOUR SECRET KEY (OAuth calls it a consumer_secret I think). So if you add timestamp, make sure you send a timestamp param along with your request.
If you want to make the API secure from replay attacks, you can use a nonce value (it's a 1-time use value the server generates, gives to the client, the client uses it in the HMAC, sends back the request, the server confirms and then marks that nonce value as "used" in the DB and never lets another request use it again).
NOTE: 'nonce' are a really exact way to solve the "replay attack" problem -- timestamps are great, but because computers don't always have in-sync timestamp values, you have to allow an acceptable window on the server side of how "old" a request might be (say 10 mins, 30 mins, 1hr.... Amazon uses 15mins) before we accept or reject it. In this scenario your API is technically vulnerable during the entire window of time.
I think nonce values are great, but should only need to be used in APIs that are critical they keep their integrity. In my API, I didn't need it, but it would be trivial to add later if users demanded it... I would literally just need to add a "nonce" table in my DB, expose a new API to clients like:
/nonce.json
and then when they send that back to me in the HMAC calculation, I would need to check the DB to make sure it had never been used before and once used, mark it as such in the DB so if a request EVER came in again with that same nonce I would reject it.
Summary
Anyway, to make a long story short, everything I just described is basically what is known as "2-legged OAuth". There isn't that added step of flowing to the authority (Twitter, Facebook, Google, whatever) to authorize the client, that step is removed and instead the server implicitly trusts the client IF the HMAC's they are sending match up. That means the client has the right secret_key and is signing it's messages with it, so the server trusts it.
If you start looking around online, this seems to be the preferred method for securing API methods now-adays, or something like it. Amazon almost exactly uses this method except they use a slightly different combination method for their parameters before signing the whole thing to generate the HMAC.
If you are interested I wrote up this entire journey and thought-process as I was learning it. That might help provide a guided thinking tour of this process.
I would take a step back and think about what a properly authenticated client is going to be sending you.
Can you store the keys and credentials in a common database which is accessible from both sets of services, and just implement the OAuth provider in one language? When the user sends in a request to a service (PHP or Java) you then check against the common store. When the user is setting up the OAuth client then you do all of that through either a PHP or Java app (your preference), and store the credentials in the common DB.
There are some Oauth providers written in other languages that you might want to take a look at:
PHP - http://term.ie/oauth/example/ (see bottom of page)
Ruby - http://github.com/mojodna/sample-oauth-provider
.NET http://blog.bittercoder.com/PermaLink,guid,0d080a15-b412-48cf-b0d4-e842b25e3813.aspx