I've uploaded and encoded several videos to windows Azure Media services. How can I provide secure streaming access to subscribers logged into my MVC 4 web site hosted as an Azure service? I basically don't want them to be able to watch a video if they are not signed in?
(I've been reading about Azure Media services and I can't find anything and that usually means I'm missing the obvious!?)
Now you could use AES or PlayReady content protection with Azure Media Services to encrypt your file over the wire. We provide token authentication on top of the key delivery, which ensure only your authorized user could get the content.
For more information, please read my blog post here: http://azure.microsoft.com/blog/2014/09/10/announcing-public-availability-of-azure-media-services-content-protection-services/
There are a couple of options for you. Currently you can encrypt the video using PlayReady DRM and then use a third party provider such as BuyDRM or EzDRM to handle authentication and DRM license delivery. EzDRM is currently available for purchase via the Azure store. This will provide you the highest degree of protection for your videos. Long term we are looking into more light weight approaches for authentication and video content protection for the cases where protection provided by DRM is not needed. We will post updates to http://social.msdn.microsoft.com/Forums/en-US/MediaServices/ when new capabilities are available in Azure Media Services.
Related
I am building a mobile app and I was wondering if my API key can be seen when I make a GET request to my database through the API?
What I am currently doing is making an HTTP GET request where one of the params is the API Key. So if any user were to see this URL, they also can fetch this data.
Can any user see this URL being sent? I am doing this through the Flutter HTTP package.
Sensitive Data in URLs
What I am currently doing is making an HTTP GET request where one of the params is the API Key. So if any user were to see this URL, they also can fetch this data.
Using sensitive data, like API Keys, as an URL query parameter was made popular by many popular internet services since earlier days, thus a lot of tutorials and docs use this approach and this is a huge disservice for the security of any application, but a huge gain in terms of developer convenience.
Keeping sensitive data in an URL query parameter is a security disaster waiting to happen at any moment, but it's the type of disaster that happens and you don't notice until is too late, like when you discover you have been data-breached because an attacker was able to get the API Key from the logs server that was left open to the public or because you use a CI/CD pipeline that logs them by design (yes a famous one does that).
The correct place for an API key is as an header in the request, not as a URL parameter or a post parameter, but can still end-up in your logs server, but is less likely.
Extracting an API Key with a MitM Attack
I am building a mobile app and I was wondering if my API key can be seen when I make a GET request to my database through the API?
Yes, it can be seen and extracted from your mobile app binary or by intercepting the API requests made through HTTPS, also known as a Man in the Middle (MitM) attack.
Can any user see this URL being sent? I am doing this through the Flutter HTTP package.
To see how this can be easily achieved with MitM attack I invite you to read 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.
If you want to learn more about API and Mobile security then 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.
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.
Yes if you are not using ssl you are sending everything in plain text which can be intercepted.
if you are using ssl still your URL can be stored in logs on api server so instead of sending key in query parameter use POST request and append the key in custom header or form parameters.
I have actually one SPA in ReactJs + one mobile application in Flutter + one REST API developed with SailsJs running on a separate server. I managed user authentication with a secured session cookie sent back by the API when we are login with valid information (id/password).
So all the endpoints that require users to be authenticated are protected (unless there are others security best practices that I'm not aware of?). The session cookie expiration and validity are checked with each call to one of the protected endpoints.
I really read a massive amount of topics and blog posts talking about securing REST API. And my problem is never or barely represented. So now my main problem is :
How can I restrict my public API endpoints (login & register currently) that does not require users to be authenticated (since there are the endpoints used to achieve this mission...) to be used only in my trusted client apps (web and mobile)?
How can I prevent another app developed by another person to use these endpoints?
I don't want anyone to login via my API unless it is done in the client apps I am developing... I don't want anyone to replicate my applications and successfully use my API that way with 0 protection, without knowing it...
I see a lot of popular services with login API routes (Heroku for example) that can't be accessed in Postman with the same parameters (403 error code). So it is possible. But how they do that? There is nothing in specialized forums that handle this or I missed something!
I tough of a secret token stored in the client to authenticate it but it is literally public with web developer tools for example.
Need some advice.
Thanks
USER AUTHENTICATION IS NOT APP AUTHENTICATION
So all the endpoints that require users to be authenticated are protected...
This endpoints are only protected regarding to identify, authenticate and authorize Who his in the request, but not for What is doing the request, and this is a topic not very well understood among developers, be them juniors or seniors.
The Difference Between WHO and WHAT is Accessing the API Server
In an article I wrote, entitled Why Does Your Mobile App Need An Api Key? you can read with more detail the difference between Who and What is accessing your API server, from where I quote the following:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
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.
So the Who is the user of your API server that you will be able to Authenticate and Authorize access to the data, and the What is the software making that request in behalf of the user, your genuine app, a tampered one, an automated script or someone manually poking around with your API via cURL, Postman or similar tools.
By now I hope that you have enough knowledge to understand why user(who) authentication is not the same as app(what) authentication.
LOCK THE API SERVER TO THE APPS
How can I restrict my public API endpoints (login & register currently) that does not require users to be authenticated (since there are the endpoints used to achieve this mission...) to be used only in my trusted client apps (web and mobile)?
I think that by now it may be clear to you that it's not only the login and registration endpoints that need to be protected from What is doing the request.
How can I prevent another app developed by another person to use these endpoints?
I don't want anyone to login via my API unless it is done in the client apps I am developing... I don't want anyone to replicate my applications and successfully use my API that way with 0 protection, without knowing it...
This is extremely hard to achieve for web apps, but possible with an high degree of confidence for mobile apps when the Mobile App Attestation concept is implemented.
For web apps
Due to the nature of how the web was built, all it's necessary to inspect a web app is to hit F12 or inspect the page source, and then search for whatever you need to access the API server from another tool.
You can learn some useful techniques to help your API server 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, specially the section dedicated to Defending the API Server.
For mobile apps
To learn how you can lock your API server to your mobile app I recommend you to read my answer 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.
Endpoints to Secure
So all the endpoints that require users to be authenticated are protected (unless there are others security best practices that I'm not aware of?).
It's up to you if you only want to enhance the security of your login and register endpoints, but my advice is that you enhance the security of all them regarding the detection for What is accessing them.
POSTMAN WITH HEROKU AND OTHERS
I see a lot of popular services with login API routes (Heroku for example) that can't be accessed in Postman with the same parameters (403 error code). So it is possible. But how they do that? There is nothing in specialized forums that handle this or I missed something!
I never used Heroku, but when I am using an API that doesn't work in Postman, but works in other clients, let's say from cURL, then I disable Postman from sending it's own user-agent and normally the API will start accepting the requests.
If doesn't then they may be doing device fingerprinting:
A device fingerprint or machine fingerprint is information collected about the software and hardware of a remote computing device for the purpose of identification. The information is usually assimilated into a brief identifier using a fingerprinting algorithm. A browser fingerprint is information collected specifically by interaction with the web browser of the device.
The fingerprinting can be done in active or passive mode. In active mode some Javascript runs on the client to collect some data to send back to the API server, while in passive mode it uses the information available from the request in the server, like the http headers and request parameters.
While this raises the bar to fake What is doing the request, it can be bypassed by observing how a trusted client sends the request and mimic it. For an attacker it's just a little more work to enumerate all variants and then automate them.
DO YOU WANT TO GO THE EXTRA MILE?
I really read a massive amount of topics and blog posts talking about securing REST API.
First and foremost my congratulations for putting such effort in educating yourself about securing your API.
I don't know if you already read some of the OWASP resources I am about to link, but in any response to a security question I always like to reference the excellent work from the OWASP foundation ;)
For Web Apps
OWASP Web Top 10 Risks
The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.
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.
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.
I am currently in the process of evaluating the usage of azure media services to store our product tutorial videos, bug reports etc. We encode and store the videos locally and are now able to upload them to azure media services, and then publish to get a SAS url that we can distribute out to our internal users and clients.
We want to be able to grant access to only specific users to these uploaded videos and also track these users, number of views etc. Also for internal users we would like to be able to use integrated windows authentication to access the videos.
Can someone please advise if this is possible? We are not that interested in encrypting of the content itself.
Thanks,
Ilias
If you don't want videos to be shared with unauthorized users you have to apply DRM or AES encryption policies. Without it any logged in user can leak video published uri or what is called "locator" in Azure Media Services. To read more about AES encryption see https://msdn.microsoft.com/en-us/library/azure/Dn783457.aspx.
In my blog post (http://gtrifonov.com/2015/01/24/mvc-owin-azure-media-services-ad-integration/) i showed how to integrate Azure AD with Azure Media Services AES capabilities. To allow playback for users belonging to certain azure AD user group.
If you don't wan't to utilize dynamic encryption, you can issue a unique locator per user session for an asset. But in this scenario you will be limited by 5 active locators per asset.
"because of a shared access policy restriction set by Azure storage services, you cannot have more than five unique Locators associated with a given Asset at one time" - https://msdn.microsoft.com/en-us/library/azure/hh974308.aspx
If you want to protect your training materials from unauthorized access and building solution which will have many users accessing same asset simultaneously, you need to use DRM or AES functionality.
I'm currently working on an FTP client as a packaged Chrome App.
Is safe to store user credentials for different FTP servers using chrome.storage.*?
According to the docs:
Confidential user information should not be stored! The storage area isn't encrypted.
Don't store sensitive information using the chrome.storage.* APIs. See this question for more information.
How do we maintain the data security in iPhone apps. For instance, a custom app for a bank needs more security in terms of:
1. Data in transmission
2. Data in rest (Data inside iPhone)
What are the potential steps one can take to ensure the integrity and security of data? What support iPhone SDK provides to achieve this? How do we encrypt/decrypt the payloads? Save the data in encrypted format locally and how do we protect this from potential threat of decryption by unauthentic user?
It's a big topic but there's a great, free video on this subject from Apple's 2010 WWDC.
http://developer.apple.com/videos/wwdc/2010/ (sign in with a developer account)
Session 209, "Securing Application Data"
Also useful: Session 204, "Creating Secure Applications"
For the wire use SSL to a server that uses oauth or some similar authentication mechanism.
For local data use the keychain ( http://developer.apple.com/library/ios/#documentation/Security/Reference/keychainservices/Reference/reference.html and http://developer.apple.com/library/ios/#samplecode/GenericKeychain/Introduction/Intro.html)