We have recently discovered a security loophole when accessing our webmail servers that gives access to the Name and Address Book on that server using the IE browser webmail.xxxxx.com/names.nsf). By using that address on the web, one can see our name and Address book. One way to “plug” it was to deny any access to the group Anonymous. This creates problems for us, for reasons that I will not get into. Is there an alternative besides taking away access to Anonymous? Could the page be hidden some how? Are there any components already in Domino server to address this? Is it bad practice to give Anonymous access? Your response is appreciated.
Subject: RE: Security loophole in the NAB
This is not a “loophole.” It’s you leaving yourselves open. Do you think the Domino server should override your decision about what the access to this database should be?
If this is a public website, it’s not safe to allow any anonymous access to the names.nsf. Just don’t do it.
If you need to allow access to a few specific elements, you can designate them as “public access,” and set the database ACL to allow read or write by public access users who otherwise have “no access” to the database. You can also do things with agents in other databases that run with the authority of the signer, but can be run by any user.
Names.nsf is a very “sensitive” database, so please be very careful what access you set for it. You do not want people getting in there.
Subject: RE: Security loophole in the NAB
I have to agree that anonymous having access to names.nsf is a “bad thing” but I have to think that a part of the solution (for keeping authenticated users out) would be a redirect document to push requests to names.nsf back to something less important like your main page.
Subject: RE: Security loophole in the NAB
Website administration is not really my issue, but I don’t believe redirects are an effective security measure. They redirect from a specific URL, and there are many, many different URLs a hacker could figure out to try to get in to the address book. It would be hard to block all of them, and harder still to prove that the database is secure. If you use the database ACL, you know unauthorized people can’t get in (without having stolen a password). If you do anything else, it’s very hard to be certain.
Subject: RE: Security loophole in the NAB
This security breach is exposed only on our webmail servers. We could stop replicating the ACL. For example, we set Anonymous to No Access on that webmail server and prevent that setting from replicating to our application (and internal mail)servers. Do you think this is a good, secure approach? Thans for your feedback. I have to have a solid argument with someone over this because giving Anonymous No Access is going to break a few of my internal Domino web applications. I am hoping there is another approach on the Administratiive side.
Subject: RE: Security loophole in the NAB
Like I said, I’m not really an administration expert. Setting the ACL not to replicate sounds reasonably secure to me, but you need to be careful how you do it. Notes likes to replicate, so you need to set things up so that the ACL from your local replica doesn’t replicate to the web server by accident.
Remember, too, that as I said, users can access data in database they don’t have access to by means of agents that run with the agent signer’s authority. This lets you use the agent code to limit the kind of access they can have.
I frankly don’t see that having unauthenticated access to the names.nsf is all that terrific an idea even for an internal app, but it doesn’t cause me shudders of dread the way having it exposed outside the firewall would. However, there may be factors I don’t know about there. Consult an administration/security expert.