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.
Related
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?
Background I have some experience implementing Oauth1a and Oauth2 as a client to connect to 'trusted' 3rd party services (twitter, facebook etc), but first time implementing the resource/authorization servers.
I have a basic but not strong understanding of different grant types, and how Oauth attempts to solve the authorization of a user/resource, while protecting user information (login information etc).
Scenario: we are creating a client-side application (reactJS) which must submit some basic information to a WordPress site. We control (are the authors of and will host) both react and WordPress on the same server.
We are using WP Rest API:
http://v2.wp-api.org/
And Oauth server plugin for wordpress
https://en-ca.wordpress.org/plugins/oauth2-provider/
Question
The further we get into implementation, the more I ask, what security to I gain at all by adding Oauth in this scenario?
For development and testing, the permissions callback on the POST to our REST endpoint is TRUE (open to any request), and now we are trying to secure it so only our application can submit information to WordPress.
The author of the Oauth server for WordpPress describes for this:
The access token used to preform a CRUD WP REST API action MUST has been acquired via the password grant type (user credentials).
Which requires embedding the following in the client:
client ID
client secret
wordpress user ID
wordpress user password
since:
The access token MUST be assigned to a user id with the correct
WordPress capabilities to preform the CRUD action.
Just to get back an access token.
Note: users do not log in via our react application. The application itself acts as one user in this case.
I must be missing something, exposing the WordPress user name and password seems less secure than skipping Oauth completely, leaving the POST endpoint open, and implementing some kind of submission abuse check, via submission rate, IP or other.
With Oauth2: Someone in control of the client can watch the XHR request and retrieve all information necessary to submit malicious data.
Without Oauth2: someone could use one of many discovery techniques to find our public endpoint and try to submit malicious data.
Things which I may be missing: should I be encrypting/hashing the password, secret, ID etc before embedding in the client?
Should I be separating out our authorization server from the resource server?
Have I missed the point, and Oauth is not a good candidate for this scenario?
Any insight or clarification greatly appreciated.
I am using sdk that facebook provides(in java-script), to add login option in my site with facebook. I succeed to do this on client side, but I want to identify this user on server side without php-sdk.
So I need from client side send a request to server, that will prove that (for example) user with ID 1234 in Facebook, indeed logged in to my site. I don't want to use php-sdk, because it's the only time I will use it, so it's seems to me a waste to load all the sdk just for that.
I have developed a multi-page Javascript web application. My clients have asked me to provide a login page. They do not need anything fancy and requested a single username and password that they can share with those who need access to certain featured within the application. They want anybody to be able to see the application, but only authenticated users can use certain tools within the application.
I currently use an ASP.net proxy page (.ashx file) for handling requests to and from a 3rd party server storing the data consumed in my application.
I've never created a login system and have no idea where to begin. I don't think I need a database for login information because there will only be one username and password.
How could I go about securely storing the username and password to authenticate with the user-submitted login information and enabling parts of the application based on whether a user is authenticated or not?
The good news are that you don't need to build the login system, Microsoft did it for you. This is called the Membership System. All you need to do is expose this API to your end users.
And it's a bad idea to have a single credential for everybody. It is better to assign unique credentials to each user.
I want users to be able to register on my mobile (web based) app and login using their Facebook account. Is this possible using the JavaScript API?
The user can login using Facebook, and the userID and auth code of that user can be sent to my server to create the account, but I see a security flaw because then anyone could then log in as anyone by sending a userID and their own auth code. So can user accounts not be done with the JavaScript API and only with a server side API?
All Facebook requests are also signed with a secret key that belongs to the app you've registered to handle Facebook sign-ups on your website, so you can use that to verify it comes from Facebook and not someone else.
This is also outlined in the registration documentation
Strictly speaking, it is not possible for the Facebook SDKs to explicitly create a new user. However, when you implement a 'Login with Facebook' button (see here for JS and here for PHP), Facebook's OAuth dialog appears, which will prompt the user to log in (if they are not already) or to sign up with Facebook, thereby creating a new account, albeit not under your control.