Your SlideShare is downloading. ×

Domino security

1,293
views

Published on

Lock down security exposures in your Domino web applications

Lock down security exposures in your Domino web applications

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,293
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Lock down security exposures in your Domino web applications Rob Kirkland Certified Lotus Instructor Consultant Author of “Domino System Administration”
  • 2. Agenda
    • Authentication - 5 options
    • ACL settings
    • Securing views
    • Securing forms and documents
    • Vulnerability in Domino URLs
    • Securing Agents
    • Important server document fields
  • 3. Authentication: Anonymous access
    • No user authentication required
    • Useful for commercial Web sites with information intended for public consumption
    • Dangerous for restricted Web sites
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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.
  • 8. 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.
  • 9. 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!
  • 10. 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
  • 11. 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.
  • 12. 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
  • 13. 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
  • 14. 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!)
  • 15. 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
  • 16. 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
  • 17. 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!
  • 18. 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
  • 19. 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.
  • 20. 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
  • 21. 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 .
  • 22. 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.
  • 23. 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
  • 24. 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.
  • 25. 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”.
  • 26. 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*
  • 27. 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
  • 28. 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
  • 29. 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.
  • 30. 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
  • 31. Thank you
    • Any questions?