General Security problem

HCL Domino Domino Forum
1

Hello,

I’ve dicovered general security problem in most of my workflow applications, eg. order approval cycle.

Usually there are 2 types of users. First normal users with Author rights just to create documents, who can submit new orders. Second group are managers, who approve the orders and edit them.

Within the application there is no problem. Normal users can just submit new documents and they have no chance to modify document in other ways (personal agents and access to design is not allowed).

Problem is that these users can access this database with background LS classes from eg. new empty local database (Even with standard Lotus client you can create agents in empty database :))). Using agent in this local database users can create new order with status APPROVED! in the main production db :((.

I’ve tryed using signatures and controled sections, but this is just one way how to detect this breakthrough. And this validation can not be easily displayed in views.

Do you have any ideas how to protect the database from these background modifications?

(next issue is similar problem with C API :))

Thanks for help,

Martin

2

Subject: General Security problem

What you have come across is fundamental to the Notes security methodology - it’s worked as designed, but not as most people expect or want.

Think of the design this way …

.------------------------. .----------------------. .------.

| .----------. | | | | |

| | Records | Security |---------| Your design elements |------| User |

| .----------. | | | | |

.------------------------. .----------------------. .------.

                |                                                |

                |              .----------------------.          |

                |              |                      |          |

                \--------------| Users local database |----------/

                               | or Notes Peek        |      

                               | or the C APL         |      

                               | or 3rd party programs|      

                               |                      |      

                               .----------------------.

Now your user is an Author in the security (ACL) of your database. That means that they have the authority to create records in that database. That’s it. There’s no limit to the types of records, or fields, or values imposed on them.

While you can build those limits in your design (forms, views, etc) that is outside of the Notes security model, and can be bypassed…

While Notes is secure in that users cannot break the security of the database (i.e. Bypass author, reader, or ACL levels), it’s NOT secure at the application / data value level. An author of a document has COMPLETE control of that document.

Now there are ways around this, but it’s a lot of work. For example, only allow users Reader access, but with the create public documents flag. The forms they use would never be saved as documents, but would trigger signed agents with Editor access to actually update the records in the back end.

Notes is a great tool, but when it comes to security, you have to understand it’s design and limitations (which is true of all products.)

3

Subject: RE: General Security problem

Thank you for your post and especially for nice drawing :).

When I was considering possible solutions I’ve found similar design with public documents and agents. But because it’s getting too complicated, I hoped that I’m missing something and there is some systematic solution within Notes. But it’s not, so I have to build some general framework for these cases now.

Have you (or anyone else reading this post) ever build application using this security mechanism? I’m just curios :)).

Thanks,

Martin

4

Subject: RE: General Security problem

Sorry, no - I’ve never worked on a Notes application where that level of control was justified.

5

Subject: RE: General Security problem

Gentlemen, this is EXACTLY why cryptographic signatures exist within Notes. EXACTLY why. This is not a big complicated problem. Just set up crypto signatures on the status field and forgeries become trivial to deal with. (And actionable too.)

6

Subject: Agreed, but that’s detection, not prevention.

7

Subject: RE: General Security problem

Yes, signatures are way how to detect the problem. Do you know some easy way how to detect in on view level without running some detection agent or openning the document?

Thank you,

Martin

8

Subject: RE: General Security problem

I would run a detection agent.

Look, what you’re talking about is an attempt to forge a signature on a business process. If someone were to attempt to do this, wouldn’t you want to know? I sure would. If someone DOES attempt to forge a signature, then capture THAT as well, and email the guy’s boss, your corporate counsel, and the head of HR. After all, what would you do if someone forged their bosses signature on a paper version of the claim? Would you want to just throw the forgery in the trash, or would you want to know that this person actually tried to do this?

Anyway, if you really don’t want the document to show up in the approved view, no matter what the user does to try to forge it, then you need to use a field that the user doesn’t have the ability to completely control. I’d go with the $UpdatedBy field. If the @Subset($UpdatedBy; -1) = OriginalAuthor, then don’t show it in the view.

Then setting up an agent with an ID created specifically for this purpose, which would verify signatures at each stage and then be the last editor by setting a flag on the document.

You could conceivably make the view’s criteria be that the agent signature has to be the last entry in $UpdatedBy, and then, EVEN WHEN A MANAGER APPROVES THE REQUEST, it still has to have the signature verified and stamped before showing up in the view.

9

Subject: RE: General Security problem

Thanks a lot. Idea about stamping documents with validation agent and then displaying would do the job. It’ll take some time to process the requests, but in this case security is what matters :)).

Thanks,

Martin

10

Subject: General Security problem

Make the status field a signed field. The backend agent can’t forge the ID it’s running under.

For a more thorough approach, to make sure the original user doesn’t use an agent to change, say, the amount of the request after it’s been approved, you really should set a large number of the fields to be signed. After that, you might want to consider a variety of options like audit trails.