As you may have noticed from previous questions, I'm building a web site that will support authentication via Webauthn using Yubikeys (maybe other tokens later). As part of that process I'd like to be able to (1) detect whether or not an authentication token is already present, so I can prompt the user to insert one if not, and (2) determine what type of token is inserted, so I can include an image of the token with helpful animation/instructions about how to use it when it comes time for them to verify their presence by (with Yubikeys) pressing a touchpad or other contact.
Offhand I don't see anything in the navigator.credential API that seems to suggest that this is possible, and maybe it would violate all sorts of Javascript security limitations if client code is allowed to probe devices, but I just wondered if anyone has any hints about how such a thing could be done?
Thanks!
Indeed, this cannot be done to prevent tracking users against their will based on their available authenticators.
The most that can be determined is if the browser is running on a platform with a built-in authenticator via [isUserVerifyingPlatformAuthenticatorAvailable][2]
See also some recent related discussion in the spec repository https://github.com/w3c/webauthn/issues/1563
Related
I don't have any idea how to implement this. After a bit of search I found out that medium keeps track of the browser and not the user, what is mean is you can access three free articles from each new browser on the same machine (if I am wrong do point it out). I am using React and Firebase for my website.
Edit: I was thinking along the lines of getting some kind of id which is unique to a browser. As cookies and local storage can always be bypassed.
I don't know if it's a clean way to do it but you can associate an IP to an unique counter. Or with a cookie but he can bypass that by cleaning the cookies
The answer would tightly depend on your application setup and especially on the service backing your front store.
If you are using a self-backed backend, for example a nodejs - express based server, within your route middleware you can access the remote address from the req.connection.remoteAddress request property along with the user-agent req.header('User-Agent') and forward these to your datastore being Firebase in this case.
If you are deploying your application to Google Cloud Function, you can then access the remote peer address using the fastly-client-ip request header and still forward this to your storage system.
Use javascript and implement a system that uses a cookie or local-storage to verify how many articles are read on your website.
On most of these websites however you are still able to bypass this limit by clearing the cache or using a incognito window.
To also limit these scenarios you can use a cookie in combination with an IP address, which has its own drawbacks, especially in corporate environments, and mobile connections where IP addresses are heavily shared or changed. Depending on your situation this may matter or not.
I developed a client side JavaScript functions and added them to the Dynamics 365 customer service solution as web resource using the recommended steps.
The functions were tested and operate as required when I am logged into the instance with Roles as a System Customizer and System Admin. But if login is as a user without these two Roles like a CSR Manager the JavaScript functions were not responding. On further investigation with client side developer tools in IE11, Chrome and Firefox I have verified that the JavaScript is in fact not downloading to the client browser for these users.
If I grant the System Administrator Role to the user the functions work fine and I can use client side debugger in the browser. As soon as I take away the Role and reload the browser the debug points I set do not pause and the JavaScript web resources are not downloaded.
I am not sure what's going on as no community forum or Microsoft docs article mentions any other requirements that secure the web resources or allow non admin users to view versus admin users.
CRM web resource (JS) cannot be rendered/controlled only for some security roles. It’s open for all.
But when you have different forms for different security roles, then there is a possibility of registered js libraries & functions missing in that particular form.
You cannot find anything like this any documentation/forum as this could be some admin/developer error.
If you enable multiple forms for Sys.Admin or CSR role, then form switcher will appear in record & you can test both behavior.
I see a couple of answers here talking about security roles and forms. If you have the jScript only on ONE form, it will not work for the others. So, you need to link that JS (whether a web resource or code you enter into the text editor) to every form you want the JSCRIPT to run on (in the Form Properties). It sounds like you have it running, and it works, for you and other users in the SysAdmin role. Have you tried this across all of your forms?
The second thing to check is what exactly your JScript code is doing. Is it only focused on one entity (the entity of the form you are injecting the JS to)? Is it updating, deleting, or appending something to the record?
As stated above, JScript and Web resources cannot be locked down by security (as far as I know), but if the user doesn't have the proper permissions to WRITE to an entity, you may see this behavior.
Update: Sorry, I lied. Web Resource is controllable through Security Role. It is in the Customization Tab, all the way at the bottom of the list (but above the Misc. Privs). You have the ability to set CREATE, READ, WRITE, DELETE permissions on this entity.
You might want to check the security roles that the non-SysAdmins have has at least READ on the Web Resource entity.
Thanks for all your responses. The issue was form "Enable Security Roles" related after all.
I am not sure whether by DEFAULT on custom form the security is only enabled for System Administrator and System Customizer Roles only OR one of my team members restricted access to these two roles.
But on reviewing these the and enabling the form for other Roles the JS script started to download for non admin users.
lesson learned do not assume, always check and double check especially in a team environment.
I'm setting up parse framework in javascript. I notice that I need to call
Parse.initialize("app", "secret")
Since this is in the page source, couldn't anyone take this and make calls against my account?
Is there a more secure way to store this info?
As per Parse Security Guide your JavaScript key is NOT secret:
When an app first connects to Parse, it identifies itself with an Application ID and a Client key (or REST Key, or .NET Key, or JavaScript Key, depending on which platform you're using). These are not secret and by themselves they do not secure an app. These keys are shipped as a part of your app, and anyone can decompile your app or proxy network traffic from their device to find your client key. This exploit is even easier with JavaScript — one can simply "view source" in the browser and immediately find your client key.
So yes, anyone who found your key can make calls.
But you can (and should) restrict what such anyone can do.
Using Class-Level Permissions you restrict what can be done with individual classes.
Using Object-Level Permissions you restrict what can be done with selected objects.
See also Roles and Roles Hierarchy for simultaneously setting permissions for a group of several users.
For instance, you can restrict access to only specific users. Only if one of those users is logged in, the access is granted. Any other "hacker" can try to use your keys but the request will be rejected by Parse.
I need a primer web/javascript security.
According to How to use an HTML/JavaScript client for Windows Azure Mobile Services, in javascript on the client side, after including a link to MobileServices.Web-1.0.0.min.js you're supposed to create a client like this:
var MobileServiceClient = WindowsAzure.MobileServiceClient;
var client = new MobileServiceClient('AppUrl', 'AppKey');
which means including my AppKey in the javascript on the page. Should I be worried about the AppKey being public?
Also, it seems easy enough for someone to put an XHR breakpoint in to read the X-ZUMO-APPLICATION and X-ZUMO-AUTH headers while making a REST call when logged in. The usefulness of this is somewhat reduced with a cross-origin resource sharing whitelist, but what's to stop someone with this information from adding javascript to the page and executing arbitrary operations on my backend database? Restricting table permissions to authenticated users wouldn't help in this scenario.
Do I need to be concerned? What do banking apps do about this sort of thing?
In the same link which you shared, application key is defined as a not safe mechanism to authenticate users - A unique value that is generated by Mobile Services, distributed with your app, and presented in client-generated requests. While useful for limiting access to your mobile service from random clients, this key is not secure and should not be used to authenticate users of your app.
More over when you enable some authentication on all the endpoints either using ACS or through Open Authentication, if you main ASP.Net/PHP etc page got authorized, then browser is going to handle federation of identity through cookies for next on-going calls till your session ends.
In most of the applications having HTTPS would protect from Man in middle attacks. Also strong encryption logic on cookies along with very specific expiry times would increase the bar of security. Also IP address based checks would definitely help in improving security.
ramiramilu's answer covers most of the question. There's one more thing which I'll add:
Also, it seems easy enough for someone to put an XHR breakpoint in to read the X-ZUMO-APPLICATION and X-ZUMO-AUTH headers while making a REST call when logged in
Yes, someone can add a breakpoint and find out the value of the X-ZUMO-AUTH header which they're sending. But the value of that header is specific for the logged in user (in this case it would be the "attacker" [him/her]self) - it wouldn't be able to get information from other people out of that header. And there are even easier ways to get the value of that header (just browse to https://<mobileservicename>.azure-mobile.net/login/<authProvider> and after entering your credentials you'll see the header encoded in the URI).
Our company makes the web based application which is priced per workstation.
That means that user/pass credentials should only be used from one particular machine.
Currently what is happening that several users are sharing credentials and we do not have any way to prevent this if they are not doing it concurrently.
The nature on the application is such that user needs to use it once in a while so the inability to work concurrently does not bother the users much and the company loses it's possible revenues.
The application currently is purely AJAX without flash/activeX/Java applets.
The ideal solution would be to read the computer name or IP address of the client with javascript using "Shell.Network" scripting interface.
But this is impossible because of the strict security settings in Internet Explorer. I have to mention that cross browser functionality does not matter and the only browser supported is IE.
Searching google I came across this solution here http://www.reglos.de/myaddress/MyAddress.html but it requires JAVA applet so will not be very convenient.
Are there any other solutions for this?
Your licensing model is not consistent with the delivery model. Change one of them.
Set a cookie on the machine with an id. Retrieve the cookie each time the user logs in. If you see several different cookies alternating for a single user you know you've got something odd going on.
(Of course a single switch may just mean they've moved to a new PC as one off. )
Alternatively, price per usage, 'query' or some other item.
This kind of abuse can probably be detected moderately effectively using the Cookie technique that RichH suggested. At least blatant abuse can be detected quite easily (say 10 licenced users, 100 real users).
But of course, don't lock the user out, just monitor the situation and get your Sales people to call up suggesting that they buy more licences.
We do exactly the same (in terms of licensing and delivery), and I'm sure that you have good business reasons for not changing your model.
Track through sessions per user. Do not allow multiple sessions to a single user. To achieve this you will have to save the session ID into the database and check everytime a user logs in.
To help users who at times have a browser crash and relogin with new session, allow them to sign out their previous session... so you can kill the old session and instead register the new one.
Hope this is useful.
There's no easy answer as your clients (the software) are effectively anonymous and the users are self-identifying.
For IE "locking you out" (I'm hardly an IE expert), but can't the IE settings be set for particular domains? You could simply make it a requirement that the users configure their browsers to give your app superior access.
I don't see any reason why you can't have certain requirements for the users browser (i.e. only IE 6/7/8, these security settings, etc.).