I am trying to implement the fix for SPR# KLYH8WBPRN. However, when I add DominoValidateRedirectTo=1 to the server NOTES.INI and restart the HTTP task my site breaks. After logging in, I get the following error:
invalid url exception [names.nsf?Login] Anonymous
This is the url for the SPR:
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.
When the ini is set, and when the login page html is generated by the Domino Server the URL set in hidden Redirecto field should have an extra temporary query string argument appended to it. That argument appears as $$_vrd2=. When the form is posted the login processing will use that token to validate if the redirect to URL to make sure it has not been hacked/changed. If the token is not present or the URL cannot be validated then the login request is rejected. The extra query argument is stripped off before doing the redirection after login.
If for some reason the login form has some other way of specifying the redirect to URL (the domino server does not generate it or is overridden with something else). The the token will not be present and the login request is rejected.
So for example, if the incoming URL that causes a login page to appear looks like /foo.nsf?Open, the redirectto url in the login form should look like /foo.nsf?Open&$$_vrd2=
When the form is posted the login processing will take the and verify it before login, if okay we do the login and redirect back to the orginal url /foo.nsf?Open. If the validation fails then login fails.
In your case the redirectto field should be set to /?$$_vrd2= and if login is successful then we would redirect back to / and strip off the ?$$_vrd2 query arg.
If this continues to be a problem, the next step will be to raise a pmr. There may be something about your use case and your login form that is causing things not to work.
Subject: How can I test whether the vulnerability exists?
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.
Subject: DominoValidateRedirectTo=1 and “Force login on SSL”
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= 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:
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.
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.
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.