How Firebase domain whitelisting works behind the scene to make it foolproof?
To be clear, I'm not trying to configure my domain in Firebase console(Which I understand how to do), but instead, trying to build some similar source domain validation in my server side - API code. What web standards Firebase uses to make sure only authorized domains make API call as the API token is public.
What if someone uses non-browser HTTP client with source domain headers faked with the API token of my app? I assume Firebase would've thought about such case and its covered. Trying to understand the how its foolproof.
My guess would be that it is not fool-proof, but limits the use cases in certain situations.
You could use such a whitelisted domain in the CORS related headers, this would prevent certain actions from modern browsers.
The whitelisted domains can also used with authentication to make sure the redirect after login is to your domain.
Theoretically you could go and check the Referer header, but a lot of browsers do not supply it for security / privacy purposes so that would be a bad option.
As for firebase, since it is quite hard to use firebase without the library, the library can just supply the current url to the server and prevent any action from unlisted domains. This is by no means fool-proof.
What if someone uses non-browser HTTP client with source domain headers faked with the API token of my app? I assume Firebase would've thought about such case and its covered.
I think your assumption is wrong. Clients are insecure and any request can be faked. Eventually it's a packet that is sent to a server and if you control the sender you control the contents of the packet.
If we monitored the connection between the client and Firebase we can figure out a way to perform the same tasks from another (out of browser) process.
TLS. If you look at the IETF's documentation Handshake Protocol Overview :
When a TLS client and server first start communicating, they agree on
a protocol version, select cryptographic algorithms, optionally
authenticate each other, and use public-key encryption techniques to
generate shared secrets.
So, I think this is the mechanism used for domain whitelisting. Regarding faking HTTP headers, Firebase does not accept HTTP, only HTTPS (TLS).
Related
I have two domains
Example :
a.com and b.com
I try to implement SSO Cross-domain authentication for these two websites
I refer to this link reference How youtube gets logged in to gmail account without getting redirected? to implement like Gmail and YouTube
I have doubt about that
How to send tokens from one domain to another domain using iframe
How to pass tokens in a secure way
If I use an intermediate domain how to prevent that domain call for accessing cookies value I want to set the cookies in the second domain
Please help me to implement I searched but the sample code is not available in asp.net
have you tried this method?
Using Reverse Proxy
As #David suggested, use a reverse proxy like Nginx or HAPorxy to serve both the applications from the same domain - protocol://host:port. All three things should be equal.
Using cookies instead of LocalStorage
If you use cookies instead of LocalStorage, then host ports do not participate in determining site policy. So two application running on the same host but the different port will share cookie without any extra work. To protect the cookie, use an HTTP-only cookie, same-site cookie.
Using URL to share - IFrame only
If you are using iFrame, then you can use URL to share the token. When the outer window is loading the iFrame, send this information via hash like http://localhost:8081/somepage#token=1234
Using hash will allow the page to send data to an inner page without being sent over the wire.
Using window.postMessage - IFrame only
Using window.postMessage, you can simply pass the required data to the inner window/iFrame. As long as you control both the endpoints, you can easily do cross-domain message sending.
In the end, it really depends on your security requirements, ease-of-maintenance, etc.
The best of this is using oAuth https://oauth.net/ provides a comprehensive definition of this.
There are many open-source implementations of oAuth consumer and server available.
The concept is that a third URL will authenticate and maintain the primary session and pass tokens via URL on redirect. The consumers can utilize tokens to request the server for details directly.
Overall benifit is that you will get implementations via open-source communities in a language of your choice, and you will be able to utilise third-party logins. There are other standards you can look into as well are SAML , OpenID and LDAP and products like shibbobleth,CAS and Azure AD.
I am using Backbone.js and it communicates with a stateless rest API. Some calls require authentication, through HTTP basic.
What I don't understand is, somehow I have to authenticate each request, how could I do this securely? My first thought was to have a cookie, store the username and password but this would be vulnerable?
Can this be done securely?
There are two themes to this question. One is about security and one seems to be about REST rules.
The way to do authentication securely, is to pass that data through an SSL connection. It's the only way to securely transfer data over the wire.
With regards to sending authentication using basic auth over each request (REST), not many people I know do this in reality.
There's always a big long discussion on how much security is enough security and it really depends on your application and what the purpose is. I know this isn't the definitive answer you might be looking for but I'll just give you my take and how I'm going about dealing with the issues you mention.
With RESTful apps, the story is one should authenticate each request but in real practice I find this is more a "guide" than a hard rule. Rare is the fully RESTful application that follows all the rules. I use an encrypted cookie to store the user session data with a standard authentication flow that happens once and expires in a week. Data transfers happen through SSL to prevent MITM attacks and a modified Backbone sync sends a CSRF token along with each POST, PUT, DELETE to prevent cross site request forgeries. Probably "good enough" for the social app that I am working on. Maybe not if you're doing bank wire transfers and stuff. Hope this sort of gives you a point of reference in judging what you might want to do.
Is https://github.com/fiznool/backbone.basicauth something you'd find useful?
This plugin enables access to remote resources which are protected by HTTP Basic Authentication through your Backbone Models and Collections.
How does it work?
A resource protected with HTTP Basic Authentication requires the following HTTP header to be set on every request:
Authorization: Basic
The access token is formed by taking the username and password, concatenating together with a : separator and encoding into Base64.
This plugin handles the Base64 encoding and automatically sets the Authorization header on every request which uses Backbone.sync.
I am planning to implement API security in my REST application, Where i need work for authorization URL (on server PHP application) which will return a session token to client (mobile clients android, iphone, BB, wp7, wp8)requesting this url.
After looking for possible solutions i found these two perfect for my needs. but i am not able to decide on solution which will survive me on long runs.
Using RSA encryption with openssl for transferring user data to authorization URL (i am going with openssl just to stick with standard and secure method).
I have a hunch that it's possible to just use HTTPS to pass the user data and let OS handle encryption/decryption.
However, I am particularly inclined to first approach, since here client will not be able to make successful call to authorization url unless it has access to public key. But i am not sure about how well this approach will gel with all mobile clients.
Any help on this is much appreciated!..
You should be ok when sending the authentication URL over SSL. SSL will authenticate the server and make sure that the data is protected against eavesdropping and man in the middle attacks. The URL will then be send over this protected channel, so after verifying the URL, the server can determine that the client is indeed the right entity. The token can then be safely send to the client over the same SSL session
If you go with your own scheme you will have to setup your own key management scheme and protocol. This is extremely hard to get right. Your comment on having access on a public key is a good indication that you will fail. SSL is not perfect either, but it has had a lot of scrutiny, and chances of it failing out of the blue are slim.
In other words, choose #2 over #1.
So feel free to not only answer this question but to throw out suggestions or improvements. I've never put together a large scale web application before. Here's my thought process:
Persistence Layer: Standard Database (MySQL right now)
Business Logic Layer: REST-like structure (PHP, Java Servlets, etc...)
Presentation Layer: Web Browser, Android devices (application not browser), and others
The reason I selected this architecture is so that devices can devise their own custom UI's and tap into the REST-like functionality by using GET, POST, and what not to interact with the server.
Problem 1:
The problem is, how do you secure user's information? You can authenticate the user over an SSL connection and return a special HASH so that the user can manipulate their account but if someone is listening on the network, all they have to do is listen for a REST call and steal the HASH. One solution is that all REST-like calls have to be over SSL, but this causes another problem.
Problem 2:
If the REST procedures are in SSL, the browser has to use SSL for everything which from my understanding can be slow and cumbersome when unnecessary. Also, SOP makes it impossible to use SSL ajax calls to the REST procedures from an unsecure browser. HTTP and HTTPS are considered different origins even though its the same origin, different protocol.
Is this solution viable? How would I solve these two problems? Or possibly (probably) is there a better architecture I should look into for my web application. Thanks in advance for all suggestions.
If you want to secure the information you have to use SSL, since anybody can listen the network, and see the user information. If you want to secure the access, then use HTTP authentication RFC2617. Over SSL, Basic is secure enough, but if you don't want to use SSL for every request, Digest is the way to go:
your application can be stateless: i.e. more restful, easier load balancing, ...
the authentication token can hardly be reused if listen (no session hijacking)
almost every HTTP client (browser or lib) can use basic or digest HTTP authentication.
As it turns out, there is actually no great solution out there for this answer. You can either protect everything with SSL or devise your own home brew authentication system. A common method is to send the user a unique HASH, store the HASH in the database and in a cookie on the client's machine. Then only that user's IP, User-Agent, etc.. will be authenticated to that cookie.
So the answer is yes, the solution is viable. Extra security precautions will need to be maintained in order to disallow account hijacking. SSL for login will protected the password. A unique hash will allow the user to continue being authenticated without giving away their password to the account. Storing a large amount of information about the user such as IP, browser agent, etc... will disallow easy hijacking of an account.
I have Android app that talks to .net 2 webservice (IIS7) using http get and managed to make it run on https using self-signed server certificate (but not requiring client certificate).
I see all http traffic is encrypted and it looks secure.
Now what options would I have on how to authenticate client? For example, I like to block webservice access from internet explorer on PC.
Client-authenticated TLS handshake described here would be a way to go?
Then how can I accomplish that? Some advice or example will be appreciated.
Well, given that each user should authenticate anyhow, you probably want to setup some sort of per-user authentication strategy for a variety of reasons. First, given this might be a widely distributed app, having a single "gold master" authentication certificate or credentials will ultimately fail as someone will hack it -- either grabbing the cert or grabbing the account. And then what do you do? Second, its not particularly hard to handle. You can easily use ASP.NET membership to back it, and then take the credentials a number of ways depending on the nature of the service. Third, it is alot easier to manage than client certificates.