Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 205
  • Last Modified:

"sniffing document IDs"

Hi:

Can you tell me if it's possible to determine a document unique id via the web? (i.e without the document being visible via the web?) I'm especially interested to know if there is any malicious software which can do this, and if so, how to defend against it.

-Ke
0
kkiddie
Asked:
kkiddie
  • 6
  • 4
  • 2
  • +2
1 Solution
 
qwaleteeCommented:
It wouuld be very difficult to do.  In R4 and R5, it would probably be easier to sniff out via DocIDs, which are much smaller and less random.
0
 
HemanthaKumarCommented:
There is no mailcious software to do that.. Your ACL does filter out most of those kind of activity from external ..

What is that exactly that you are afraid of ?

~Hemanth
0
 
Bozzie4Commented:
Yes, this is possible.

At least, starting from R5.  Try this :

http://server/database.nsf/View?Readviewentries

Will show you the document unique id's (among others) in xml format.
You can of course deny those ?readviewentries urls

cheers,

Tom
0
Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
Bozzie4Commented:
Of course, you would need access to the view, and the database, and you must be authorized to read the document in the first place.

But this does work just fine for views you could expect to be present in a database ( ($All), All Documents, LU, LUVIEW, lookup, .... )), or with the defaultview url

http://server/database.nsf/$defaultview?Readviewentries

cheers,

Tom
0
 
kkiddieAuthor Commented:
I just detected this and it seems curious... tell me if it's correct... if you know the document unique id (of a document with no readers field on it), even if the document has been created with the form security set to prevent web reading, and the view security is set to prevent web use, you can still access the document.

Additionally, you don't even have to know a valid view name... random characters in place of the view name will work.

Anything you can tell me about this would be appreciated.

As well, if I did want to put a readers field on a form... would I just set a default value of the appropriate ACL groups or individuals?... and this would prevent it from being read even if one knows the unique document id?

-Ke
0
 
Bozzie4Commented:
If you know the documentunique id, you can open the document if
- you can read the document (access through ACL, and readers fields)
- there is a form to display the document (you could have forms for notes use only, or a special form for web use)

cheers,

Tom
0
 
HemanthaKumarCommented:
In the acl, set default to no access and set anonymous to no access. This will force only the users who are authorized to access the data...Thus by keeping out the "malicious" users..
0
 
Bozzie4Commented:
Hemantha, if you want to create a Notes based website, that 's not really a solution, is it ?

So if you do allow anonymous access to your database, you have to be careful when designing the application.  Don't rely on 'security thru obscurity' to secure your application ....

cheers,

Tom
0
 
HemanthaKumarCommented:
basically that is what he wants.. prevent other users to mess around..
0
 
HemanthaKumarCommented:
Another way is to hide the location by using frames
0
 
Bozzie4Commented:
That's 'security tru obscurity' .  No would-be hacker or nosy sniffer will be stopped by that :-)

0
 
qwaleteeCommented:
If your users all use the same root hierarchical certifier, and all Notes client users SHOULD be able to read all documents, then set up a readers field with */RootCertName (you wil also want to set up a separate readers field with a true name, because I don't remember whether */Cert works with both ACL and readres, or just ACL, and if I am wrong, you will have a phantom doc in your DB).

A variation of the above:  If your web users will all be anonymous, then create a role called NonAnon, and assign the role to all ACL entries EXCEPT Anonymous (make sure you do have an entry named Anonymous).  Then, set a readers field with [NonAnon] computed for it.

Now, if your web users are not always anonymous, then you just need a well designed readers-restructed app to start with.
0
 
Sjef BosmanGroupware ConsultantCommented:
I just fail to see what the problem is. If you open a database for webusers, then those documents are meant to be visible, aren't they? If users aren't supposed to watch them, then hide them, protect them, or move them to a separate database. Users modifiying documents can easily be prevented.

But don't you have exactly the same (or worse) with any HTML-based website? Sniffing documents there isn't that difficult. Checking ww.website.ext/default.htm or /index.htm or just generate names and you'll strike oil some day. And so what? The document is visible, yes, but who has a public website with only invisible pages? Luckiloy, with Notes, you can pull up a nice fence where you want it.
0
 
Bozzie4Commented:
The problem could be that some documents, although the content is public, are not meant to show.
Examples are documents where you store attachments (images,...) or configuration documents.

Of course, the biggest problem would be a less-than-perfect design to begin with....

cheers,

Tom
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 6
  • 4
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now