3

(Is this the best forum for this type of question?)

I'm writing a web application which allows approved users to login, and perform various tasks, depending on the security role(s) they have been assigned.

I'm guessing that to prevent users from performing tasks that their roles don't permit, this should probably entail 2 main phases:

  1. Present web pages which contain only the options (menus, pages, buttons, fields, etc) that the user should be able to access, on the web pages. (This is basically working, already.)
  2. In case a user tries some hacking (e.g. posting fields/values which their webpage doesn't allow them to post), double check all actions before processing them. (This sounds pretty complex in some areas, to me.)

Does this strategy sound appropriate/normal/necessary? Any tips or links to pages which discuss this, before I possibly spend a lot of time going down the wrong track?

I'm using Perl/MySQL on Linux, though the principles might be generic.

Thanks.

3

You're on the right track, but missing one key point: All validation/authentication must be done (or double-checked) by the server, because you cannot trust the client. Maybe you already had this in mind, but it's worth stating explicitly. And yes, you definitely need to do both 1 and 2.

In principle the logic for 1 and 2 should be exactly the same. A type 1 check determines whether a UI element is shown, and a type 2 check determines whether a command gets processed, but the actual checks should be identical. So I'm very curious why you think 2 would be significantly more complex; maybe this points to an architecture problem somewhere.

  • @Terry You're very welcome =) – Ixrec Mar 12 '15 at 20:29
  • Thanks very much for all that, @Ixrec. Re my architecture, for example: One form has many fields, and different roles have access to different fields, so some fields are disabled or even not present for some roles, (which was easy enough to code). When it comes to phase 2 though, my SQL UPDATE statement is going to have to remove certain columns from the list of columns, and values from the list of values, right? (Maybe that's no harder than phase 1 - haven't tried it yet.) – Terry Mar 12 '15 at 20:40
  • If you need to make all the changes in a single SQL statement, yes. But it may be easier to write code that updates each field with a separate statement (and group all the statements in a transaction). I'd certainly prefer to keep authentication logic far away from query string building logic if at all possible. – Ixrec Mar 12 '15 at 20:43
  • Back to general advice: If you try to implement this and find it is hard, I would be inclined to think that your permissioning system is too complex or your database design is suboptimal or something like that. In theory 1 and 2 should be basically the same, and in practice they usually are. – Ixrec Mar 12 '15 at 20:47
  • Thanks again @Ixrec. After looking at my code (which I haven't seen for ages) it looks as if this will be easier than I thought if I modify the query string. Why would you want to keep authentication logic far away from query string building logic if at all possible? – Terry Mar 15 '15 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.