I would like to improve the security of the transactions that occur on an Azure website I am developing by using an SSL certificate. However, I know very little about the subject. Azure seems to support SSL and I can get certificates from numerous authorities.
I only want to be able to get to the transactional stuff if the connection is secure. The main home/landing page of the site can be arrived at using http or https?
Where can I go to find out more about SSL and particularly how I incorporate it into Azure websites?
You can take a look at this sites
http://www.windowsazure.com/en-us/documentation/articles/web-sites-configure-ssl-certificate/
http://www.windowsazure.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/
Related
My mobile app is using an HTTP-based API with endpoints that aren't hard to figure out, such as https://<domain>/api/config or https://<domain>/api/login.
So someone could create an account in the app, then use the credentials in some request-making desktop app ("rogue client") to send requests to /api/login and then, after "logging in" with my bearer authentication scheme, go on to other endpoints to see what data is being sent from there.
Such attempts could potentially let people peep into some sensitive data about other users that should only be accessible internally by the app alone.
What would be an established approach to improve my app's security in guaranteeing that any data sent from my backend API is accessible by the app only?
Specifically for iOS apps, are there any frameworks to achieve this?
My backend is Nginx & Django.
MAPPING AN API
My mobile app is using an HTTP-based API with endpoints that aren't hard to figure out, such as https:///api/config or https:///api/login.
All it's needed to map all the API endpoints being used by your mobile app is for someone to install your mobile app in a device they control and proxy the requests through a proxy, like the mitmproxy:
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
BEARER AUTHORIZATION TOKEN EXTRACTION
So someone could create an account in the app, then use the credentials in some request-making desktop app ("rogue client") to send requests to /api/login and then, after "logging in" with my bearer authentication scheme, go on to other endpoints to see what data is being sent from there.
Yes you can create the account in the app and extract the bearer authentication token, and for this you can continue to use the proxy approach I mentioned to map all the API endpoints. You can read this article to see how I use mitmproxy to extract an API key, therefore applicable for your bearer token scenario.
The mitmproxy allow us to intercept, manipulate and replay requests on the fly or at any point in time, therefore an excellent tool to poke around your aPI and extract all data while you use the mobile app as a normal user.
SENSITIVE DATA ACCESS
Such attempts could potentially let people peep into some sensitive data about other users that should only be accessible internally by the app alone.
Well here it seems more like a design problem of your mobile app and backend, because a logged user should never be able to access API endpoints as another user.
Also you need to ensure that each API endpoint strictly returns only the absolute necessary data for the mobile app do what it needs to do. Unfortunately more often then not developers have fat API endpoints that give away a lot of info, and then its up to the consumer to filter the data it needs. Don't do this, instead using roles to authorize what amount of data each logged user as access to in each API endpoint, therefore allowing for more or less data to be sent back in the response accordingly to his role.
Another thing to keep in mind is that developers tend to do too much business logic on the client side, and this approach also leads to fat APIs and to leak data that could be kept in server side if the API was the only one responsible to perform that business logic. Try to design your mobile apps to be as dumb as possible, and make them delegate to the backend all the hard work. This approach also as the advantage of making easy to fix bugs without needing to release a new mobile app.
IMPROVE API SECURITY
What would be an established approach to improve my app's security in guaranteeing that any data sent from my backend API is accessible by the app only?
Well you bought yourself a very hard challenge to overcome, but while hard is not impossible to achieve a solution that allows your API server to have a very high degree of confidence that the requests is receiving are indeed from a genuine instance of your mobile app.
So it seems that you want to lock your API server to only accept requests from your mobile app, and if that is the case then please read this reply I gave to the question How to secure an API REST for mobile app? for the sections on Securing the API Server and A Possible Better Solution.
Specifically for iOS apps, are there any frameworks to achieve this?
If you have read the reply I linked above, then you know by now that you should employ security in depth, by using as many layers as you can afford, being the most effective of all the Mobile App Attestation concept.
Bear in mind that has you add more security layers, more time consuming will be for an attacker to overcome all of them. This also raises the bar for the skill set necessary for an attacker to have in order to bypass all of them, thus putting at bay scripts kids and seasonal attackers.
By the way don't forget to always apply strong code obfuscation techniques to your code base.
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 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 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.
The correct way is to use App Attestation
App Attest Flow
It is a cryptographically secure way to make sure your app is the thing which is accessing your API and not something else.
Apple has an App Attest service. Some docs are located here:
https://developer.apple.com/documentation/devicecheck/establishing_your_app_s_integrity
https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server
Here is the best practice of using JWTs.
On the client-side, you create the token (there are many libraries for this), using the secret token to sign it.
You pass it as part of the API request, and the server will know it’s that specific client because the request is signed with its unique identifier
Edit: Based on comments and discussions, reaching to full security is not possible, But you can make it harder using the above blog post practice.
i have to develop the backend of a mobile app (IOS swift). I started to create the api with laravel.
But i'm concerned about the access to my api: how i should i give access to my api ? i've heard some stuff about Oauth key and passport .
For my app i want to :
-user can create an account (i guess it's with JWT)
-user can navigate in my app and start to use it after they create their account.
I wan't know the basic process about creating an api for a private use (only my app will use it) what security stuff should i implement and how the account creation for my app will work. Thx :)
PRIVATE APIs
wan't know the basic process about creating an api for a private use (only my app will use it)
Let me tell you here a cruel truth...
No matter if an API doesn't have public accessible documentation or if is is protected by any kind of secret or authentication mechanisms, once is accessible from the internet is not private any-more.
So you can make it hard to find and access, but to truly lock it to your mobile app you will gonna have an hard time to do it so.
WHO AND WHAT IS ACCESSING THE API SERVER
The WHO is the user of the mobile app that you can authenticate,authorize and identify in several ways, like using OpenID or OAUTH2 flows.
Now you need a way to identify WHAT is calling your 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 your genuine mobile app or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
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 and some go the extra mile and compute it at run-time in the mobile app, thus becomes a dynamic secret in opposition to the former approach that is a static secret embedded in the code.
REVERSE ENGINEERING A MOBILE APP BINARY IS EASY
The truth is that anything running in the client side can be reverse engineered
easily by an attacker on a device he controls. He will use introspection frameworks like Frida or xPosed to intercept at runtime the running code of the mobile app or will use a proxy tool like MiTM Proxy for watching the communications between the mobile app and the API server. Normally their first step in reverse engineer a mobile app will be to use the Mobile Security Framework to reverse engineer the binary of you mobile app to extract all static secrets and to identify attack vectors.
Mobile Security Framework
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
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.
MiTM Proxy
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
So now what... Am I doomed to the point I cannot protect my API server from being abused??? No quiet so... hope still exists!!!
A POSSIBLE SOLUTION
So anything that runs on the client side and needs some secret to access an API can be abused in different ways and you can learn more on this series of articles about Mobile API Security Techniques. This articles will teach you how API Keys, User Access Tokens, HMAC and TLS Pinning can be used to protect the API and how they can be bypassed.
But i'm concerned about the access to my api: how i should i give access to my api ? i've heard some stuff about Oauth key and passport .
For my app i want to :
-user can create an account (i guess it's with JWT)
-user can navigate in my app and start to use it after they create their account.
...and how the account creation for my app will work.
Laravel Passport is an OAUTH2 server thus is a good solution to use for user creation and identification, thus to solve the problem of WHO is using your mobile app and API server.
what security stuff should i implement
To solve the problem of WHAT is accessing your mobile app you need to use one or all the solutions mentioned in the series of articles about Mobile API Security Techniques that I mentioned above and accepted that they can only make unauthorized access to your API server harder to bypass but not impossible.
A better solution can be employed by using a Mobile App Attestation solution that will enable the API server to know is receiving only requests from a genuine mobile app.
Mobile App Attestation
Use a Mobile App Attestation solution to enable the API server to know WHAT is sending the requests, thus enabling it to only respond to requests from a genuine mobile app.
The role of a Mobile App Attestation service is to guarantee at run-time that your mobile app was not tampered or is not running in a rooted device 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.
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.
The Mobile App Attestation service 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.
Not sure if this is the right place to ask, sorry if its not, i would to know where the right place is.
I created a chat app that uses firebase and a nodejs server hosted on heroku
The messages are stored in firebase and are not encrypted.
The nodejs server is not very secure, i have passport authentication, but data is not encrypted or secure.
What is apple's policy on servers and not encrypted content. i tried looking around and couldnt find any useful content.
I just need to be pointed in the right direction.
You need to ensure that the data stored on your device locally is protected and encrypted following the Apple guidelines. Your app needs to communicate with your servers over HTTPS layer as per the requirements of apple policy.
There is no policy for security on your backend servers. However it's always a good practice to keep your data stored securely and encrypted at server level. Passport authentication is good to make sure that your app will server data to the authenticated users only.
You can make your web-services (nodejs server) secured using various security options (oAuth, basic authentication, custom authentication, etc.)
Apple will not reject if your server is not secured.
How to verify if the API being hit is from the actual application and is not going through any MITM attacks.
I understand SSL certificates can be used to achieve transport level security and the app can be sure it is taking to the correct server, but how can I attain the same thing from app side.
I just want to make sure that only my app is hitting my services and the hit is not coming from somewhere I don't trust.
Thanks
Have a look at SSL again - it offers client certificates, for example, to do so. Yet, this only shifts the problem as an attacker might use the same mechanism the apps use to get certificates. (An shared API token is often considered okay as well and much easier to implement.)
In general, you cannot achieve a guarantee for that. You might get a good result by issueing certificates based on user authentication by external means (e.g. make users put in their user names and passwords) or make it hard for adversaries to abuse your API by using reverse turing tests (e.g. completely automated programms to tell computers and humans apart, aka CAPTCHAs).
The same way that the client validates the server based on its server certificate, SSL supports the server issuing client certificates and requiring communication to be signed with that specific certificate.
With this approach it comes down to possession of the certificate rather than, say, knowledge of a password. Which in the case of mobile is problematic, because an attacker can more easily gain physical access to your device and read your app's documents. So take care to store your keys in your keychain.
Also, your method of handshaking with your server and asking it to issue a client certificate becomes a security bottleneck. An attacker could, since she has physical access to the device, sniff the traffic and easily figure out the API calls needed to get the server to issue the proper certificate.
Read Apple's business oriented document on security in iOS here.
I have an iOS application that authenticates to a Rails application. The first time it authenticates, it needs to submit a username and password and in return the rails application returns a token which the iOS application can use to authenticate in further communications.
The information being passed between them consists of the user's email address and other trivial information, but nothing highly sensitive like financial details etc. I need a way to protect these communications.
What is the simplest way I can add this protection?
HTTPS is a straight forward way to secure communication as is passes over the wire. To reuse and token for subsequent communication can be done with oAuth. You may want to take the approach that Facebook adopted in their iOS SDK. They put up their login page in a UIWebView (HTTPS) and return the oAuth token for subsequent calls.
EDIT: Since SSL seems to be "off the table" - why don't you just authenticate with Basic Authentication and have each call re-authenticate instead of using a token.
Get a trusted and valid certificate for your webserver and use SSL / HTTPS. That's what most people do.
I wouldn't recommend implementing your own encryption method.
Your problems with SSL locally reminded me of this tutorial
When Ryan forced SSL, he mentioned that it would not work in the development environment (locally), only in production and testing. This issue is discussed around the six minute mark. It appears that if you deploy your app with ssl then it will work. This is also the case with Omniauth and using external providers. It does not work locally but it does when deployed.