3

In my web application, users are assigned to groups and groups are granted permissions on objects. The application exposes some objects to unauthenticated public users (i.e. people casually visiting the website).

I have thought about having an object attribute of "visible to public" that grants unauthenticated users that access.

I have also thought about creating a group named Public, and giving that group permissions like any other group - then automatically treating the unauthenticated user as a "dummy" user who is a member of that group.

The latter seems simpler from the perspective of the interface (both API and UI) for managing permissions. But the concept of the Public group being special feels like a slight design smell. Am I missing any security principles that would make this undesirable?

jl6
  • 625
  • 4
  • 9
  • Are you using an existing web app framework? Most of them already have ways of supporting anonymous users. – Neil Smithline Mar 08 '16 at 21:05
  • I am using Django as the authentication mechanism, but none of the Django model features. I note that Django takes the second of my two listed approaches. – jl6 Mar 08 '16 at 21:10
  • Sharing some code between public and private users pose some risks. Any coding bug may grant public users, private privileges. I don't know your code, so take it only as a "check" point. To be safe, you have to design your code in a way that there is no chance for a public user to gain privileges even if the code fails to do what it is suppose to do (encapsulation), something like a virtual machine in which no matter if the client OS has security flaws it should not leak to the host OS. – lepe Mar 09 '16 at 01:13

1 Answers1

1

It sounds like your following good security principles by establishing secure defaults, trying to keep it simple, and ensuring guests have least privilege.

I think both of the two options are viable and should be left up to you, the programmer. Whatever you think is simpler and easier to manager long term is probably the right choice.

If a visible to public object is going to be easy to manage the access rights on whatever content you wish, use it, as long as it also provides easy functionality to change what's visible in the future.

I personally would lean towards creating a permissions group for guests, and assigning them to that group by default because that's what everyone is used to managing. It would also permit someone to manage the permissions of all the guests in the same way that one would manage the permissions for everyone else. Remember, keep security simple.

Attack surface area and simplicity go hand in hand. Certain software engineering fads prefer overly complex approaches to what would otherwise be relatively straightforward and simple code. Developers should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler.

Read more on security principles here - owasp.org

Pete Peterson
  • 41
  • 4
  • Can't find any reference to "security principles that would make this undesirable" in your answer. That was the question, wasn't it? – techraf Mar 09 '16 at 01:28
  • The question was what are security implications of having a dummy user account representing unauthenticated users. I believe I described the security principles generally enough to allow this fella to make his own decision. If you'd like to supply a better answer, please do. – Pete Peterson Mar 10 '16 at 00:47
  • No, I don't want to supply a better answer. I'd like to read a better answer. – techraf Mar 10 '16 at 00:49