A client of mine has a bunch of APIs in CloudHub that communicate with two APIs on premise in their runtime. The question I get asked, to which I don't really know the answer, is how to secure the communication between the APIs on CloudHub and on premise without using API Manager (since the client preferred not to pay for it) ? I thought of a middleware (middleware inception) that hashes the messages from one end to another, is this a viable idea? What could the best answer be?
The server applications should implement some basic security best practices like authentication and encryption.
Having applications deployed in any cloud environment without security is a big security risk. I assume that there is a secure link between the CloudHub environment and their on premise environment, like a VPN, but even so this architecture would not probably pass a security audit.
They should implement authentication using HTTP Basic authentication or OAuth 2. These are the most common authentication schemas used for REST APIs. Note that credentials go in clear text so they should also implement encryption.
To encrypt the traffic the server applications should use TLS, ie HTTPS connections instead of plain HTTP.
Optionally you could also implement mutual TLS authentication, requiring the client to have a valid certificate that the HTTPS server validates.
Hashing message could be an additional level of security, but that implies changing the applications logic to implement some custom security. The effort should be better put into implementing standard security practices as mentioned. If after that you want to add it feel free to do so.
You have not shared details of the technology of the on prem applications. Mule applications can implement both the client and server side of any of these methods. Read the documentation for details:
https://docs.mulesoft.com/http-connector/1.7/http-authentication
https://docs.mulesoft.com/mule-runtime/4.4/tls-configuration
https://help.mulesoft.com/s/article/Tutorial-how-to-create-a-simple-Mule-4-http-basic-authentication-application
Related
It's a hot debate on how to securely handle API Keys.
And almost all of us know that it's the best solution to have them stored on the server side, and never exposed in client-side applications.
Our clients can send requests to our APIs, and our APIs can act as proxy to send/receive data to/from the third party API and return the response back to our client.
However, there are some third party SDKs that you can integrate into your client-side app and they also have their API Keys.
For example, Zoom has SDKs for Web, Android, iOS, Windows, etc., or Pusher has Pusher Key.
When you want to work with these libraries, you CAN NOT send request to your API to hide API Key. You have to initialize these libraries in your client-side code (react for example).
An example from Zoom to join a meeting inside your web app:
client.join({
apiKey: apiKey,
signature: signature,
meetingNumber: meetingNumber,
password: password,
userName: userName
})
What are the best practices to secure API Keys for client-side SDKs and libraries?
Your Problem
When you want to work with these libraries, you CAN NOT send request to your API to hide API Key. You have to initialize these libraries in your client-side code (react for example).
What are the best practices to secure API Keys for client-side SDKs and libraries?
Well you found yourself a very hard problem to solve (but not impossible to some degree), because once the API Key is in the client side it's public. So, no matter how well you hide it will always be possible to retrieve it on a browser or mobile app.
Web Apps
On browsers is very trivial to get hands on the API key, just open the developer tools and in the network tab look for the request you are interested in extracting the API key and click on it to inspect the request headers.
Mobile Apps
In mobile devices id more laborious to extract an API key from a mobile app, but not that difficult has many may think.
JNI/NDK - Hide API Key in Native C Code
For example, you can hide the the API key in C native code via JNI/NDK:
Using Android Studio 2.2 and higher, you can use the NDK to compile C and C++ code into a native library and package it into your APK using Gradle, the IDE's integrated build system. Your Java code can then call functions in your native library through the Java Native Interface (JNI) framework.
This approach aims to protect the AP/i key from being extracted from your mobile app binary via static binary analysis, as exemplified in this repo and blog post I wrote:
During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.
Extract the API Key hidden in Native C Code with a MitM Attack
In the above blog post the API key hidden in the source code with JNI/NDK interface was not possible to extract via static binary analysis, but it was easy to extract with a MitM attack as I demo in the article Steal that Api Key with a Man in the Middle Attack:
In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.
Prevent MitM Attack with Certificate Pinning
The first thing one can do to prevent a MitM attack is to use certificate pinning and I wrote about how to do it in the article Securing HTTPS with Certificate Pinning:
In order to demonstrate how to use certificate pinning for protecting the https traffic between your mobile app and your API server, we will use the same Currency Converter Demo mobile app that I used in the previous article.
In this article we will learn what certificate pinning is, when to use it, how to implement it in an Android app, and how it can prevent a MitM attack.
I see the smile on your face now, but will not be for long because certificate pinning can be bypassed.
Bypassing Certificate Pinning
You can do it repackaging the mobile app without pinning or by using an instrumentation framework at runtime to disable it.
Repackaging the mobile app to bypass pinning
This is not hard to achieve when you have the correct tools and open source is full of them. I wrote how to do it in the article Bypassing Certificate Pinning
In this article you will learn how to repackage a mobile app in order to make it trust custom ssl certificates. This will allow us to bypass certificate pinning.
Using an Instrumentation Framework to bypass pinning
This is my preferred method and my instrumentation framework of preference is Frida, and guess what, I also have an article on it with the title How to Bypass Certificate Pinning with Frida on an Android App to show you how to do it:
Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
Possible Solutions
You may employ an array of different approaches and techniques to defend your API server and mobile app, but give preference to use a security solution that spans both the mobile/web app and API server.
The solution(s) to use will depend on your threat model, your budget and your resources and I will give you below pointers to some options.
For Mobile Apps
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
For Web Apps
You can learn some useful techniques to help your API backend to try to respond only to requests coming from what you expect, your genuine web app, and to do so I invite you to read my answer to the question Secure api data from calls out of the app, especially the section dedicated to Defending the API Server.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
For Web Apps
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
What do you want to secure exactly? I assume you want to avoid someone from misusing your API key, but you should ask yourself, from what security risk or threat do you want to protect?
You should also understand what kind of API key are you dealing with, as not all of them are intended for the same use-case and could 'offer' different level of security.
For example, you could have an API key in the form of a personal access token (in GitHub, for instance), where the token is directly tied to a user/employee and should be considered a secret, or you may have an API key in the form of a machine token that it's tied to your organization or your repository (still in GitHub, for instance) and that can be configured with different permissions (read-only, read-write).
It is also possible that the API key can be configured and restricted to some clients, according to the possibility of the client itself.
For example some of the Google Maps APIs allow you to configure a trusted origin that it is allowed to perform requests using your specific API key, however this protection works by checking the referrer header of the request and it could be spoofed by arbitrary clients. Browsers should still honor the convention and send the correct referrer, protecting you from people that want to use your API key on their website.
Another example in the mobile application world: there are some vendors that allow you to bind your API key to a specific package name that it is then validated at runtime by the vendor's SDK, however this kind of protection is usually as a licensing mechanism, to avoid developers to configure for free an SDK with a leaked API key.
Most generally, if the API key is intended to be used on public clients, then the developers of the API already considered the threat of having this leaked and you should not have a repercussion. This means that you will be covered from huge API usage billings or from rate-limit/usage quota limit (but better check yourself!).
The general rule is to always check the developer's documentation of the application you're trying to configure and see how to create a proper API key for your use-case and if it's fine for you to have this 'leaked' from your client. Additionally, if the API key allows you to configure permission, remember to follow the Principle of Least Privilege.
Another golden rule is to always threat model your implementation:
What are the capabilities of the API key?
What is the worst an attacker can do if they access the API key?
Am I protecting myself from these threat? How? Can I put more controls or monitors on back-end side (i.e. notification on high usage, etc)?
Finally, if your API key need to be kept secret, then you must not use this on a public client, no matter how hidden it is. There will always be at least one person able to retrieve it (And don't rely on client-side check either!). In this case what you want is probably to have your own back-end service responsible both for querying the APIs using the secret API key and for authenticating and authorizing your customers/users, and also to implement additional security measures like rate limit.
One thing I found very helpful is to always document any generated/used API key and its capabilities along with the threats of having them leaked and some preventive measures to minimize the risk.
I am working on a web application and security is one of our main concerns in this application. I was looking at different methods of API security (mentioned here on OWASP) and couldn't understand the difference between Mutual SSL auth and token-based auth. Here is a brief into of both before I move forward,
Mutual (or two-way) SSL authentication provides a combination of an encrypted data stream, mutual authentication of both server and client, and automatic sign-in convenience.
Source
Every single request will require the token. This token should be sent in the HTTP header so that we keep with the idea of stateless HTTP requests.
Source
From what I get, they both are probably alternatives of each other, so here are a few question that I have in mind and if you could answer them, I'd be so thankful.
In my opinion, both of these methods are alternatives of each other, is it so?
Yes? Then which one is better then the other and why?
No? Then should we use one of these or both? Also, whats the difference between them based on which you're saying that they are different.
In my opinion, both of these methods are alternatives of each other,
is it so?
Both of these method should be used based on your context. Two methods are used based on the need and security context.
No? Then should we use one of these or both? Also, whats the
difference between them based on which you're saying that they are
different.
Token-based auth (OAuth) usually used in a scenario where there is a need to establish a secure communication between mobile app/ web app and api server.Where password is not stored in the device.It store a temporary token to the device which expire over time.
Mutual SSL Mutual Authentication can be good candidate for establish a secured communication between two servers.
So it is the context which decide the choice!
I have googled "websocket delegated authentication" and the only interesting hit is (unsurprisingly) on stackoverflow: WebSockets authentication
What I'd like to know is: how are you allowing client-side applications - connected via websockets - to delegate their authority to back-end services and data stores?
I'm especially interested in figuring out how to delegate x509-based authentication, but at this point, I'd be happy to hear anyone's account of how they're delegating authority from the client-side over websockets.
Don't know what tech you are using php, net, java? Anyway for plain formsauth we just use the cookie passed from the browser with the websocket connection. We can then tell if the client has access or not. Have also used certificates (x509) wss/tls
If you are a .NET guy here's some docs
http://xsockets.net/api/net-c#
You will find both wss/tls and formsauth at the bottom of the page.
I am developing Restful API layer my app. The app would be used in premises where HTTPS support is not available. We need to support both web apps and mobile apps. We are using Node/Expressjs at the server side. My two concerns are:
Is there a way we could setup secure authentication without HTTPS?
Is there a way we could reuse the same authentication layer on both web app (backbonejs) and native mobile app (iOS)?
I think you are confusing authenticity and confidentiality. It's totally possible to create an API that securely validates the caller is who they say they are using a MAC; most often an HMAC. The assumption, though, is that you've securely established a shared secret—which you could do in person, but that's pretty inconvenient.
Amazon S3 is an example of an API that authenticates its requests without SSL/TLS. It does so by dictating a specific way in which the caller creates an HMAC based on the parts of the HTTP request. It then verifies that the requester is actually a person allowed to ask for that object. Amazon relies on SSL to initially establish your shared secret at registration time, but SSL is not needed to correctly perform an API call that can be securely authenticated as originating from an authorized individual—that can be plain old HTTP.
Now the downside to that approach is that all data passing in both directions is visible to anyone. While the authorization data sent will not allow an attacker to impersonate a valid user, the attacker can see anything that you transmit—thus the need for confidentiality in many cases.
One use case for publicly transmitted API responses with S3 includes websites whose code is hosted on one server, while its images and such are hosted in S3. Websites often use S3's Query String Authentication to allow browsers to request the images directly from S3 for a small window of time, while also ensuring that the website code is the only one that can authorize a browser to retrieve that image (and thus charge the owner for bandwidth).
Another example of an API authentication mechanism that allows the use of non-SSL requests is OAuth. It's obsolete 1.0 family used it exclusively (even if you used SSL), and OAuth 2.0 specification defines several access token types, including the OAuth2 HTTP MAC type whose main purpose is to simplify and improve HTTP authentication for services that are unwilling or unable to employ TLS for every request (though it does require SSL for initially establishing the secret). While the OAuth2 Bearer type requires SSL, and keeps things simpler (no normalization; the bane of all developers using all request signing APIs without well established & tested libraries).
To sum it up, if all you care about is securely establishing the authenticity of a request, that's possible. If you care about confidentiality during the transport of the response, you'll need some kind of transport security, and TLS is easier to get right in your app code (though other options may be feasible).
Is there a way we could setup secure authentication without HTTPS?
If you mean SSL, No. Whatever you send through your browser to the web server will be unencrypted, so third parties can listen. HTTPS is not authentication, its encyrption of the traffic between the client and server.
Is there a way we could reuse the same authentication layer on both web app (backbonejs) and native mobile app (iOS)?
Yes, as you say, it is layer, so it's interface will be independent from client, it will be HTTP and if the web-app is on same-origin with that layer, there will be no problem. (e.g. api.myapp.com accessed from myapp.com). Your native mobile can make HTTP requests, too.
In either case of SSL or not SSL, you can be secure if you use a private/public key scenario where you require the user to sign each request prior to sending. Once you receive the request, you then decrypt it with their private key (not sent over the wire) and match what was signed and what operation the user was requesting and make sure those two match. You base this on a timestamp of UTC and this also requires that all servers using this model be very accurate in their clock settings.
Amazon Web Services in particular uses this security method and it is secure enough to use without SSL although they do not recommend it.
I would seriously invest some small change to support SSL as it gives you more credibility in doing so. I personally would not think you to be a credible organization without one.
I'm receiving mixed signals on the web regarding preferred REST API authentication/authorization mechanisms, especially for mobile applications.
There is OAuth 1.0, but it's claimed to be more complicated than it needs to be and doesn't support native clients too well (callback URLs are very browser-centric). On the other hand, there is one major provider that supports it (Twitter).
Then there is OAuth 2.0, which is supposed to be an improvement over 1.0, and it gets rid of client-side crypto in it default incantation (replaced with bearer tokens), but some people are of the opinion that it's broken by design, and bearer tokens are no better than cookies. An SSL certificate from a sketchy provider can trick a mobile client more easily into believing that the endpoint is a trusted authority. However two major providers (Google and Facebook) support it.
And then there are people, who advocate sidestepping the whole mess and rolling your own.
So which is it?
This is going to sound like a hedge, but the answer is "whatever is appropriate for your application".
3rd-party authentication systems like OAuth and OpenID have their place, and they are perfect for some applications, especially for the kinds of systems that would allow clients to become API users without having to fork over their personal credentials to yet another server system.
However, you might be building a system that doesn't have that constraint or requirement, and it may be reasonable to ask your clients to simply create an account on your server. In that case, you can probably simplify things dramatically by using HTTPS and Basic Auth. Have the client pass their username/password in the appropriate header and ensure that your connection is SSL-protected. Or, have the client use a certificate for their credentials.
I would suggest you start by enumerating what "security" means to you, and work from the ground up. Consider every related facet like integrity guarantees, non-repudiation, replay protection, client impact, performance and API usability. From there, figure out if all you need is HTTPS/basic auth, or if you also need to add API keys, OAuth, OpenID, checksums, etc.
I'd recommend OAuth 2, but with additional certificate checks in the clients. If your certificate comes from Verisign, then invalidate all certificates from other CAs. Make sure to always get your certificates at the same CA though, unless you like distributing updates.
In the end, however, only a client can verify that the connection to the server is completely safe. Never forget that.