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 7 years ago.
Improve this question
I have a website and am making a login system using cookies so the user can stay logged in, which I believe you can't do with sessions. I wanted to know if a malicious user could create or modify the existing cookies on the domain. I know they can delete them, that's fine, but can they create or modify them?
Anyone can control their browser, however they like. They can create, edit and delete cookies.
For that reason, your cookies should be long and random (or at least random-looking to the point of being indistinguishable from random).
They should be meaningful to your server, which should be able to relate them to a user, but not meaningful to anyone outside your server. They should be long enough and complex enough that guessing one would be statistically impossible.
Your server should be careful not to make any assumptions about the cookie values it receives. For instance, I could submit a cookie with 2,000 characters in it - that mustn't cause it to crash.
You can create, delete and edit your browser cookies, everyone who have access to your computer can read them, and copy so you can steal session ID for example.
You cannot modify session manually, because this is "server cookie", only server software can do it. If you want store password or other secret information, you should not store it inside cookie. Its insecure, you can store token or session id but not inforamtion like password.
Related
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 5 months ago.
Improve this question
I'm fairly new to coding, and when I try to find a way to lock my website behind a username and password field, every tutorial just hides them as a plain variable in some random file. I'm wanting to make the website only accessible once a username and password have been entered, but I want the usernames and passwords to be made and managed by myself, so only people I know can access it. If this is a really obvious thing I apologise, but if it's something that I can specifically look up please let me know so I can do more independent research.
There's no good way to do this on the frontend alone.
every tutorial just hides them as a plain variable in some random file.
Sounds like some pretty shoddy tutorials. Anyone could look at the source code of the site and get in.
The right thing to do would be to:
Hash the passwords (one-way encryption so that the original password text cannot be recovered, even if someone gains access to the hash)
Save the passwords in a database or (if there aren't many) in environment variables on your server
Set up routing on the server so that if the user isn't authenticated, none of the protected content gets sent to them in the first place - redirect them to the login page. (Don't serve the HTML of a protected page and then try to do validation from that page; with that approach, users would still be able to open up the developer tools and bypass your restrictions, by inserting their own code and removing your own).
Anything on the client-side can be tampered with and bypassed; gate requests behind the server instead, which is (or, has the potential to be) much more secure.
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 3 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
If I'm using something like React/Vue/Angular or just simply preventing my page to load on submit with pure JS, should I generate the id for my element on the front end or should I wait for the server to respond with an id?
A simple example would be the good old todo list, I add a todo and it has to have an id so when I want to delete it I can send the id to the server. In the past I used to generate a UUID and send that to the server for it to use. My question is just if this is good practice or should I be doing it differently?
If you're going to store data in the server, you should never created the ID of an element in the client. You could add the same ID twice, or another user could use the same ID that you do, or use an invalid one, or -- you get the idea. You can almost surely avoid repeating IDS generating UUIDs client-side, but it is much easier, and more secure, to edit them in the server. Take into account that in the client you don't have any control in which the client sends to your backend. Despite what you do with JavaScript, a malicious user can always hack the request sent to the server and modify it the way they want, so you could end with IDs too long for you database fields, or with invalid values, or God know what else.
Generating ids client side is indeed bad practice for the reasons already explained. But the real point regarding your concern in my opinion is, even if you generate the ids client side, you still have to wait for that server response to make sure the resource is actually created. Server might be temporarily down, server-db connection might be down, disk might be faulty. You need that response in either case for a better user experience when there is an error. So I don't believe you're actually improving the overall user experience by generating ids client side.
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 2 years ago.
Improve this question
I want to verify that everyone that visit my website is least 18 years old. What would be the best approach in order to do it?
I think that the best approach is to send a cookie after the user clicks over the checkbox. Is there any better way to do this?
Example:
I would look into 3rd party authentication services like Auth0 (https://auth0.com/). I find if you allow people to use Social Networks that require their age, you are more likely to collect verified information.
You can use cookies for this :
https://www.w3schools.com/js/js_cookies.asp
You could also use localStorage instead of cookies. It stores data on the client side with no expiration date. It gets erased only through js or when the user clears his browser cache.
Yes, you can save this information in cookies and yes you can check if there is such an information available on the user's browser. (in php for eg. very simple)
The IP check is not a great idea. Just think about dinamic IP-s (same user with different IP next time) and storing sensitive data.
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 6 years ago.
Improve this question
I am using javascript and Reactjs. We have a very complicated server set up, and it would be quicker if it was possible to use the .env file to store our API keys and access them directly from the client.
I'm sure you can, but you should not. Especially when it comes to security concerns.
Everything the browser reads, writes, or otherwise interacts with is also available to all users to be used as they see fit.
it would be quicker if it was possible to use the .env file to store our API keys and access them directly from the client, [...] there is a way to load .env variable on the code, so its hidden, your just refering to the env file
This would effectively give those API keys to users for them to use as they see fit. There is no way to hide something that is sent to the browser. Nothing is stopping a user from modifying (or completely rewriting) the client-side application for themselves and displaying -- or worse, modifying -- any data present in there.
This is one of the reasons your server should treat every single request and response as a potential attack. Keeping that in mind, including API keys in the response is everything but secure, as a potential attack will pretty much effortlessly harvest your API keys.
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 7 years ago.
Improve this question
How can an offline website (zip, MHTML, SingleFile) be made secure? Are there techniques (obfuscating, encrypting) or anything within the specs of HTML or JavaScript (ECMAScript) that would allow for an offline website to be secure on its own?
By "secure" I mean that if a user has a local copy of the website, they may not still have access to the contents without a password. Imagine a level of security approximating that which is used in PDF documents.
You may use an offline js function (https://code.google.com/p/crypto-js/#Ciphers here are some algorithms that will do) to encrypt all the data, and ask for a password to decrypt it.
Note that you shouldn't store the correct password, but instead check if it is correct by decrypting with the password given by the user a known message (encrypt "hello world" with the correct password, and then check if the password given by the user works).
Yes; you can encrypt the data, then decrypt it in Javascript.
Note that any user with the encryption will always have full access to the data.