risk of javascript injection attacks with firebase - javascript

I am trying to understand/anticipate the security considerations associated with using firebase as a backend.
The documents cover authenticating users and validating input, but I can not find any discussion of risk associated with malicious users trying to inject javascript into the database.
Is it possible that javascript could be included in an input field that is saved to the database that then could be executed later when that code is retrieved and displayed elsewhere?
Or is firebase escaping or sanitizing data somehow?

Any database (or other storage system) can be used to store malicious code as it is inherent to their function: they just store data.
The Firebase SDKs and supported libraries (such as AngularFire, EmberFire and ReactFire) ensure that they never embed the information from the database into HTML pages unescaped. While it is always possible that we (I work for Firebase) missed something there, I don't recall that ever being reported.

You have to properly escape all user input when putting it in a webpage regardless of the backend.

Firebase offer validation of data, there you can check for injecting javascript snippets into your database.
https://firebase.google.com/docs/database/security/securing-data#validating_data
And you should always sanitize your output, this is not related to Firebase but a good rule of thumb.

Related

How to set firebase database security rules?

The situation is that I have a website, where at the end the user can order with filling a form, but no registration or log in is required, to be more specific, there's no possibility to register or log in. When the form is filled, with the submit button I want to validate the input with a function, and if they are valid, send it to Firebase. There are a few problems:
there's no possibility to authenticate the user, I need to set the Firebase security rules as "open", so everybody can write and read data to the database (but it may be a good solution to set as everybody can write, but just I can read data.
I read a bit about the config variable, and there's no good possibiity to hide that, so if somebody write a simple js program, and set the config as it's in my file, it can do whatever it want with the database
I was thought about that is it really the best solution to read the users input as order, I was thought about that maybe js can somehow send me the data to my e-mail address, but after careful research, I can't found a possibility to that. Anyways, it's sure that there's a solution to the Firebase problem. What I want is to set the only possibility to write to the database through the website, and read the data just through the Firebase Console.
There's not much you can do if you aren't authenticating your users, I guess the best option would be to set up write rules to protect the integrity of the data being saved (so even if someone with access wrote to it they'd have to follow a structure): https://firebase.google.com/docs/database/security/securing-data and set read rules to nobody.
Another method may be to have an API on a backend server which makes sure all requests are coming from your website only before saving it to firebase. This way you won't have to expose your firebase config.
In addition to #AlchemistShahed's answer, I'd recommend checking out Firebase's anonymous authentication. This gives each user an ID, without requiring them to specify any information. It's pretty much a persistent session ID, with as little code as:
firebase.auth().signInAnonymously()
By embedding this (anonymous) user's UID into the data they write to the database, you can easily detect when a single user is flooding your queue with data.
You could write a cloud function that would be called on form post, that function would check and sanitize data before inserting data into Firebase. Since data insertion would be done from the server side, no config would be present client side. Then set security on Firebase so only you can read.
You can also check those links, you might find something else in there.
Here's a link to some common use case for Firebase rules:
https://gist.github.com/codediodeio/6dbce1305b9556c2136492522e2100f6
Here's a link to Firebase security doc: https://firebase.google.com/docs/database/security/

Security flaws of keeping sensitive information inside javascript code

Everybody knows that you shouldn't keep sensitiveInfo variable at your js code. The better way is to put it inside local storage. Could you pls explain vulnerabilities of the first approach with help of my example?
Example:
You use bundler, which bundle all your js files together. sensitiveInfo isn't global, but stored inside YourStorage.js. To access file which keeps it you do:
import YourStorage from 'somepath/YourStorage';
YourStorage.sensitiveInfo = newValue; // QUESTION: can you steal this value? Is it accessible from console?
Questions:
Is sensitiveInfo variable accessible from console?
Could you please describe mechanism how someone can steal sensitiveInfo?
If someone can steal it from my code, why he couldn't from local storage?
UPDATE: (whom I'm trying to protect from?) I'm writing mobile web app, where users can spend real money. I want to protect them from all kinds of attack where they can loose their money (i.e. locally installed viruses)
Anything put in javaScript that is downloadable can be easily seen on the users device. The most common method of securing sensitive information that must be passed back and forth to a client is to:
First, use SSL to encrypt the information over the 'wire'.
Second, if the data is of a very sensitive nature - such as a token used to process credit card information (do not store the card number in this token!) - that data should be encrypted itself, using a seed/key that is securely stored on the application server.
Often you would write the application to require both the identify of the user AND the device be verified. After this verification, you would then decrypt the token - using a key stored only on, and only available from, the server-side of your application.
Using this practice you can reasonably assume the user and device are whom they say there are. Of course, such applications need proper authentication themselves - with said credentials not being stored on the device - to prevent stolen devices from easily being used to access the application account/data. Do not simply rely on a devices screen lock for security.

Clientside PostgreSQL Javascript access without serverside part

I know that direct access to a database via Javasript is not recommended, since the user would get the database login and thus the ability to manipulate the database.
But in my case, the user cannot see the client-side code, since it's a phonegap app.
Is there a way to do it? And it not, what is a good way to do with a serverside part?
its really not recommened to access database from client-side its not only for security reasons, but what if you changed the database access or upgrade to different database, so you will have to change it in your app which you may not be able to access again after users installed if its mobile app and then you stuck to your database for ever,
so whatever you want to do you can add an action in server-side and depend on your params it will formulate your Query,
for example sending parameter for user=true this will search for users tables, sending parameter for account=true will search in users-accounts tables and so on.

security issues with client side code javascript and unbounce

I am trying to integrate an unbounce account with a salesforce account, I can get the leads generated across to salesforce fine, however the form used is js, and I have the option to add custom js to the page.
What I want to do is setup hidden fields in the form that posts and then use js as custom code to extract the referrer from the url + the source from the query string and to split the 'name' field into 'firstname' 'lastname'.
What i am wondering is as this code is client side no server side option available, is it making our salesforce account vulnerable in any way?
what is the worst that can happen
disclaimer not a coder just a basic understanding
thanks
If you are only using JavaScript to read and parse the referrer, you're just modifying information that's already in the URL. This is publicly available information, so no security vulnerability.
On the other hand, if you are accessing your SalesForce account via some sort of API or other function calls in page code, we need more details before answering your question adequately.
The js is simply gathering data and then being submitted with the form, from what i understand the sending of the form details including the hidden fields are then done server side with ruby

Can I make Google Drive Spreadsheets act like a MySQL database?

Can I use a Google Drive spreadsheet as if it were (similar to) a MySQL database?
I'm thinking of using it as a player database for an HTML/JavaScript web game. The player's username, password, and score among other things would be saved in the database. It would be really interesting if it could actually work, however it of course has to be secure and private so that no player (or anyone on the internet for that matter) can access it except the owner of the spreadsheet which would be me for example.
I know that Google Apps Script allows a user to access their own spreadsheet and read/write to it, but is there a way that I could allow other users to "save their score" to MY spreadsheet WITHOUT giving them permission to view/edit the spreadsheet directly?
Also, i'm assuming PHP/Python/some other server-side language would have to be used in order to hide my account info which I also assume would be needed to open and close the connection with my spreadsheet.
Anyways, I'm just wondering if this is feasible.. literally turning a Google Drive spreadsheet into a database that players can update their score to but not have direct access to it.
This may be a stupid idea, so your opinions are welcome!
Thanks in advance!
This is the right way to do it.
Another post explaining the same idea.
Essentially, we publish the spreadsheet and query it using a "select"-like syntax. For instance:
this query which reads something like:
https://spreadsheets.google.com/tq?tqx=out:html&tq=select+B,C,I&key=phNtm3LmDZEObQ2itmSqHIA
This is for querying data (reading). For inserting, you can use google forms (create a form, see its html and submit using a http post request). I have not explored update yet.
And yes, this has to be done server side.
Answers saying you need an extra server or oauth are incorrect.
Just publish an appscript (anonymous public) service using your permissions. For all operations always pass the username and password thus you validate users on every call. Call the service from client js using ajax.
Store it in scriptdb [update: scriptDb is deprecated now]. If you use spreadsheet for storage it will get slow with many rows.
In any case it will be slow if you use appscript.
Without a server-side service that implements another authentication layer for client libraries and use Google auth to talk to Drive, this is not possible.

Categories

Resources