Deleting after each request (and your other fix) certainly take care of that vector.

captcha=view.getDocumentByKey(captchaID);

If not captcha is nothing then

'testing logic

else 'Something wrong. Assume it's ok and continue?

document.replaceItemValue("CaptchaPassed", "1")

end if

Spot the flaw? It's unlikely but if a hacker figured out unfound captcha documents led to a success they all they'd have to do is change the hidden CaptchID field in the form to "foo" and it would pass. Doh!

I'll change the logic to set a flag for admin approval now.

What is to prevent the user from answering the captcha once manually, and then modifying each requested page for the duration of the lifetime of said document?

I don't know that that would work, since you've left out some details of the process.

Rather than "Secure Enough" I'd say this was "Completely Secure".

Dictionary.com says secure means "to guarantee the privacy or secrecy of" which I think this does a pretty good job of. Especially as the answer is hashed now ;o)

Jake

In general with notes client work though, I'd agree. Any user that can access the document can see all values on it, and there is nothing you can do about it other than encrypt the field.

In a pure web environment though, you can store values on docs that the user should never see, as long as you are careful not to let that information get back to the browser.

"Secure Enough" is a decision to be made by the business/process owner. This probably meets "Secure Enough" but doesn't meet "Secure" in my opinion.

Never?

If a document is that well hidden that there's no *possible* way in the world you can ever see it then I'd say it *is* secure. Is it not? Maybe not secure in the true sense of ACL and Readers fields but surely sometimes you can achieve a certain level of secureness without them?

I can't use readers fields/ACLs anyway as (is the case with most CAPTCHA-enabled forms) the user is Anonymous.

#1 - Hidden documents aren't secure. You've done well in the hiding of it, but that's not the same. If you want to prevent access, put reader names on it or store it in a db with an ACL. On the submit, have the agent which runs be signed by an ID which DOES have access to look up the answer, but DOES NOT have access to the object with the file itself. There's a lot of details I left out, but from your post you seem up to that. Obscurity is never security.

#2 - Captcha isn't perfect at all. My favorite captcha hack is when they set up another site which requires captcha input -- a popular one, like maybe a free porn site. When they show users THEIR captcha screen, they use script to do the page load on YOURS to get the captcha image which they then retransmit to the user of their site. The user answers their captcha question, and that answer is then submitted as the answer to your own site. This way, they get real people answering your site's captcha requests without you knowing it.

That said, you have to be an important target for this to be worthwhile. Opening GMAIL accounts for spam sending, for example, would be a "good" use of this technique. Posting blog comments probably would not.

One entry said, "What I do is generate an image in the agent. Then save it to the local file system."

The other said, "... just get the image stream from Google and save it to a uniquely named file ...".

So what did I miss? How does this help Jake in not writing the file to the disk first?

Have a nice day ;)

I know a few of the different ways you can get at documents in database but I'm assuming in my case none of it matters as there's only one Form with which to display any document found and that's not only hidden but also blank.

I wrote a Java servlet a few years back that highlighted one way {Link} which is now closed (I think/hope).

<b>By-passing ACLs set on views</b>

The fact that you can request a document in one view through another view opens up a security hole. If ACLs are set on a view to give say only admins access, then any documents in that view may be access directly through another view - thus bypassing the access control. This works because the permissions allow access to the database, the fake view and the document in question. At each stage where permission checking takes place the authorization process succeeds. If the request was made through the real view then authorization would fail. Remember by requesting a NoteID you're simply asking for the contents from a position in the database file.

Extract taken from ...

www.ngssoftware.com/papers/hpldws.pdf

The only way for someone to "Solve" it is if they know the alogrithm used to hash it, and if your using domino's own function then it should already be secure. You may not even need to store it as it could be used again.

Just an idea...

I had a go at the MIME yesterday and managed to save an image to a document, but only a document that was committed to the disk before being opened as ?OpenDocument. What I couldn't manage is to add a MIMEEntity to a rich text field on a Form using the WQO agent and having it display to the user. Is that possible?

I take it for this scenario, this is the only "session" you need. If multiple forms need submited, then multiple captchas must be passed?

Also as a follow up to yesterdays post, I've succesfully added a file to a document via MIME without saving it to disk. I was getting the file as base64 encoded via a webservice, but the principle should be the same.