Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 days ago.
Improve this question
so i got an email that said my database was about to expire if i won't change the security rules, i missed it so my database expired, now when i change the security rules it doesnt do anything, how can i solve this?
the email:
You chose to start developing in Test Mode, which leaves your Realtime Database instance completely open to the Internet. Because this choice makes your app vulnerable to attackers, your database security rules were configured to stop allowing requests after the first 30 days.
In 0 day(s), all client requests to your Realtime Database instance will be denied. Before that time, please update your security rules to allow your app to function while appropriately protecting your data. Analysis is run daily; if you've modified your rules in the last 24 hours those changes may not be accounted for.
when i noticed the email i tried to change to rules to the most basic ones - just changed read"true",wright "true" - didn't do anything
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 months ago.
Improve this question
So, I am trying to safely store an authentication token using Angular, processed with additional encryption on top (in front end) and put it in browser local storage (so that not anyone can de-code it).
Many people recommend this method, but I came across several opinions that say even in such case one can access your source code through your browser and get your secret key to decrypt the Auth Token (for example experienced hacker).
Many people claim that Access + Refresh tokens are the best in terms of security.
So, my question is - what are standard practices for serving/ storing authentication token? Is token encryption in local storage good implementation or should we use refresh tokens (although, they are harder to implement)?
I think you should use both a refresh and access token for maximum security...the access token should have an expiration date and should be blacklisted after rotation(when you use the refresh token to get an access token)...if you need even more security,after rotation,the user should get a new refresh and access token
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 1 year ago.
Improve this question
I made a simple online web-app to practice what I've learnt this half of the year at univ and turned out interesting (to me & my friends). The app is very simple, you register (used firebase authentication), then log-in and you create simple notes for stuff you have need to remember. It works almost at 100% but I have to fix some UI stuff and this issue...
When I sign in to the app, and then other person enters the link from their device, they somehow are inside my account and that shouldn't happen. How can I approach this to be fixed? Add a timer for inactivity to call the signOut() method? Or how is a way to make my app recognise each device for having multiple sessions runing at the same time?
The code is vanilla js, firebase authentication and firebase firestore.
Your question at face value isn't technically possible unless you are also storing the user auth state within your app for other users to facilitate.
Instead, I will answer if this is based on the same device:
Firebase's refresh token does not expire, allowing a user to return to the site or web app without having to re-authorize. To bypass this, you can configure Authentication based on the session or local instance, where if the user closes the window, it will log them out.
firebase.auth().setPersistence(firebase.auth.Auth.Persistence.LOCAL)
// or
firebase.auth().setPersistence(firebase.auth.Auth.Persistence.SESSION)
Reference: https://firebase.google.com/docs/auth/web/auth-state-persistence
If this is not the case which you are trying to solve, further debugging is required. Possibly a link to your project would help?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
If I have a webapp (website) and I am posting data from the user's browser to Firebase, how does it prevent some other website or hackers from posting to my database?
If there is an API key or token, it is viewable from the traffic from the user's dev console. Can it be identified by which website the user is on, but even so, the hackers can spoof a website in the HTTP traffic data.
Without backend code, if I post 10 game coins for a user, how can I stop the user from posting 100 game coins to the same Firebase database if there is no server code to control that?
(there is a post about other hackers hacking it will be difficult, but what about a hacker hacking his own account?)
If I have a webapp (website) and I am posting data from the user's
browser to Firebase, how does it prevent some other website or hackers
from posting to my database?
It doesn't really "do" anything by default. You have to do something.
If there is an API key or token, it is viewable from the traffic from
the user's dev console. If it is identified by which website the user
is on, the hackers and spoof a website in the HTTP traffic data.
All traffic sent between client apps and Firestore is encrypted, usually over HTTPS or other encrypted socket, so it's not visible to anyone who can just see the stream of encrypted bytes between the client and server.
Without backend code, if I post 10 game coins for a user, how can I
stop the user from posting 100 game coins to the same Firebase
database if there is no server code to control that?
Your security rules will prevent that, but security rules might not be robust enough to stop unwanted changes. So you might need a backend for that. You shold always assume client code has been compromised, since it runs on hardware you don't control.
(there is a post about other hackers hacking it will be difficult, but
what about a hacker hacking his own account?)
When you use security rules (or whatever mechanism) to gate access to individual authenticated users, you should assume that the user isn't bound by the logic in the app. Someone can take their own auth token and use it in calls to Firebase services to do whatever they're allowed to do with that account. This is really not any different than any other permission system.
This question already has answers here:
Is it acceptable to leave a database (Cloud Firestore) unsecured when no site login is required?
(2 answers)
Closed 3 years ago.
I am working with log-in log-out management, and it turns out that it's quite important to use the FirebaseAuth for all operations. But since only I have the service account key and only I can alter how the app is working, I'm wondering how someone can read or write in my database other than what I've programmatically given to them within the app. Can someone help explaining this to me? I would be really glad.
If your security rules allow access to unauthenticated users, then anyone with an internet connection will be able to read and write the entire contents of your database. It will be especially easy with the Firestore REST API.
A judgement of how "bad" that is for your project is entirely up to you to determine.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I write a phrase and please you say your point of view about it:
For my web site,If My Server Is Secure(Server Admin warranty that) and I prevent XSS and Sql Injenction attack,Is my web site secure?
(please leave your answer with reference)
Thanks
Edit 1 ::
every of above items + Cross-site request forgery
Firstly, don't expect to obtain a "secure" end state as if it's an absolute position - you can't. Software security is about reducing risk and you won't ever reach a position of no risk.
There are many, many other risks you've missed: broken authentication and session management, insecure direct object references, security misconfiguration, insecure cryptographic storage, failure to restrict URL access, insufficient transport layer protection and unvalidated redirects and forwards to name a few. These are all out of the OWASP Top 10 and I suggest you start with these.
Make sure you understand:
The risk
How it's exploited
How you can protect against it
If you'd like to see all this in the context of ASP.NET have a read through the OWASP Top 10 for .NET developers series.
And thee are risks beyond these top 10 too, they're just the most common ones in web apps.
No. There are other attack methods. For example, http://en.wikipedia.org/wiki/Cross-site_request_forgery