What is the best practice both security and performance focused to avoid letting users see incrementally IDed data in database or other dataset.
Main concern is to avoid urls such as
www.myweb.com/user/123
This of course applies to posts, users, files or messages.
Implement permissions so that only authorised people can see/change/delete data.
If you still want to hide the incremental ID from users or API consumers, you could add a hash column to your database and index it, then expose that instead of the incremental ID.
Hiding Incremental IDs
Depending on your programming language, the unique ID you assign your users may not need to be displayed in the URL. For example, with PHP, you can use the $_SESSION[] array to store values on your server for each user. Those variables will never be seen by the user, but the server will be able to identify each user appropriately (via PHP cookies) and serve them the correct page dynamically.
For example, when a user signs in to your site, after authenticating, your script might do something like:
$sql = 'SELECT id FROM user_table WHERE name = :username';
// Prepare & execute SQL query, putting result in $sqlResult
$_SESSION['user_id'] = $sqlResult;
Now, whenever the user wants to visit their own page, your server will know which information to fill your home page template with -- and the URL will appear the same to every user.
If a user wants to visit another user's page, you could do something similar: upon choosing a specific user page to visit, your script could set a $_SESSION['visit_user'] variable. Thus, you would be able to fill a visit page template with the appropriate information, and your user will be none the wiser.
This same tactic can be applied to posts, files, etc. that are assigned incremental IDs.
But Is This Necessary?
As you yourself mentioned in your previous post, there are plenty of examples of sites that use incremental IDs -- and with no qualms about displaying them. Because while this does give a malicious user the ability to view other users' IDs, etc., this doesn't necessarily pose a threat to your site's security. If you follow basic security principles (require strong passwords, watch your MySQL users' and files' permissions, sanitize user input, etc.), it doesn't matter if malicious users can guess at auto_incremented IDs. Those IDs aren't valuable information unless your site can be exploited in another manner.
Related
I reckon every page that has a form will need a unique ID generated. How would one go about storing, retrieving, and verifying this ID in an online environment?
Would you create a new database and run an INSERT query on every page that has a form on it? Followed up by a SELECT query on the forms target page to verify?
Would you then need to manually run a script that checks for old IDs to delete them? Or is there a more efficient method to all of this?
Edit: This is to prevent a script that executes a major action with a relatively simply query from being abused. Say limited_event.php can be POSTed to with a createNewReservationAutomatically variable that does just that, creating a temporary reservation with whatever contact details were submitted for manual verification later.
If the script is requested repeatedly with those variables, it will eventually fill up all available spots (and generally flood your database).
From my understanding referring URIs can be spoofed and are thus unreliable. What's a web developer to do? You have my upvote if you don't say recaptcha.
You seem to be asking 3 questions: how to prevent duplicate submissions, how to "reserve" spots, and how to protect a form from malicious input.
To prevent duplicate form submission, use http://en.wikipedia.org/wiki/Post/Redirect/Get
For reservations, see https://stackoverflow.com/questions/tagged/reservation?sort=votes
To protect forms from malicious input you need to do server-side validation, use XSS, CSRF and brute force countermeasures
I need to set up user permissions within the same table, based on the value of a field. I know that this is not directly possible in Access but a post on Allenbrown.com points to a way of doing this see here. I'm not proficient in coding so I'm hoping that I can get some directions from you. Here are the details:
I have two tables in the database, a parent one populated via a form and a children one populated via a subform. The parent contains companies and the child contain subsidiaries of those companies. In the child table, I have a field called "Domicile" and I want to discriminate user access based on that. Because the database will be used by a variety of people worldwide, my plan is to create user groups based on location and allow users to edit (or add) information based on a match between their location (as specified in the group) and the domicile of the subsidiary. For example, a person in Europe will only be allowed to edit data for subsidiaries that are in Europe, even though companies from other domiciles may be stored in the same table.
I'm looking for some guidance here as well as suggestions as to how you think may be done most effectively. I'm not partial to this method, that's just something I came up with to put some logic behind what I'm doing.
Thank you so much!
The important thing to note in Allen's description is (emphasis mine):
Assuming all updates are performed through forms, the Current event of the form then locks the fields based on this property.
There would be no practical, bulletproof way to prevent users from viewing and altering any data in the table(s) if they open the back-end database file directly.
Since you are asking for advice on how "[row- or column-level restrictions] may be done most effectively" the first issue you need to address is how "effective" those restrictions really need to be:
If you can accept that these will be "soft restrictions" (really a matter of convenience to the user so they don't accidentally alter certain records or fields while using the forms), then Allen's approach might be sufficient. (If so, then follow Allen's instructions as best you can and ask new question if you need help with a specific aspect of that implementation.)
On the other hand, if you need "hard restrictions" (serious protection against mischievous or malevolent user activity) then you'll have to employ a different database back-end -- something like Microsoft SQL Server -- with a richer set of security tools for you to use.
I am developing the application in which i have a super user concept. Super user is the user who has all the access for the application. So what my initial thinking is in user table the user with id 1 will be my super user. but how safe is this in terms of security concern ? is there any other logic which i can use to define super user ?
I have done more emphasis in coding side. I also implemented the roles and other access permissions, But what i need to to do is something like ghost user. Whenever he logged in he could be able to access everything like he is a father of application. for his access i shouldn't need to check any role conditions or access condition. is it possible ?
Thanks.
Why not work with roles? Make a column in your user table where you have 'SuperUser', 'Admin', 'ReadOnly',... Or perhaps just 0, 1, 2... and match it with a constant/enumerable in your code. Now you can easily change your super user, make multiple super users, give someone temporary super user rights, define other roles...
From the database point of view it is valid to define two or more users and grant more or less permissions to them, work with roles etc.. But as you said - it's about the application. So in parallel to the database security you need to consider application security in terms of:
which user may get which functions, menu items, web pages etc.
how can this be configured and parameterized, etc.
I personally put a bit more emphasis on the application side and less on the DB side. So thinking of e.g. PHP + MySQL, I have 2 DB users (operator, admin), but a database table within my application for each (application) user, assigning to them the operator or admin login for the DB and defining which parts of the application they get.
As a complement to the other answers:
Don't forget you could create users and grant/revoke permissions at DB level. I would not push for a 1-1 mapping between your application users and the DB users, but you could use that to implement "roles" and enforce permissions at DB level as an extra level of protection. This might be especially interesting if you have some users with "read-only" and/or "anonymous" access. This would prevent "escalation of privilege" due to a bug in you application code.
Super user is the user who has all the access for the application. So
what my initial thinking is in user table the user with id 1 will be
my super user.
In the Unix tradition, super-user is generally ID 0. This might improve code (maybe) and more important make it more understandable by programmers familiar with kernel/security coding.
But what i need to to do is something like ghost user [...] for his
access i shouldn't need to check any role conditions or access
condition. is it possible ?
I don't think this is a good idea to somehow "deactivate" all your security checks for one particular user. In order to improve maintainability and not clutter the code with permission-checking, as of myself, I would encapsulate all the code that need to check permissions in wrapper functions or objects, then I would use that wrapper in the rest of the application. Based on that, and if you implement "roles" at application level as someone else suggested, handling the "ghost user" shouldn't be too much of an issue.
I'm developing a site that has to store a user's contact list. So it will contain people's phone numbers, addresses and also messages sent to this contact. I obviously want to keep this information secure but it seems quite easy an efficient just giving each user a json file with an array of details.
I'm not too sure if this is a horrendously dangerous and insecure idea and if I should be using a table in a database, or something else. Using a table to store messages sent between users doesn't seem too intuitive though. So I was just wanted to know what the most sensible way I would store
i) User specific contact lists with sensitive information
ii) Messages sent between two contacts
I'm sorry if this is a widely known and not even talked about topic. I just couldn't really find a clear answer anywhere.
You should definitely use a database for this. If you store these values on files, then you will have to load all of the information per user every single time you need to access something as small as a single phone number.
how to connect database table with the local username id and password of the system?. When user logs into the machine. opens up the software, he gets only the assets alloted to him. asset information is contained in the database table..anyone has any idea on how to implement this.I'm using mySQLdb with pyqt4.(creating an asset manager, user gets only the assets alloted to him )
As has been stated in the comments, the tables should not be any different between users. Also, there is no way to get the users password without them entering it again. And once you do have them enter it, you would have to use some method to authenticate them, such as checking it against an LDAP server.
Otherwise, if you simply want to base the delivery of database information of the current logged user and assume that them being logged in is enough of an authentication, you could simple get the login name with os.getlogin()
Most likely what you would just be doing is selecting on your table, data that has that username as matching criteria of some column. You wouldn't be using any sort of database-level authentication to filter the data. The authentication comes from some other earlier layer.
In pseudo-code: select * from assets where user is <result of os.login()>
With regards to the reason you are getting downvotes... People would like to see more context about your problem to understand the solution you are after. What is the structure of your database tables? Are you associating asset records with users? Is there a specific need for security or simply automatically identifying a user that is running the software? People on SO that take a little more time to outline their problem, the context, and what they have tried, tend to get better responses and upvotes.