I would like to write a JS function to have access from the browser to the public data stored on the hardware security token inserted in an USB port.
Specifically, in an intranet where ALL users have security tokens, I would like to have some sort of landing page, which will ask the user to enter his/her security token credentials (inserted in the USB port), and then read the public information from that token (I do not really need ALL of them, but I am interested mostly in the user name, certificate name(s) loaded in the token and their expiration date) and load them in the web page (to be displayed).
I have little to none experience with security devices like that, but I assume this is not a very complicated issue (though "googling" did not manage to get me in the right direction of how to make it work).
Thank you.
In my company we created a service installed installed in client's device, this service uses java to access the token and it provides an API(in client localhost), not sure if it's the best way but it works, if you find another way to solve this issue please leave a comment.
You can use the WinUSB API implemented in Chrome v54+.
You'll need to know the intrinsic structure of your USB token.
Related
Firstly, sorry for the format of this question. I know the rules for this site, but I haven't previous work nor investigation, because, basically, I don't know where to start...
I'm content with a tip for I start.
I'm searching how restrict calls to an api rest made in expressjs from (only) a native mobile app (ios and android). I thinking in a token, but I don't think it's a very safe idea, because any people can take the token and simulate to be the mobile app, or I'm wrong?
Thanks in advance!
You cannot restrict access to a REST api from only a native mobile app. The internet is wide open for access from any client so if you have a REST server, then any client can access it, whether mobile or not.
You can control access via authentication. So, usually what one would do is to require some sort of account access and then have your server watch for unexpected or unauthorized use and, if found, you disable that account.
You could also embed "secret" credentials in your mobile app and use those as the authorization over SSL, but a determined hacker could still get the credentials out of your app if they wanted to.
You can't restrict a public REST Api. Any request that your mobile users send can also be send by anyone.
Maybe you can keep a 'secret' string and attcah to http requests, but it can be easily exposed by sniffing http traffic or decompiling the apk.
Your last option is restricting access by IP, but I don't know if it's suitable with your case.
Of cource any one can simulate any APIs, it would just need a sniffer and the understanding of the right data format (like the format of the JSON object that is sent by your client app).
Anyone can go ahead, figure out how the WhatsApp works and simulate such an app. This can even happen when you are getting each user to Sign up first, then the "simulator" will just have to simulate that process too.
But, generally, what a developer wants is that :
People use his app
People use his REST APIs
Point 1 implies Point 2, but Point 2 does not imply Point 1. You cannot stop a hacker or someone from using your APIs without your App, you can just slow his simulator-development-process using some techniques.
Then you might ask, cant he flood your server with millions of request ? Of course he can. That a DoS attack. In theory, he can even use manny android simulators and install your App and then flood your server with millions of request.
Any one can use your APIs if you open it to the internet world.
I am trying to embed facebook auth into my application.
My initial effort was to login in browser and obtain code. I pass this code back to my api and obtain access token (that stays with the server) and route all my requests to FB Api through my server. Seemed totally secure to me as my client has no information to be able to make authorized calls to FB as my app.
I however have been looking at FB Javascript SDK to avoid writing code for dialog opening and closing and noticed that it allows me to getLoginStatus and returns me the access token. Also, I went over FB auth flows in their documentation and they say that client-server hybrid flow is okay to do where server actually gives "Long lived access token" back to the client and advises me to use HTTPS (fair).
Now all this gets me thinking if this is a security concern. Can't I as a potential hacker inject some javascript into the user's webpage that could either a) make a getLoginStatus and get the access token or b) just get the access token by making a request to my api server and get the access token and then use that to post (assuming that user authorized my app to do so) to facebook as if my app was doing it?
I am a security newbie and maybe overlooking a bunch of stuff here but could someone help me understand what I'm missing?
Thanks in advance!
PS: I do know I can enable further security to ensure that I need the app secret every time I want to make a request which the client can't do as that information will never be available on client side.
I am not a security expert, just some thoughts: in your question, you are assuming that the hacker somehow injects the script into the webpage in the user browser using malware and that script then interacts with the data you have client-side.
Now, if we imagine this actually happened and the evil script has full access to the web-page data, even if you don't have the access token on the client, what prevents the evil script to make requests to your server and interact with facebook through your server?
Moreover, if the user opens facebook itself and authorizes there, the evil script could be injected into facebook page and do any actions on behalf of the user, just sending the requests to facebook server.
This way, it looks for me that if the situation you describe happened, it would not really matter if you storing the access token client side or not - anyway the evil script will be able to do it's job.
Practically, if you are worried about security - first carefully check all the facebook docs related to authentication and security and follow their recommendations. Second - search for common known attack vectors and recommendations of how to avoid security risks in your application.
If the user already has malware on his computer which is able to alter browser behavior (like inject additional scripts into pages), you probably can't do much about it.
You can only get your access token if you have a valid redirect URI which equivalent to your Site URL on your facebook application settings..
also, it needs permissions before you can post using the facebook access_token.
You can check the API calls at https://developers.facebook.com/tools/explorer/
I'm a regular reader here at stack overflow but this is my first question.
I'm developing an authorization-server using the OAuth2 specs. And I just got stuck with how do I ensure the first-party client authenticity while using the password flow. I read many forums and this is what I got:
Javascript single-page clients
This blog post by Alex Bilbie, he states that to avoid the client_secret problem we should just:
It’s simple; proxy all of your API calls via a thin server side component. This component (let’s just call it a proxy from here on)
will authenticate ajax requests from the user’s session. The access
and refresh tokens can be stored in an encrypted form in a cookie
which only the proxy can decrypt. The application client credentials
will also be hardcoded into the proxy so they’re not publicly
accessible either.
But now this proxy can be accessed by someone impersonating my
angular app. And then I came across this blog post from Andy
Fielder: How Secure is the OAuth2 Resourc Owner Password Flow
for Single Page Apps. He basically says to rely on CORS to
avoid impersonating JS clients.
It is a good idea to use both approaches to secure my JS app?
Native Apps (Desktop and Mobile)
In the case of mobile apps, I only found cases for Authorization
Code and Implicit flows. This is not what I want, as the redirects
will compromise the user experience. So my thoughts on this is:
I will use the ROP flow and then register the client with a
client_id generated for this particular installation and attach it
to the user account, receiving the access_token and a
client_secret as response. Any other token request made by this
client MUST carry this credentials (as the client_id is specific
for the installation, I will be able to check if this client is
already authenticated). This way if someone uses any credential for
impersonating a client, or even registers a bogus client, I can take
mesures to revoke the user and client access.
I know that this can be overthinking, and I also know that some of this matters doesn't avoid anything. I just feel that is my job to protect my API as much as I can.
I would really appreciate your thoughts about this matters! Am I really overthinking? Should I just use the concept of a 'public client' and carry on?
Thank you all and happy coding!
First of all, this problem is not a common priority because most applications are developed first with website, and after with the API. This is probably the reason because no one knows how to deal first clients with oauth2, because everyone have developed other ways to do that and oauth2 is needed only to grant user access to third party applications.
Even if you have develop the oauth2 authorization server only for your first clients applications (thinking about a single authentication mechanism instead of developing many), you should try to develop the authorization code or implicit grant types. You will realize that you need a way to check what user is actually logged in.
The two common methods are:
user session (based on Cookies)
user access from localStorage (based javascript)
In either ways you need to check your application security, user session is vulnerable to CSRF, localStorage are vulnerable to XSS. There are a lot of articles about how to secure your website against either, so I will not suggest anything here, you just need to know that they exist.
Now that you choose your authentication method we can start to do some consideration about:
Javascript single pages applications
Proxy
Having a proxy that filter all requests in my opinion is like to have a door with the keys always inserted. It's useless even build the door.
However, for session based authentication it's the only way to do it. Allowing session authentication on your Rest API will open to CSRF security issues, so you need to have a proxy layer that get the user session, retrieve the access token from the session and do the request to the Rest API adding the Authorization header.
CORS
With this method you need to store the user access token in the localStorage, because the token is retrieved from the Js client directly.
Using CORS you are sure that other websites cannot do requests to your Rest API from a browser. But your first client need to be public (ie: it does not have a client_secret).
Native Apps (Desktop and Mobile)
In my first application I tried to use the same mechanism that you suggest to secure the auth flow. However that type of mechanism require that you identify every user client in an unique way. This is not possible in iOS for privacy reasons and with some probability it will denied in the future releases of Android. So you should rely on a public client and add only the client_id in your native application code.
This means that your native app client/your js client can be impersonalized? Yes, and there is no way to prevent this with oAuth2 resource owner password credentials grant type.
The main reason about this is because oAuth2 is not for authentication, only for third-party authorization, and that grant type was added only for specific third-party applications trusted enought to use directly the user password. You could read more about this argument here and here.
At the end
You still need a way to auhorize your user, and I think that the best you can achieve using oAuth2 is what Auth0 did.
Essentially this Saas manage your users with an oAuth2 server + OpenID connect, so you are always managing your users like its a third-party application and everything works fine.
Indeed, you can see on this page that for mobile applications they suggest to use a browser based login form, because the native one can be impersonalized by everyone that decompile your application, but if you wrap it into an authorization code flow it works fine.
I'm relatively a newbie to extension development for chrome, i find that there is a lot of source material out there which mention the use of OAuth over localStorage. I need to verify credentials for an API that doesn't offer OAuth. I don't want to do it through localStorage either due to the obvious security risks. Is there any other best practices that could be followed ?
As of now I am directing the client to the main website through which Basic Auth occurs. If I were to follow this way the client would login through the website everytime and I don't know how to check the ifLoggedIn() status other than through accessing the domain through a dummy request and checking if a 401 is returned. Is there some way out for this as well ?
Even if you use oauth, in the google samples it still saves the tokens in localStorage. Chrome storage is not encrypted but the only way to get to it is by having access to the machine (physical or by malware) in which case you can't do much. Even if it were encrypted, malware could reverse eng. it since the keys are in the client.
The only encrypted area currently is chrome.sync but the user has to enable it plus it seems more dangerous to me. Anyone that hacks into your chrome password could login to chrome from another machine and receive the encrypted sync data. That's worse because it doesnt require malware or physical access to that particular device.
I want to create an API at www.MyDomain.com that is accessible from public websites www.Customer1.com and www.Customer2.com. These public websites display each customers inventory and do not have any login features. They will use AJAX calls to read data from my API.
How can I secure the API so that it can be accessed via AJAX from different domains but no one can access the API to be able to scrape all of my customers data and all of their inventory?
I have tried thinking of different solutions on my own but they would all either require people to login to the public websites (which isn't an option) or it would require some secret "key" to be displayed publicly in the browser source code which could then be easily stolen.
Any ideas would be greatly appreciated.
Thanks!
P.S. Are their any obstacles that I am going to run into using Javascript & CORS that I need to look into now?
Anything that is accessible without authentication from a browser is by definition insecure, so you can't stop that. Your best bet is to have to have a relationship with the owner of customer1.com and customer2.com - the server apps for those two websites would make an HTTP call to you and authenticate with your service. Going this way also avoids the CORS issues you're talking about.
If you've already designed the client functionality, you can still probably do it without much change to the javascript - have it point to customer1.com for its AJAX call instead of your API, and customer1.com would accept this request and just act as a proxy to your API. Aside from the authentication, the rest of the request and response could just be pass-throughs to your API.
You can use Microsoft.AspNet.WebApi.Cors.
It's just need add ONE line at webapi config to use CORS in ASP.NET WEB API:
config.EnableCors("*","*","*");
View this for detail.
The simplest way to provide a minimum security here is to provide some kind of token system. Each app has its own token, or combination of tokens which it must pass to the server to be verified. How you generate this tokens is up to you and other than being linked to app's access, doesn't have to mean anything.
Provide a way for each API implementer to open an account with you. This way you will know who is accessing what and in some cases you can block/stop service.
For instance, a token can just be an MD5 hash:
7f138a09169b250e9dcb378140907378
In the database, this hash is linked to their account. On each request, they send this token with what they want. It is verified first to be valid, then the request is fore filled. If the token is invalid, then you can decide how to deal with it. Either don't return anything or return an "access denied" (or anything you want).
One thing to avoid is having a single token for everyone, though this can be a starting point. The reason for this is if some unauthorized app gets a hold of this token and exploits it, you have to change the token for everyone, not just the app that somehow leaked the token. You also can't control if someone has access to something or not.
Since you listed ASP.NET, I can also point you to WCF, which is fairly complex but has all the tools that you need to setup a comprehensive web service to service both you and your clients.
I hope this gives you a starting point!
EDIT:
There are security concerns here in the case that someone leaks their token key somehow. Make sure that you setup a way in which the app/your service do not expose the the token in anyway. Also have a flexible way of blocking a token, both by your clients in you, if it so happens that a token is exploited.