To provide security layer on top of loading Web Application.
Scenario:
Implement a .exe file (client side) which will ask for a password -
1) If the password is correct - it will grant the access to Web Application to load on browser whenever the URL gets hit.
2) If the password is NOT correct - it will not allow the Web Application to load ever.
NOTE:
1) Running .exe and feeding password is just the one time process (except formatting the system).
2) Later the group/user only hit URL of Web Application any number of time (Loads only when he has filled the password section correctly - one time process)
3) The purpose of .exe is to provide the access of Web Appication only to those group/user who have this .exe file and have that unique password.
Please explain in detailed view.
THANKS in advance.
Not a very regular use case but let me try if I can be of any help!
First thing is you'll need to connect your exe's output with the web application(I assume it will be browser on the client side).
Once the user launches the exe, get the input and validate them by sending a request to your server. If the credentials are correct you'll need to save a file preferably with some auth token or may be username:password pair in an encrypted form on the disk. This is required so that user can use this while accessing the application using a browser.
Now when user launches the application in a browser, ask her to chose the exe's generated file and read the details there(one time activity). Can be done using How to open a local disk file with Javascript?
Once you get the details, store it in the browser's local storage so that you don't have to ask the user to do this exercise again and again.
From next access onwards, if you have those details in the local storage just pass it the server so that it can authenticate the requests. Local storage doesn't have a expiration time so this should work. However it can be cleared using other means. Besides you'll need to take of the security. I would say it's a huge risk to keep the credentials on your local disk permanently.
Related
I'm converting part of my Python Flask application to be used as a kiosk via a progressive web app (simplest way I've been able to find to deploy it as an "app" to my managed tablets). What I'm struggling to wrap my head around is how to handle registration/assigning a device to a group so that when the app is downloaded, it caches the correct group information. Currently, my web app expects group info to be passed as a request parameter and then renders the correct information. Normally I can give that link to a client and they're good to go.
Here's expected setup process:
New tablet is provisioned, put into group and group policy loads Example PWA onto desktop.
Client receives new tablet, loads Example PWA
Example PWA looks for a registered device ID (UUID) and can't find it so redirects user to registration endpoint.
Client logs in with credentials, configures settings.
UUID is generated on the device (or server), saved on server side and saved in localStorage client side.
Client logs out
PWA now sees it's registered, requests resource from server (start_url) and renders correct landing page for the client based on device UUID.
End users can now use the kiosk
Is there a way to do step 7 without rewriting vast swaths of code to be driven by JS. What's the easiest way to get a uuid to the server so the right content is loaded? Ideally, I'd like to pass the device ID in the header but I think that means I have to intercept every request to inject that but I can't find a good tutorial on doing so. Suggestions?
I ended up pointing the start_url to a dedicated landing page and storing a uuid for each new device in IndexedDB while modifying the Fetch event listener to add that uuid (device_id) to the headers. New devices won't have a device ID, so server side for the landing page sees an empty device ID and redirects to a registration page. If device ID exists, it looks that value up in the database and redirects to the real start page for that client.
I have made a html login page for my webpage. I am using Miniweb (simplest html server). All passwords and login data is saved to file.js but using the browser dev tools it is possible to see all passwords. I would like to know how I can encrypt or hide files from this tool.
JavaScript files used in your webpage can never be hidden from the user. The user can at any time open the developer tools and head for sources as you stated. JavaScript isn't a secure way to store passwords and sensitive data. Using a database is much safer. It would be saved on the server such that users cannot access it.
There's a few ways to do this. But typically, you wouldn't want the information on the actual html file. You could use webpack and something called uglify that takes all the javascript and scrambles it so it's unreadable.
But this is still shrieking security vulnerability. You would want to have the login information saved in a back end. The password itself should never be saved in it's pure form, anywhere where the public can access it.
Look into simple node servers. You can setup a quick database to store your information. Additionally, before you save the data, you encrypt it. and save the encryption. There's a module called bcrypt that helps with that.
When you login, you encrypt your login password again and compare it to the saved encryption. That way if you're database is ever compromised, all they'll see is a hash, not your actual password.
Additionally, traffic to and from your server and front end can still be intercepted, there's methods to encrypt the body of the requests and responses as well. So only the server can decrypt traffic coming out of the front end. Look into PKI and Certificates to learn more about that stuff. It's a pretty deep and heavy subject but clever as hell.
Im working on an web application using the MEAN Framework, within that app I want to give the users the ability to upload files.
Now heres the main thing:
All users uploaded files should be uploaded to a SINGLE dropbox account (my account)
They will only upload files of with the max size of 20MB (I've already built the functionality to check the file size before upload)
What I've done:
Ive gone to a Dropbox developers and I have setup my app. And now I have access to my appKey, appSecret and also a Access Token
My questions:
Is it possible for me to connect a single dropbox account (my
account) to my app and give users in my app access to upload/download files from the dropbox but by using my apps interface?
As I already have the access token would I or every user in my app still need to go through
the OAUTH process?
Can I just send my Access Token with each request to Dropbox api every
time a user uploads a file through a specific form on my app?
If you can provide an example or a link that would be very helpful.
UPDATE:
I generated my token using the following button on the dropbox developers console:
Assumption: it is supposed the user of your apps are "legit" and that they won't do anything of your dropbox files that should concern you.
Yes, it is. You can configure your app to be the consumer of your dropbox; of course, your app will also have to make sure the users of the app are legit (check them with user/password login and so on) --note: consequences can be that any unauthorised person able to use your app can delete permanently all your files (or do anything as bad as possible according to the privileges)
The access token is part of OAuth, so I am not sure what you mean when you say "process". I will interprete your question as "how do I refresh my token?". Simply, before every call to dropbox API by your app, you check the expiration of your access token: if it is still valid you just perform the call, otherwise you request a new token. You do not need a Refresh token in this case: the OAuth mechanism (or 'grant flow' as per OAuth jargon, or 'process' to use your word) you are using is called "client credentials grant flow"
See above 2)
Some links for you: Here some overview of the grant flows.
Here a schema of that grant flow (note: MS uses another component called "ActiveDirectory" to grant permission; in your case, both "Azure AD" and "Resource API" are just "the dropbox server")
Actually I want to store a file on a client PC.
I know that asp.net does not allow to access client harddisk but by using any trick or any idea?
For security reasons I want to save a file on client's computer containing user information. I does not want to save a cookie in a user's browser.
Scenario.
I want to store something on client's PC permanently by using which I identify the user. Everytime when user login to mysite I will check that file on client's PC. If file is present then user will login sucessfully if file is deleted by the user or by any reason file is deleted or user comes from another PC then again save a file on client's PC. I does not want to save something on browser bcz user may delete the cookies and other histroy.
Don't mark my question as negative, I don't have any harmful intention.
No, this isn't possible.
Any technology that lets you store files will throw up a stack of security warnings.
Short answer...no
There are a number of ways to accomplish saving a file to the users machine. They will all require some form of permission from the user. (i.e. a java applet will need trust)
The advantage here is that if you self-sign your applets and use the same sig for all of them then you can obtain trust through another applet and it is then extended to your file writing applet.(if they check the box too) However the user will always have to click at least once that they trust you.
Note that even if trust is extended like this they may well see another trust box asking them to trust microsoft to do file operations(in the case of win systems)...they will always know whats going on
EDIT: Just had a thought, depending on what you want to save you may be able to squeeze it into a cookie or a batch of cookies. A lot of users have these always on and will never know....sneaky
No, it's highly unsafe to have access to the client PC without any permission.
"I want to store a file on a client PC without telling to the client." - that is where the real problem lies. You should not do this. And the browser is designed to stop you doing this, quite rightly.
You need to go back and look at what you are wanting to do, and do it differently.
This is break a fundamental security principle of Web Applications
According to the Facebook API documentation, most of the work is handled through javascript.
That means that all the processing is done, and then the front end checks if the user is connected to Facebook/authorized. right?
My question is:
Suppose a user goes to my site for the first time ever.
He clicks on "facebook connect". The javascript verifies him as authentic, and it "redirects" to another page on my server. From then on, how do I know that the user is actually authenticated to my website, since everything is done on frontend?
I think this is correct, but aren't there some security issues..:
-After user clicks Login, Facebook redirects to a page on my site. AND they also create a cookie with a specific "Facebook ID" that is retrieved only from this user. My backened will "read" the cookie and grab that ID...and then associate it to my userID.
If that is correct...then it doesn't make sense. What if people steal other people's "facebook ID" and then forge the cookie? And then my backend sees the cookie and thinks it's the real user...?
Am I confused? If I am confused, please help me re-organize and tell me how it's like.
Facebook Connect uses a clever (or insane, depending on your point of view) hack to achieve cross-site communication between your site and Facebook's authentication system from within the browser.
The way it works is as follows:
Your site includes a very simple static HTML file, known as the cross-domain communications channel. This file is called xd_receiver.htm in the FB docs, but it can be named anything you like.
Your site's login page includes a reference to the Javascript library hosted on Facebook's server.
When a user logs in via the "Connect" button, it calls a function in Facebook's JS API which pops up a login dialog. This login box has an invisible iframe in which the cross-domain communications file is loaded.
The user fills out the form and submits it, posting the form to Facebook.
Facebook checks the login. If it's successful, it communicates this to your site. Here's where that cross-domain stuff comes in:
Because of cross-domain security policies, Facebook's login window can not inspect the DOM tree for documents hosted on your server. But the login window can update the src element of any iframe within it, and this is used to communicate with the cross-domain communications file hosted on your page.
When the cross-domain communications file receives a communication indicating that the login was successful, it uses Javascript to set some cookies containing the user's ID and session. Since this file lives on your server, those cookies have your domain and your backend can receive them.
Any further communication in Facebook's direction can be accomplished by inserting another nested iframe in the other iframe -- this second-level iframe lives on Facebook's server instead of yours.
The cookies are secure (in theory) because the data is signed with the secret key that Facebook generated for you when you signed up for the developer program. The JS library uses your public key (the "API key") to validate the cookies.
Theoretically, Facebook's Javascript library handles this all automatically once you've set everything up. In practice, I've found it doesn't always work exactly smoothly.
For a more detailed explanation of the mechanics of cross-domain communication using iframes, see this article from MSDN.
Please someone correct me if I'm wrong - as I am also trying to figure all this stuff out myself. My understanding with the security of the cookies is that there is also a cookie which is a special signature cookie. This cookie is created by combining the data of the other cookies, adding your application secret that only you and FB know, and the result MD5-Hashed. You can then test this hash server-side, which could not easily be duplicated by a hacker, to make sure the data can be trusted as coming from FB.
A more charming explaination can be found here - scroll about halfway down the page.
Same issues here, and I think Scott is closer to the solution.
Also Im using "http://developers.facebook.com/docs/?u=facebook.jslib-alpha.FB.init" there open source js framework. So things are a little different.
For me, via the opensource js framework, facebook provides and sets a session on my site with a signature. So what I am thinking is to recreate that signature on my side. - if they both match then the user is who he says he is.
So basically if a user wanted to save something to my database, grab the session signature set up by facebook and recreate that signature with php and validate it against the one facebook gave me?
if($_SESSION['facebookSignature'] == reGeneratedSignature){
// save to database
}else{
// go away I don't trust you
}
But how do you regenerate that signature? preferably without making more calls to Facebook?