Embedthis Ejscript Forum

I have the following in my appweb.conf:


and I am seeking to download /web/Foo/foo.html, which is both within the Location and within the Directory. So it knows it is within an App, and it knows that its first choice of handler is EjsHandler. But it soon realises that FileHandler is the proper thing to use for this html page. So, in pipeline.c it has tried findLocationHandler and then findHandlerByExtension and, since neither has found a handler it proceeds to mapToFile, which calls maLookupBestDir, which discovers that this directory requires authentication and arranges to put the proper authentication filter in the pipeline, and off it goes. The browser pops up a window asking for username and password, and all proceeds correctly and the authentication is accepted and the page displayed. So far so good.

BUT now I try to download /web/Foo/foo.ejs, and this time it finds, in findHandlerByExtension, that the EjsHandler is appropriate, so it doesn't need to call mapToFile, and therefore it never calls maLookupBestDir (which is only ever called from mapToFile), and hence it doesn't know that authentication is needed, and it serves up the page without it :-(.

NOT SO GOOD! A bug in fact.

ISTM that another call to maLookupBestDir is needed somewhere (perhaps within findHandlerByExtension), but I will leave it to you guys to fix that.

Now for the second Bug (or misfeature?). I see that, following RFC 2617 for the Digest method, it first returns a challenge with a WWW-Authenticate header containing a nonce value. The browser returns the username with the password hashed using this nonce value (in an Authorization header) which the server then compares with users.db and, if it matches in the proper way (clearly I have simplified the precise details) it releases the page.

Again, So Far so Good, An eavesdropper cannot discover the password.

BUT the server makes no attempt to check that the nonce the browser has used in the Authorization header is the same as the nonce that it had earlier sent in the WWW-Authenticate header, and this is clearly contrary to the intent of RFC 2617, since it leaves the door wide open to a Replay Attack by the eavesdropper, who can now submit that same Authorization header weeks later when the nonce is long expired, and he will be let in to view the page.

BUG, rather than Misfeature IMHO :-(.

You can add Auth directives to location blocks and to dir blocks. The ejs handler is marked as a virtual handler in that many ejs URLS don't really map to physical files. So it is best to use auth directives in a location block (i think)

I'll mark this as an issue to investigate anyway. There may be a better solution - at least as u indicate to do dir based auth checking when running ejs by extension.

The spec does allow, but not require validating nonce ingredients. Good suggestion, we'll add that to the list.

peter

There are two problems with that:

1. A dir block does not catch /web/Foo/foo.ejs, but conversely a location block does not catch /web/Foo/foo.html. so if you want to protect the whole of /web/Foo you have to have:

2. But even that does not work for /web/Foo/foo.ejs because, even though it returns a page saying "Error 410", the Code actually returned is '500', and so the browser does not recognize it as requiring a password. Certainly, it starts off with conn->response->code == 401, but somewhere inside Renderview that gets changed to '500'. I haven't tracked down exactly where this is happening (tracing within Escript is well-nigh impossible), so I shall leave it to you guys again.

Indeed, but RFC 2617 allows you to do (but clearly intends you not to) all sorts of things. And it includes a long "Security Considerations" section which sets forth all the evils that can ensue if you ignore their advice.

Thanks for your detailed reports.

THe solution is to remove VIRTUAL for the ejsHandler but to make the pipeline matching a little smarter. We're testing this now.

If the match is by location, then the request is virtual. If the match is by extension, the request is non-virtual. That way, if a location block fails to match and it matches by extension, the normal mapToFile code will run and set the required auth details.

We'll toughen up our nonce validation too.

Thanks for the tips.

Michael

Those changes look good. Specifically, we've tested the change to make the ejs handler non-virtual. There were quite a few related changes, but the end result works well. Files with a *.ejs extension can use basic or digest authentication.

For improved nonce handling. We've made changes to validate the nonce value and give it a limited timespan. We're also validating the secret which is changed in the server and also the etag. This should make replay attacks very difficult indeed.

thanks for your suggestions.