I need to generate UUID to eventually store in a database. Can I generate theses UUID from Javascript on the client browser (There are some examples here)?
Is there any security risk of doing it this way? I understand that anyone can modify the UUID before it's passed to the server for storing. So i'll need to check if they are trully unique before storing them in the database, but other than that, is there any other things to checkout?
(Sorry for my english, feel free to correct any grammar errors)
edit: To answer questions about why I would want to do this, it's because I can create a new object and it's identifier in Javascript and add it to my view and then make an AJAX call to the server to add it to the database. This way, I don't need to load it back from the database to know what is it's primary identifier.
Not really. As long as it's a simple identifier and nothing more, and you are indeed checking it for validity and uniqueness, it's no different than user accounts having an id in the url, for example.
Look at your URL bar. I bet 1296234 is the primary key of this question, but I can't really do anything with that information. Same deal with your script.
What benefit do you see in generating these client-side? In all honesty, the best option is to generate it server-side, out of the users reach. It may not give save you from any serious security issues, but it will cut down on redundant validation.
Is there some reason you can't have the database generate (increment) an ID?
If, like you say, you'll have to check the uniqueness of the value before submitting it anyway, why not just have whatever backend language you are using generate it. That would make it much more opaque.
Yes. The risk is not specific to UUID, any client-side generated ID has some risks, depending on what you do with the ID. The problem is that it's very hard to authenticate the Javascript. If you accept ID generated by client, you accept any IDs from the hackers.
The risks may include,
Session stealing. If you use the ID to identify the session, someone may use an existing ID as generated ID and the server may treat it as an existing session if proper care is not taking.
Duplicate keys. True UUID is random but someone can generate duplicate keys which will mess up your database.
You might find ways to defend against each of these attacks but that's passive protection. It might defeat the original purpose of generating IDs on the client, which is simple.
Related
Introduction
For a website I'm working on, I will be storing confidential information that I need encrypted.
The way Laravel currently handles things, they encrypt each record with the same APP_KEY that's stored in the .env by default. I think I should be able to take that same APP_KEY and decrypt all the information in my production database as long as I have access to the production .env.
If so, I don't think that's a proper away to handle security for my case. Let's say I hire an admin for my production site and they turn out to be malicious. All they need to do to get access to all the users' sensitive details is take that APP_KEY and run the decryption.
If that's the case, I would rather have it work like this:
The user creates a record that has a "secret" field
A random string is generated to encrypt the data passed to the "secret" field and is then given to the user
If the user wants to access the data in the "secret" field, they have to use the key given to them; I nor anyone else should be able to decrypt that field without knowing the key given to the user
For my specific case, a client program will handle accessing the site's API and storing the encryption key and other details safely, so the user doesn't have to think about this.
My questions are the following:
Is the current encryption scheme Laravel uses safe from malicious admins?
If not, how would I go about best implementing the latter scheme?
Are there vulnerabilities with the latter schema as well, and if so, how can I improve it?
What I've Done
I've looked at the docs on this issue. I've also looked into the Model::encryptUsing feature, which allows for custom encryption.
I think I can implement the above if, when running the action that creates the record, I use Model::encryptUsing, but I haven't tested it yet.
If it ends up working, I will post the answer here.
I run a landscaping company and have multiple crews. I want to provide each one with a custom URL (like mysite.com/xxxx-xxxx-xxxx) that shows their daily schedule. Going to the page will list the name, address and phone number of 5-10 customers for the day.
Is it safe/wise to use a UUID in a URL for semi-private data?
Depends on how safe you want it to be.
Are the UUIDs used for anything else? If not, they are fine for creating random URLs.
But, browser history would allow anyone using the same machine to find the URLs. Also, unless using https, a network sniffer could easily see the requested URLs and go to the same page.
Another concern is spider bots. Make sure nothing links to those pages, use a robots.txt to prevent indexing the site, but you still might find that some of the pages show up on search engines. It might be better to have the UUID set in a cookie and check that for determining which employee it is, lest your semi-private pages start showing up on google.
Whether or not that schema would work for you, depends on your threat model (as well as some implementation details). Without a concrete threat model, it is not possible to give a definitive answer to your question.
I can, however, give you some ideas about potential issues with the solution, so you can determine if they are relevant for your application. This is not a complete list.
On the implementation side of things:
Not all UUID generators are created equal. Ideally, you want to use a generator based on a cryptographically secure RNG, providing an UUID where every byte is chosen at random.
Using the UUID for a database lookup or similar operation is not necessarily a constant-time operation (and thus there might be side-channel attacks unless you implement the lookup by yourself)
Make sure your URI does not leak via referrer
Some tools attempt to detect 'secret' URLs to protect them from history synchronization or other automatic features. Your schema will most likely not be detected as 'secret'. It might be better to artificially lengthen your URI and to move your UUID into a query parameter.
You can further reduce attack surface with the usual methods (rate limiting, server hardening, etc.)
On the conceptual side of things:
A single identifier for both identification and authentication is not necessarily a bad thing. However, in most cases there is a need for an identification-only identifier – you must not use the 'secret' UUID in those scenarios
If a 'crew' consists of multiple people: you cannot revoke access for a single crew member
Some software (antivirus, browser, etc.) treats information in URLs as public information, and might upload them without user interaction
As I am using CanCan gem, I check if the required record is created by the current user, if not, I redirect to another action ..
So, why its important to encrypt the id sent via routes?
Is it that dangerous issue to keep it simple like this: ?
http://www.mydomain.com/posts/5
I've never heard anyone claim that obfuscating ids improves security. Sounds like security through obscurity.
Can you cite a source who claims that ids should be obfuscated?
So lets say i have a member base website and when the user signs in i put put a cookie (or a session) with a key value pair remembering who the user is. But its just come to my attention which information i should use to remember the user so that its secure. I cant use username=username or user_id = user_id (because my user_id will be 1), because people then can just simply guess what the cookie values are and logged in as that user. So what key/value pair should i use to be able to identify users and still connect their information to the database securely? Thanks.
Ben, there are a few different types of attacks you need to be concerned with. For example simply encrypting the identifier with a private key doesn't prevent someone who can intercept the encrypted value from simply replaying it to your server (and appear to be the user). Some common security risks are detailed here (and in associated links at bottom of this page):
https://www.owasp.org/index.php/Session_hijacking_attack
Session management can be quite complex and depending on the level of security you require, it is not something you want to tackle yourself, because likely your development environment / framework already has a solution that has been vetted moreso than a homebrew solution. Here is a link detailing some things to consider, unfortunately this topic has more to it than a simple Stack Overflow post:
https://www.owasp.org/index.php/Session_Management
If you dont prefer encryption for whatever reason, then a simpler solution could be to use a GUID to identify the user. This way, a hacker would have to launch a denial of service kind-of attack on your application to be able to run through even a very small fraction of the GUIDs.
If you want to do this properly, then you should have a look at http://jaspan.com/improved_persistent_login_cookie_best_practice also.
I'm definitely not an expert in security, but I have recently implemented user management tool and I have done the following.
Don't use encryption, its slow and most of the time for simple implementation its just a waste of time.
Here is what you do need to store on the server - in order to authenticate each request.
UserId (obvious)
CookieHash (made out of userId, some secret private key and crypto randomly generated number)
LastLogin
SessionRenewed (useful for when to cancel someone's session eg. renew cookieHash every 10 min, otherwise log out user)
LastIP
What I store in cookie is following
UserId
CookieHash
How to use this basic security
Simply when user logs in you check username/password etc. (just the usual) If everything is fine then log in user and generate new cookiehash and fill those values given above.
Every request check UserId against its hash. If someone gave UserId = 4 but hash didnt match then automatically drop a session and forward user to login screen. Possible log is good to see how often people try to play around with your hard work.
I hope this helps.
You can just encrypt the user id with a private encryption key that you keep on the server. There are a few things to watch out for with this approach:
Every call to the server will require you to decrypt the cookie to get the id of the user. This will add overhead to each request.
If the key is ever compromised, you will be forced to abandon the current name for the cookie you use and use another encryption key when assigning to the new cookie name; this will cause the user to have to re-login, of course.
While I don't think that these are major hurdles, they might be to you, and you would have to evaluate the impact on your site for yourself.
Is there any problem with security if I store userid,profileId,username and other such kind information in cookie.
Yes there will be an enormous security problem doing this. If you don't encrypt the cookie anyone could replace the username you've stored with say for example Administrator (usually id=1) and send a request to the web server.
This information need very often,and instead of do Sql query every time I can one time get this information from Sql,store it in cookie(when user login) and then get it from cookie.I think it will be more efficient.
Yes, you can do that BUT ONLY IF IT IS NOT CRITICAL THAT THIS DATA BE CORRECT.
The user can edit his own cookie.
If he wants to change his display name to something else, or get a different background picture, probably no problem.
If he can impersonate other users, big problem.
So, to be on the safe side, better not go down this road.
If you need performance improvements, consider server-side caching solutions instead.