The login page is a copy of the default page in domcfg.nsf.  The only change is graphic with a custom logo.  The RedirectTo field is set to "/".  Again, it only fails if I set DominoValidateRedirectTo=1 in the server NOTES.INI file which I need to inorder to fix a security vuln.

Thanks!

I will give it a try this weekend(production server) and let you know on Monday.

Thanks!

I have tried every form of redirect possible on this but everything fails once I set DominoValidateRedirectTo=1   Does anyone have any info that explains how this is supposed to work?  My security group is really pushing to get this resolved.

Thanks

We where having a similar problem after we set DominoValidateRedirectTo to 1 but not on all our sites.

To diagnose the problem I checked the source of the login pages for our sites where it was working and where it was not.  All the sites had the $$_vrds=<token> but on the sites where it worked the URL was a relative reference with an absolute path, and on the site where we got the Invalid URL exception it was an absolute URI.  

To be clear this is an relative reference where it would work:

    /sales/orders.nsf&$$_vrd2=token
    
this is an absolute URI where is would not work:

    http://apps.company.com/sales/orders.nsf&$$_vrd2=token
    
We started looking for differences between the set up for these sites.  We disregarded the login form as it is a simple modification of the default from domcfg.nsf and the same form is used on sites that work and do not.  In one instance we have two sites running on the same Domino server but with different internet site documents, one works and one does not.  The main difference between them is the site that works was set to redirect all TCP to SSL where the site that does not work is only set to force login on SSL.

Our conclusion is that when "Force login on SSL" is set to "Yes" the redirectTo value in the login form is an absolute URI.  This makes sense as it allows the login to use HTTPS but switch back to HTTP afterwards.  The problem is that DominoValidateRedirectTo seems to fail with absolute URIs.

To work around the problem we have found you can either set the entire site to use HTTP (security department would not be pleased) or set the entire site to use HTTPS.

Do either of these vulnerabilities apply to 9.0.1? How can I test each on?

Thanks!

Mark,

All our servers in these cases are running Domino 9.0.1 FP2.

How can I test whether the vulnerability exists - so that i can test whether the notes.ini 'fix' works?

This is the first I've seen of this vulnerability, and it seems kinda odd that the fix requires an Admin to be proactive (add a notes.ini parm) as opposed to adding a notes.ini parm to disable the fix - the difference being that all servers would be patched unless the admin decided to disable it.

Thanks!

I tested this using Firebug to manipulate the value of the redirectTo field on the log in form.  With DominoValidateRedirectTo=0 I could happily redirect the login form to any page I like.  With it set to 1 any tampering would result in a HTTP 500 Invalid URL Exception.  I'm not a hacker but I assume using some carefully crafted URL or link could do the same.