Context
We have a website with end-to-end-encrypted data. The user enters their master password on the login page and it is saved only in a variable locally on the client. Data is encrypted and decrypted on the fly.
Now we want to create an extension that allows an user to view their data. Because this data is e2e-encrypted, we need the user's master password. For convenience, the user should not be asked again for it in the popup, instead the website should send it to the extension securely.
Problem
How do we securely send data from a website to the extension?
Solutions
Website saves the password in plaintext
The website saves the password in a <script> tag.
The extensions injects a content script.
This content script sends the password to the popup.
Problem
XSS attacks will lead to a leakage of the password.
Website send passwords on events
The extension injects a content script.
This content script sends an event asking for the password.
The website listens to those events and sends back the password.
Problem
Again, an XSS attack will lead to the leakage of the password.
Question
Is there any way to securely send data from the website to the extension? Can you verify the authenticity of the extension (seems like you can not)?
What's currently the most secure way to exchange sensitive data, such as passwords, between a website we control and an extension we control?
Related
I'm developing a webextension which connects to an online database (firebase).
The login process is handled in the popup, currently this gives me a username and password (raw text).
In the contentscript, I need to communicate with the database. To do this, the database handle needs to be authenticated.
Currently, I'm planning to send the credentials from my popup to the background script and to use that to distribute login credentials to the contentscripts.
This would be done via browser.runtime.sendMessage and tabs.sendMessage. Is that a bad idea ? The docs don't talk about their security.
I have a blog that requires users to login to view the content. But my page checks for a cookie, if cookie exists then it shows the content (to avoid users having to login repeatedly).
I want to send out an email to my subscribers with links to new posts. Is it possible for me to create a cookie when they open the email or click the link and then recognize that cookie on my website to prevent the requirement of them needing to login?
No.
Most email clients capable of rendering HTML will not, by default, load any remote content or run scripts. And using a JavaScript cookie for authentication is inherently insecure anyway.
Give the a link to click on in the email with a one-time-password and set a http-only, secure cookie from the page the URL links to.
I have embedded an iFrame into my web-page. The iFrame keeps prompting the user to enter their security details via a dialog box which appears on the screen.
I do not have access to the server on which the iFrame is stored, but I do have security details and a username/password that works on this server. I would like to hardcode it so that the dialog box no longer appears - the details are automatically entered via Ruby/JS.
Is it possible to do this? If so, how?
If I'm correct in assuming this is an HTTP-Auth window (that is, the remote HTTPD itself - Apache or Nginx or IIS or whatever - is requesting authentication, not the site software) you can provide a login and password as part of the iframe src URL, e.g.
<iframe src="http://login#password:website.com"></iframe>
I wouldn't recommend this approach if the login and password are sensitive, but your choices are really either putting the login and password in a place where the end user can find them, like this, or making another arrangement with the owners of website.com to auto-authorize users of your site.
I have to make changes to classic asp website where once a button is clicked it autologins to a third party website with a intermediate page that warns that you are logging in to a third party website.
The thirdparty is providing us with a username and password and gave us an examle javascript to encode the password to send to them. Now where do I store the userid and password. I cannot execute the javascript on the serverside. It has to go to the client. If the asp page which has the encryption javascript goes to the client side then the source can be viewed and the username and password is given out.
Is there a way that I can have hidden asp page whose only job is to encrypt the password and create a new url and auto redirect it to that new url.
So when the user clicks ok on the intermediate warning page I redirect it to this hidden asp page which does the encryption and a creates a url for get method and redirects to that page.
I am a novice as far as java script and classic asp is concerned. Any ideas/ advice will be appreciated.
Thanks,
--Abbi
As SLaks said, it really doesn't matter what you do, if the client browser MUST send the user/pass to the final website, then you cannot prevent that client browser from being able to see that user/pass. It MUST see it, in order to provide it to the other website.
What you might want to consider is creating a page that is loaded server side and presented to the client browser from your website. Think iframe (but not an iframe, that's still client side); where your server requests the page from the destination server, and then presents that page back to the browser. This could get very complex depending on the kinds of interactions that happen on that page; you would basically need to proxy all GET's and POST's between your server and the destination site. But this would eliminate the need for giving the browser the username and password.
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?