domino security

31
Lock down security exposures in your Domino web applications Rob Kirkland Certified Lotus Instructor Consultant Author of “Domino System Administration”

Upload: dominion

Post on 21-Jan-2015

1.296 views

Category:

Technology


2 download

DESCRIPTION

Lock down security exposures in your Domino web applications

TRANSCRIPT

Page 1: Domino security

Lock down security exposures in your Domino web applications

Rob KirklandCertified Lotus Instructor

Consultant

Author of “Domino System Administration”

Page 2: Domino security

Agenda

• Authentication - 5 options

• ACL settings

• Securing views

• Securing forms and documents

• Vulnerability in Domino URLs

• Securing Agents

• Important server document fields

Page 3: Domino security

Authentication: Anonymous access

• No user authentication required

• Useful for commercial Web sites with information intended for public consumption

• Dangerous for restricted Web sites

Page 4: Domino security

Basic authentication: Name and password access

• User submits name and password, which Domino compares to Person document in a Domino directory or to a record in an LDAP directory

• Easy to set up and administer. Just create Person and Group documents.

• Problem: Name and password cross network as plain text with every URL the user submits

Page 5: Domino security

Session authentication

• As with basic authentication, user submits name and password in plain text– But only submits them once.

• User submits cookie after initial authentication• With each reply, server sends user an updated

cookie– Maintains transaction state this way

• Supports single sign-on too– One login recognized by multiple Domino and

Websphere servers

Page 6: Domino security

Authentication: Server-side SSL

• Server submits certificate with public key to user• If user trusts certifier, creates, sends a session key

to server, encrypted with server’s public key• All further transmissions of information between

user and server are encrypted and validated (signed) with session key

• User can authenticate using any method

Page 7: Domino security

Server-side SSL (cont’d)

• Solves problem of user name and password crossing network in plain text. Good!

• Increases demand on resources: processor, memory, I/O.– Therefore, should use SSL only when

necessary. (Set property in each database.)

• Relatively costly to set up and maintain.

Page 8: Domino security

Authentication: Client-side SSL

• User submits certificate with public key to server

• If server trusts certifier, compares user’s public key to that stored in Person document in Domino or LDAP directory.

• If public keys match, user is authenticated.

Page 9: Domino security

Client-side SSL (cont’d)

• This is the most secure user authentication because a hacker must steal user’s certificate (and know the password) in order to pose as user

• Costly and cumbersome to set up and maintain because user must obtain an X.509 certificate from some Certificate Authority and merge it into user’s browser.

• Can’t use with session authentication. Bummer!

Page 10: Domino security

ACLs: Basics

• In general: Set ACLs to lowest possible levels– Anonymous: No Access or Reader. Never Author.– Registration DB: Set Anonymous to Depositor.

• Set -Default- or Anonymous entries in ACLs of all databases– If there is no Anonymous entry, -Default- is used on the

Web– If Anonymous is set, -Default- is ignored on the Web– Use -Default- for Notes clients, and Anonymous for

Web browsers

Page 11: Domino security

ACLs: Privileges

• Create documents and Delete documents– Don’t activate if not needed. Don’t get lazy!

• Create personal agents, Create folders/views, Create agents– Available to Notes users only, not Web users

• Read/Write public documents– Consider using to restrict access to selected

database elements.

Page 12: Domino security

ACLs: Roles

• Use ACL roles to refine access to database elements.

• You can use roles with the following DB elements:

• Framesets• Views• Sections

• Outlines• Forms• Readers/Authors fields

Page 13: Domino security

ACLs: Considerations

• Set Maximum Internet Name and Password field (in Advanced)

• Create default ACL entries in design templates– Use brackets, e.g.: [Anonymous]

• Create File Protection documents to set No Access, Read Only, Read/Write for elements in the Domino file system.– Then create Realm documents to head off user

frustration

Page 14: Domino security

Securing views

• Hide views from Web users– Use Hide from Web browsers in Design

Document Properties.– Use parentheses to hide view names

• Hide views from specific users:– Use Read Access lists

• Prevent Web users from guessing view names (by using hard-to-guess names!)

Page 15: Domino security

Securing views (cont’d)

• Use single-category views to limit what portions of a view Web users can see– Embed view in a form or page– Use a formula to define which category of

items will display to the Web user

Page 16: Domino security

Securing views (cont’d)

• Block direct (manually entered URL) to views– Use $$ViewTemplate for [viewname] and $

$ViewTemplateDefault forms that have no embedded view or $$Viewname field.

– When user requests the view, Domino will deliver the form, not the view!

• And don’t forget to redirect $DefaultNav and ?ReadViewEntries URLs

Page 17: Domino security

Securing forms and documents

• Use form and document Read Access lists• Use form Compose Access lists• Use Authors fields

– Remember, an ACL author can only edit a document if his/her name appears in an Authors field on the document

• Use Readers fields– Great security feature!

Page 18: Domino security

Securing forms and documents (cont’d)

• Use Form formulas in views– Defines what form Domino will use to display

documents in view– But remember, users can open documents

directly if they know a doc’s UNID• Then the Form field controls, not the Form formula

• Use Controlled Access sections – To control edit access to items in section

Page 19: Domino security

Securing forms and document (cont’d)

• Use Hide-whens liberally– Hides data from users but not from the server– Especially, hide password fields from

unauthorized users

• Don’t rely on field encryption– It doesn’t restrict Web users from seeing

contents of fields.

Page 20: Domino security

Lock out unauthorized Domino URLs

• Web users who know Domino URL syntax can hack your Web site.

• Use redirection to thwart this

• Problem areas include:– Certain special identifiers– Certain URL commands

Page 21: Domino security

Domino URLs (cont’d)

• http://….nsf/$DefaultView– Retrieves a database’s default view

• http://….nsf/$DefaultForm– Retrieves a database’s default form

• How to thwart:– Don’t designate a default form or view– Or create a default view or form that displays a

warning message.

Page 22: Domino security

Domino URLs (cont’d)

• http://….nsf/$DefaultNav– Retrieves a list of a database’s views

• How to thwart:– Create a Redirection document in Domino

Directory– Incoming URL path: /*.nsf/$DefaultNav– Redirect to hacker warning.

Page 23: Domino security

Domino URLs (cont’d)

• http://…/$SearchForm– Retrieves default search form– If DB is FT-indexed, user can search it

• How to thwart:– Create a $$Search form or $

$SearchTemplateDefault form with a warning or error message

Page 24: Domino security

Domino URLs (cont’d)

• $Help and $About– These retrieve the Help and About documents.– Use hide-whens to hide selected content from

Web users, if necessary.– Or don’t create these docs– Or put warning messages on them.

Page 25: Domino security

Domino URLs (cont’d)

• http://…?OpenServer– Lists all Notes databases in the server’s file

system– This may be okay for an intranet Web server,

but is usually not okay for an Internet Web server.

– To block this command, disable in Server document. Set “Allow HTTP clients to browse databases” to “No”.

Page 26: Domino security

Domino URLs (cont’d)

• http://…?ReadViewEntries– Retrieves view in XML format

• Permits user to export view contents to a database.

– How to thwart:• Create a Redirection document in Domino Directory

• Incoming URL path: /*.nsf/*?ReadView*

Page 27: Domino security

Secure agents

• Agents can be invoked from a browser– http://…/agentname?OpenAgent

• Browser-invoked agents run with the rights of the agent signer– But invoker must have Reader access to the items on

which the agent acts

• You can override this– Set agent property “Run Agent as Web user”

– You can also hide the agent from Web users

Page 28: Domino security

Secure agents (cont’d)

• If a Web user invokes an agent directly (by entering its URL manually), the HTTP_Referer CGI variable returned with the URL will be blank– Therefore, to prevent Web users invoking

agents directly, test for a blank HTTP_Referer variable.

– See example code, next slide

Page 29: Domino security

Secure agents (cont’d)

LotusScript Example to Check HTTP_Referer:If Not(Instr(1, Ucase(docContext.HTTP_Referer(0)),

Ucase(docContext.Server_Name(0))) > 0) And Not(Instr(1,

Ucase(docContext.HTTP_Referer(0)),

Ucase(docContext.HTTP_HOST(0))) > 0) Then

Print{<HTML><HEAD><TITLE>Error</TITLE></HEAD><BODY>}

Print {<H1>Error</H1>Unauthorized Exception<P><HR>}

Print {</BODY></HTML>}

Exit Sub

End If

Slide used courtesy of The View. Copyright 2000 The View. All rights reserved.

Page 30: Domino security

Some important server document fields

• Security tab– Administer the server from a browser– Agent and Java/COM restriction fields

• Ports, Internet Ports, Web tab– Authentication options fields

• Internet Protocols tabs– DNS lookup

• Domino logs host name, not just IP address

– Allow HTTP clients to browse databases– Web logging fields

• Enable one or none, not both

Page 31: Domino security

Thank you

• Any questions?