How can I be confident that only our silverlight applications are calling our azure services?
The silverlight client will need to have a user authenticated and have the correct permissions to perform an action but I did not know how application authenticity is commonly implemented on these azure service calls. I know you can sign the application (required for client updates). Is this combined with ssl connections enough? Should I be using a cert at the client?
What are some common approaches to this problem?
You can put data inside your message headers. You can do it in the SOAP header when using SOAP or in the HTTP header when using REST. Then when you've done this you can use a secure SSL channel to communicate so people can't sniff out your packages.
http://blogs.msdn.com/b/nathana/archive/2007/05/29/custom-soap-headers-wcf-and-asmx.aspx
When you're using RIA service and you want to add data in the HTTP header then see my blog:
http://strugglesofacoder.blogspot.com/2011/02/normal-0-21-false-false-false-nl-be-x.html
Silverlight does not have a way of identifying itself to the service, and even if it does, a little tool called Fiddler will expose all that information for anyone to exploit your services.
You should assume nothing about the client. Your services should perform validation on the incoming requests without trying to determine who/what the client is.
I do hope someone has a solution because I haven't found one yet, and I'd love to secure my services so that only Silverlight can make requests.
You could do this using the Access Control Service, there is a nice example on codeplex written by someone of the ACS team:
http://acs.codeplex.com/wikipage?title=ACS%20Windows%20Phone%20Sample&referringTitle=Samples
although it is a windows phone 7 client (which is also silverligh), i think you can distill what you need from it.
Silverlight is a tricky beast when it comes to integrating with ACS, it seems that writing to the headers from Silverlight to pass authentication information along is very tricky - there isn't an easy way to intercept the calls to wrap them with the auth header in Silverlight, like you could do in an ASP.NET application.
You can use ACS to get your identifying information to Silverlight by using an approach like this example: http://channel9.msdn.com/Events/MIX/MIX10/SVC01
What I ended up doing is wrapping some unique identifier claim in a SWT token, signed with a key that's known by both Silverlight and the web service, and having the web service verify that that user has access. By placing the unique identifier in a signed SWT token (with an expiration time of a very short amount - to help reduce attacks where folks copy a valid request and send it again at a later time), I could more comfortably believe that the request was truly coming from my Silverlight app.
To pass the token, I just made a class that contains all the parameters I want to pass (that way I didn't have to keep rewriting the function definitions), including the SWT token.
Hope this helps.
Related
Thanks for your help in advance.
I'm using React Native and Node.js to deliver a product for my company.
I've setup the steps on the backend to retrieve a password, validate it and respond with a token. The only problem is - the password I use on the front end (mobile app) to be validated by the back end is hardcoded.
My question is:
How should I securely store this password on the mobile app so that it can not be sniffed out by a hacker and used to compromise the backend?
My research so far.
Embedded in strings.xml
Hidden in Source Code
Hidden in BuildConfigs
Using Proguard
Disguised/Encrypted Strings
Hidden in Native Libraries
http://rammic.github.io/2015/07/28/hiding-secrets-in-android-apps/
These methods are basically useless because hackers can easily circumnavigate these methods of protection.
https://github.com/oblador/react-native-keychain
Although this may obfuscate keys, these still have to be hardcoded. Making these kind of useless, unless I'm missing something.
I could use a .env file
https://github.com/luggit/react-native-config
Again, I feel like the hacker can still view secret keys, even if they are saved in a .env
I want to be able to store keys in the app so that I can validate the user an allow them to access resources on the backend. However, I don't know what the best plan of action is to ensure user/business security.
What suggestions do you have to protect the world (react- native apps) from pesky hackers, when they're stealing keys and using them inappropriately?
Your Question
I've setup the steps on the backend to retrieve a password, validate it and respond with a token. The only problem is - the password I use on the front end (mobile app) to be validated by the back end is hardcoded.
My question is:
How should I securely store this password on the mobile app so that it can not be sniffed out by a hacker and used to compromise the backend?
The cruel truth is... you can't!!!
It seems that you already have done some extensive research on the subject, and in my opinion you mentioned one effective way of shipping your App with an embedded secret:
Hidden in Native Libraries
But as you also say:
These methods are basically useless because hackers can easily circumnavigate these methods of protection.
Some are useless and others make reverse engineer the secret from the mobile app a lot harder. As I wrote here, the approach of using the native interfaces to hide the secret will require expertise to reverse engineer it, but then if is hard to reverse engineer the binary you can always resort to a man in the middle (MitM) attack to steel the secret, as I show here for retrieving a secret that is hidden in the mobile app binary with the use of the native interfaces, JNI/NDK.
To protect your mobile app from a MitM you can employ Certificate Pinning:
Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.
You can read this series of react native articles that show you how to apply certificate pinning to protect the communication channel between your mobile app and the API server.
If you don't know yet certificcate pinning can also be bypassed by using tools like Frida or xPosed.
Frida
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
xPosed
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.
So now you may be wondering how can I protect from certificate pinning bypass?
Well is not easy, but is possible, by using a mobile app attestation solution.
Before we go further on it, I would like to clarify first a common misconception among developers, regarding WHO and WHAT is accessing the API server.
The Difference Between WHO and WHAT is Accessing the API Server
To better understand the differences between the WHO and the WHAT are accessing an API server, let’s use this picture:
The Intended Communication Channel represents the mobile app being used as you expected, by a legit user without any malicious intentions, using an untampered version of the mobile app, and communicating directly with the API server without being man in the middle attacked.
The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using a repackaged version of the mobile app, a hacker using the genuine version of the mobile app, while man in the middle attacking it, to understand how the communication between the mobile app and the API server is being done in order to be able to automate attacks against your API. Many other scenarios are possible, but we will not enumerate each one here.
I hope that by now you may already have a clue why the WHO and the WHAT are not the same, but if not it will become clear in a moment.
The WHO is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
OAUTH
Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.
OpenID Connect
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
While user authentication may let the API server know WHO is using the API, it cannot guarantee that the requests have originated from WHAT you expect, the original version of the mobile app.
Now we need a way to identify WHAT is calling the API server, and here things become more tricky than most developers may think. The WHAT is the thing making the request to the API server. Is it really a genuine instance of the mobile app, or is a bot, an automated script or an attacker manually poking around with the API server, using a tool like Postman?
For your surprise you may end up discovering that It can be one of the legit users using a repackaged version of the mobile app or an automated script that is trying to gamify and take advantage of the service provided by the application.
Well, to identify the WHAT, developers tend to resort to an API key that usually they hard-code in the code of their mobile app. Some developers go the extra mile and compute the key at run-time in the mobile app, thus it becomes a runtime secret as opposed to the former approach when a static secret is embedded in the code.
The above write-up was extracted from an article I wrote, entitled WHY DOES YOUR MOBILE APP NEED AN API KEY?, and that you can read in full here, that is the first article in a series of articles about API keys.
Mobile App Attestation
The use of a Mobile App Attestation solution will enable the API server to know WHAT is sending the requests, thus allowing to respond only to requests from a genuine mobile app while rejecting all other requests from unsafe sources.
The role of a Mobile App Attestation service is to guarantee at run-time that your mobile app was not tampered, is not running in a rooted device and is not being the target of a MitM attack. This is done by running a SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device is running on. The cloud service also verifies that the TLS certificate provided to the mobile app on the handshake with the API server is indeed the same in use by the original and genuine API server for the mobile app, not one from a MitM attack.
On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.
Now the App must sent with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.
Once the secret used by the Mobile App Attestation service is not known by the mobile app, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.
So this solution works in a positive detection model without false positives, thus not blocking legit users while keeping the bad guys at bays.
What suggestions do you have to protect the world (react- native apps) from pesky hackers, when they're stealing keys and using them inappropriately?
I think you should relaly go with a mobile app attestation solution, that you can roll in your own if you have the expertise for it, or you can use a solution that already exists as a SAAS solution at Approov(I work here), that provides SDKs for several platforms, including iOS, Android, React Native and others. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.
Summary
I want to be able to store keys in the app so that I can validate the user an allow them to access resources on the backend. However, I don't know what the best plan of action is to ensure user/business security.
Don't go down this route of storing keys in the mobile app, because as you already know, by your extensive research, they can be bypassed.
Instead use a mobile attestation solution in conjunction with OAUTH2 or OpenID connect, that you can bind with the mobile app attestation token. An example of this token binding can be found in this article for the check of the custom payload claim in the endpoint /forms.
Going the Extra Mile
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.
Our application is a Single Page App built with Angular and ASP.NET Core.
We have to integrate another web app which we will integrate in an iframe in our app. This app has to send data back to our application after the user finished his work.
I need to make sure, i can relate the data coming from this application to an authenticated user starting the operation in our app in a secure way.
Those were the options i thought in realizing the interface:
Generate a unique token in our application which knows about the related user and gets passed to the other application. The other application transmits this token along with it's other data back to our application and we can check this token on our backend to find out if it's a legitimate request and also relate it to a user.
Store cookies after authenticating the user in our app, so the other app could just post the data to our endpoint and the cookies make sure, the call takes place in the authenticated user's context. Also we would probably have to allow CORS from this site to make this work.
Use a non-http-based middleware (message broker) to connect the systems in a way, which keeps data transfer out of the browser.
Transmit the Bearer token from our application to the other application, so the other application can make an authenticated call to our application backend.
CORS would have to be activated as well for the other app's origin.
However i'm a bit concerned about the security implications this could have.
Which way would you suggest? Or would you suggest a completely other way of achieving the goal?
Thank you very much for any advise!
Number 2 and 4 will both have potential security issues. Passing authentication contexts between different applications should be avoided, instead each application should be authenticated independently.
Number 3 would add complexity to your architecture while bringing little to no benefit for your use case - message brokers are not trivial to configure and operate. I would also question why two apps need to be integrated in the client via and iFrame but then are somehow able to share a message broker.
Number 1 for me is the cleanest option from your ideas. Consider however, you will need to pass this token somehow in the client which may open security holes. Think about the negative implications of what could happen, should a nefarious 3rd party get access to this token.
In your place I would question why an iFrame. Would it be possible for your app to provide the UI and instead communicate with this other application over an API?
I have a .net WEB API publicly exposed and also a Xamarin Forms App which uses the API, the app needs to be extremely secure due to the data it manages.
I will create an HTTP Certificate for the WEB API.
The Xamarin Forms app will have a login/password to validate against a local Active Directory. via a /token endpoint, and using an Authorize attribute on all endpoints to assure that every HTTP call has the bearer token in it, I implemented that using this:
I based my implementation on this one:
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
Additionally the customer has asked us for Client Certificate Authentication, I dont understand how this totally works.
1. I need to add a certificate to the Xamarin Project, right? How do I Add it? How do I generate it?
2. In the Web API I need to validate each http call has the certificate attached.
I found this but not sure if it will work:
http://www.razibinrais.com/secure-web-api-with-client-certificate/
However when investigating this, I also found something about certificate pinning, which is basically security but the other way around, it means the Xamarin APP will validate if the server certificate is associated with the right server (or something like that), so there is no way of a MAN IN THE MIDDLE Attack.
I found how to implement it here:
https://thomasbandt.com/certificate-and-public-key-pinning-with-xamarin
Question is:
1. Do I need both ?
Something else that I should research for on this journey?
Certificate pinning and Client Certificate Authentication are 2 very different things. Certificate pinning makes sure your app is talking to the server it expects to talk to. It also prevents eavesdropping, which is known as a 'Man in the middle' attack. I just recently wrote an article about this on my blog.
Client Certificate Authentication works the other way around. It adds an extra layer of security so your server can be sure only clients that have the certificate can communicate successfully with it. However, since apps can be decompiled without a lot of effort, this client certificate can 'easily' be obtained by a malicious user. So this isn't a silver bullet.
From my experience, Client Certificate Authentication is often used in enterprise apps, when there is an Enterprise Mobility Management solution in place (eg. Mobile Iron or Microsoft Intune or others), where the EMM solution can push the certificates to the users device out of band.
Should you use both? That really depends on the requirements of your customer, since they mitigate 2 very different problems.
The Web API link you included looks like it should do the server job properly at first sight. This article also includes how to generate a client certificate with a Powershell command.
Generating a client side certificate:
Use the Powershell command in the article that you referenced in your question.
Otherwise, this gist might help you on your way.
Installation:
Add the certificate file to each platform specific project as a resource. This is usually done in the form of a .p12 file.
Usage:
That all depends on which HttpClient you are using.
If you use the provided Web API solution, you should add the certificate contents as a X-ARR-ClientCert header with each request.
I have the following scenario:
1.- A web api project in Azure, that I want to secure using Azure AD (I don't mind Token, cookie, whatever, as far as it meets the entire scenario)
2.- An Azure web site in asp.net MVC, also secured by Azure AD. This website has to call the web api controller with SSO (I'm using same Azure AD in the entire scenario)
3.- Some JavaScript code running in a page in SharePoint Online, also calling the web api controller in any secure way (The Office 365 tenant is also using same Azure AD). If you don't know about SharePoint, let's say I have an SPA project where I can only use Javascript and html (no server side code).
Following some of the MS Azure AD samples and some blogs from Vittorio Bertocci I'm able to get the points 1 and 2 working fine, using OWIN and Oppen ID connect. However, seems impossible to achieve point 3. As I'm inside a page in SharePoint Online, I can only use javascript, and not any server side code. I'd like to get a valid token for the current user, that is already logged in SP, and remember that SP uses same Azure AD that web api site.
Can I call the Azure AD and get a valid token, just from client code?
I'm open to any possible solution. I can do whatever in the web api project. If you are thinking in a SharePoint app with an appPart, and the appPart calls the web api from server side code, I agree that will work, but it's an option that is not allowed at the moment :(
Many thanks.
I have similar needs. While waiting for a Microsoft sponsored solution we’re working on the following approach.
3) in Your solution (i.e. HTML page with JavaScript, hosted in SharePoint Online and running in Browser) will call Services in 1) (i.e. Web Api Service layer in Azure).
In Our case we only want to validate that the calls made from SharePoint Online (via users browser, i.e. JavaScript) originate from a correct Office 365 / SharePoint Online user in our tenant.
We are opting out of using the App Model as we only want some simple HTML / JavaScript pages in our Intranet and don’t want App Webs. The Web Api server side code is kind of our “Web Part” code behind.
Change to the solution after trying it out and having workable code:
The auth cookies are ReadOnly and cannot be used. Instead we have registered one metod in our service layer as App in SharePoint Online (via appregnew.aspx). That methods url (e.g. https://cloudservice.customer.com/api/authentication/token) is registered as App start page in the app manifest and is deployed to a site Collection.
Now we can call our App via https://customer.sharepoint.com/sites/devassets/_layouts/15/appredirect.aspx?instance_id={GUID} i a jQuery ajax call and parse the result. AppRedirect sends the correct SPAuthToken which we use in our service endpoint (i.e. App start page) to call back to SharePoint and check context.Web.CurrentUser. User email is then stored in Table Storage with a generated Token which we send back to the caller (i.e. the jQuery ajax call to app redirect).
That token is then used in all other service layer calls in order to be sure of who is calling our service layer and in some cases perform authorization in our service layer.
Note, You can use the same approach in order to store Refresh and AccessToken in your client and provide that in all calls to your service from your client and use those tokens in order to do App Calls back to SharePoint. This enables HTML UI in SharePoint host webs and server code using user context in Azure service layer.
To follow up, ADAL.js has recently been released, and the ability to use CORS with O365 APIs was recently added, enabling a scenario for script clients to communicate with services protected by Azure AD, such as your Web API.
http://www.andrewconnell.com/blog/adal-js-cors-with-o365-apis-files-sharepoint
UPDATE 2018:
This is now supported by SharePoint Online and the SPFx development model, and officially documented, for instance here
Consume enterprise APIs secured with Azure AD in SharePoint Framework
Being said that the work done meanwhile by Vittorio, Kirk, and their teams, but extending that also to Andrew that has delivered great samples, is awesome; that doesn't really fully reply the original question because one of the requirements is to don't run the component as Add-in Part.
If you try to use ADAL JS (which starts its own OAuth flow) hosting that directly in a SP page, that's not going to work, or anyway you can expect a weird behavior for the user (cause of client redirects happening on the browser).
The solution proposed by Peter Karpinski is interesting, and will work matching the requirements in the original question, but requires quite some complexity and additional management/resources.
This recent article provides an alternative solution similar to Peter's one, but requiring less 'extras' and somewhat simpler, also reusing user's SP identity.
Consuming Azure Hosted Web API from SharePoint Online using JavaScript and Office 365 identities
and doesn't either require the use of ADAL on the client side and the implementation of custom security provider / token issuer on the server side.
The identity (cookie) will be passed via properly handling CORS (documentation) on both sides.
However, as you can read in my comments to that blog, this won't work normally with IE due to its security zone implementation. You'll have to be sure you have control on IE security zones on the clients, or have an alternative solution specific for IE.
As of today AAD does not support the OAuth2 implicit flow (or OpenId Connect variants) hence you can't obtain a token from AAD using a user-agent (browser), regardless of whether you hit the wire handcrafting the protocol or using a library.
However keep an eye on future announcements, as this is an important scenario for us!
HTH
Cheers,
V.
update we now support the implicit flow on our server, and we released a library for helping you consume the new feature: http://www.cloudidentity.com/blog/2015/02/19/introducing-adal-js-v1/
Thank youi for r your patience!
The fact that you say you can use only HTML/JS let me guess you're having a SharePoint-hosted App.
Azure AD Authentication Library (ADAL) doesn't provide yet in this moment support for HTML5.
I've been looking since a while (almost one year) on how to implement something as you say; but I couldn't find any working solution, which doesn't make use also of some 'code-behind'.
I'd suggest you then to move to a Provider-hosted App, where you'll be able to have some C# code, and make use of ADAL to retrieve and reuse the OAuth token.
Also, I think is worth to look at this documentation page:
Choose patterns for developing and hosting your app for SharePoint
at section Match your hosting pattern with your development goals
thanks for your help.
Well, it's not a SP-Hosted App, but it's same scenario. It's just a SP page in SP Online, so I can only use JS code like in a SP-hosted app.
As I said in my question, I agree the Provider hosted app is likely the right (or at least, the unique) solution, but that means to build and app, deploy it, and add teh appPart manually to the page (is not easy to package in a WSP). So, this solution is quite hard, when you only want to make some AJAX calls and show some data.
However, after all that I've seen, I think we can't do anything else. I'm gonna wait some more days to see if someone know any weird workarround that could work, and if not, I'll mark your answer as valid.
Thanks again!
I'm interested to know what methods people use to secure their webservices from unauthorized web service consumers.
There is a protocol specifically for web services security WS-Security. I've used parts of it in the past but at the time there was not a lot of support for it in .Net so it was a lot of work.
Currently with .Net I use SOAP Extension Headers. I have one web service call to authenticate and get a session token and then include that token in a SOAP header for every subsequent call, somewhat similar to this example. Of course all the request must travel over TLS to keep them from being compromised.
I usually require either a user id/password to be sent each time, or return a token from the first authenticated connection that can be used subsequently.
Nothing fancy. Pretty similar to standard web app login.
I've used both SOAP headers and method parameters to pass user credentials -- .NET makes using the SOAP headers pretty easy, but I had issues with this using Java (several months back). I also do some IP-based filtering if the service is not intended for client (browser) use, but rather from backend web servers. Public, browser consumable web services are often protected by session cookies -- i.e, requires a valid logon to the web site, then the standard session authentication mechanism is used for requests via AJAX to web services.
You can use network appliances such as IBM's DataPower or Vordel if you don't want to handle in your own application.