SID-02429: Login with URLPARAM transfer

Status:	Asked	TWiki version:	6.1.0	Perl version:
Category:	CategoryAccessControl	Server OS:		Last update:	5 years ago

When an unauthenticated user visits MyTopic?myvar=1234, this topic offers the possibility to login or register. However, after login, the user is directed to MyTopic, without the URLPARAM (?myvar=1234). Is it possible to login with conservation of the URLPARAM?

-- Emiel Van Riel - 2020-02-21

Discussion and Answer

Hmm, that should work. Let's test here:

• https://twiki.org/cgi-bin/view/Support/SID-02429?ip=1.2.3.4 - current ip:
• https://twiki.org/cgi-bin/view/Support/SID-02429?skin=pattern - current skin:

-- Peter Thoeny - 2020-02-22

OK, it works for links that force a login. TWiki.org is configured to require auth for URL parameter skin, but not for URL parameter ip.

But you are right, it does not work with login menu item.

-- Peter Thoeny - 2020-02-22

Login URL parameters are sanitized for security, s/[^a-zA-Z0-9_\-\.\:\/\?\;\&\~]//g, see Codev.SecurityAlert-CVE-2011-1838. It could however be relaxed a bit by allowing the equal sign.

-- Peter Thoeny - 2020-02-22

I could confirm Emiel's observation on my own installation, and also here: If I logout, then visit https://twiki.org/cgi-bin/view/Support/SID-02429?skin=pattern, I'm asked to login. After the login I'm redirected to https://twiki.org/cgi-bin/view/Support/SID-02429?twiki_redirect_cache=99664539940ecac08543754016a8ab39, so the skin parameter is gone, and a twiki_redirect_cache appears instead.

My memory is a bit shaky but I seem to recall that twiki_redirect_cache is used by POST requests (the login screen is a POST request) to store query params. The login page still has the query params in its URL, both verbatim and in the origurl parameter, and it supplies both to the login process as hidden parameters. I guess that the redirect cache should be resolved into the original URL parameters when the successful login processing redirects back to the original page.

This is more than filtering: The login URL parameter is not just filtered, but eliminated altogether. If filtered, it should still read ?skinpattern.

I also understand the CVE which was effective because TWiki renders the URL parameters in the login link, where they should be both HTML- and URL-encoded... Filtering works, too, but seems a bit radical.

-- Harald Jörg - 2020-02-22

In login.tmp lines 33 -37 it says:

%TMPL:DEF{"formstart"}%<form action='%SCRIPTURLPATH{"login"}%/%WEB%/%TOPIC%' name='loginform' method='post'>%TMPL:END%

%TMPL:DEF{"formend"}%<literal>
%QUERYPARAMS{encoding="entity" format="<input type='hidden' name='$name' value='$value' />"}%
</literal><input type="hidden" name="origurl" value="%ORIGURL%" /></form>%TMPL:END%

Has this to do with this problem? I cannot find where %ORIGURL% is defined.

-- Emiel Van Riel - 2020-02-24

To answer your question: The variable %ORIGURL% is provided by TWiki code (in lib/TWiki/LoginManager/TemplateLogin.pm, line 228). Check the HTML source code of the login page: In my own installation the hidden parameter is there, and it shows the correct value, including the query string.

I ran a few tests and a debug session: Though the browser shows twiki_redirect_cache in its URL, the URLPARAM parameter is correctly evaluated in the TWiki content. So as Peter wrote, it should work. The cache is resolved by TWiki, and the temporary cache file is cleared after that.

So here are some questions / ideas:

• Do you see the twiki_redirect_cache parameter after login?
• Also, you can check your TWiki working directory: Does it have a subdirectory tmp, and is it writable by the user id of the web server (I guess it is, or you would face other issues)?
• Do you have any action in your TWiki page which causes the page to reload or redirect? Reloading a page with twiki_redirect_cache in its URL will lose the parameters from the cache, because the cache is deleted on first use.

-- Harald Jörg - 2020-02-28

Maybe I found something which is not going well:

In ../twiki/working/tmp I don't see a twiki_redirect_cache parameter. I do see cgisess -parameters, so it looks like this directory is writeable by de server.

After logging out form MyTopic?myvar=1234, I see a QUERYPARAM: name='twiki_redirect_cache' value='49db760...........c57849c283'.

During login in my browser I see: https://www.MyTwiki.com/do/login/...../MyTopic?origurl=/do/view/......./MyTopic%3ftwiki_redirect_cache%3d49db7.............31cf548c57849c283 .

After login in my browser I see: https://www.MyTwiki.com/do/view/....../MyTopic?twiki_redirect_cache=5e9008f88.......c4dd1e98c6d0e.

But the QUERYPARAM of MyTopic says: name='crypttoken' value='4ea92e944ea978b56f3d7f4ae85d8a8c' .

And in no phase of this process I see a twiki_redirect_cache parameter in the ../twiki/working/tmp directory.

Can you tell me what is going wrong?

-- Emiel Van Riel - 2020-02-29

Thanks for checking: If your working/tmp directory contains sessions, then the server can write it.

I should clarify: twiki_redirect_cache is the name of the URL parameter. The value of this parameter is appended to a file with a name passthrough_[insert_value_here]. These files are short-lived and exist only between a redirect response by TWiki, which is automatically followed by your browser to the redirect's location, and TWiki's response for that location. So you can't spot them without debugging aids.

There's something strange in the step During login in my browser: During that step, the origurl parameter snould end in %3fmyvar%3d1234 (that's encoded for ?myvar=1234), and there should not be a twiki_redirect_cache yet. So the question is: How do you "log out"? In the top menu entry for logout, the link should be something like https://www.MyTwiki.com/do/view/...MyTopic?logout=1.

Also, you could examine the HTML source code of thh form in the login screen: It should contain <input type='hidden' name='myvar' value='1234' /> and <input type="hidden" name="origurl" value="/bin/view/Sandbox/NotPublic?myvar1234" /> immediately before the </form> closing tag.

-- Harald Jörg - 2020-03-01

Well, I am logging out with the https://www.MyTwiki.com/do/view/...MyTopic?logout=1 construct. I saw the equalsign = missing in <input type="hidden" name="origurl" value="/bin/view/Sandbox/NotPublic?myvar1234" />, so I added ' \= ' to line 146 of TemplateLogin.pm, as Peter suggested obove. Now, after logging out from MyTopic?myvar=1234 , I see an URL .../do/view/MyTopic?myvar=1234. Also the QUERYPARAM of MyTopic gives: name='myvar' value='1234'. Now, during login the URL is .../do/view/MyTopic%3fmyvar%3d1234 . In the HTML source of the login screen there is <input type="hidden" name="origurl" value="/do/view/......../MyTopic?myvar1234" /> and <input type='hidden' name='crypttoken' value='5e9008f88.......c4dd1e98c6d0e' /> . After login the URL is https://www.MyTwiki.com/do/view/....../MyTopic?twiki_redirect_cache=5e9008f88.......c4dd1e98c6d0e . And myvar is not passed to MyTopic ....

-- Emiel Van Riel - 2020-03-02

Is the crypttoken passed, because the equalsign = is filtered out elsewhere?

-- Emiel Van Riel - 2020-03-02

Or, is it, like Peter noted above, that a forced login origurl is treated different from a chosen login? In TemplateLogin.pm from line 68 is see a ObjectMethod "called when authentication is required". But from line 114 there is another ObjectMethod, where origurl is filtered.

-- Emiel Van Riel - 2020-03-02

• I assume with QUERYPARAM you are actually referring to VarQUERYPARAMS with a custom format?
• crypttoken is not related. This is a mechanism to protect login actions against XSS attacks, you can disable it by setting $TWiki::cfg{CryptToken}{Enable} = 0: in TWiki's configuration.

I don't understand a few things here:

• Now, after logging out from MyTopic?myvar=1234 , I see an URL .../do/view/MyTopic?myvar=1234: After logging out, you should not see this URL if, as you wrote in your first article, unauthenticated users are given the possibility to login or register.
• Now, during login the URL is .../do/view/MyTopic%3fmyvar%3d1234 : I guess that what you write here is the value of the origurl URL parameter at the end of the URL. The actual action is supposed to be .../do/login/. In any case, the final part of that URL is exactly as it should be: The characters ? and = are correctly URL-escaped.
• And finally: It seems that the value of crypttoken and twiki_redirect_cache are the same. This does not explain your issue, but this should never happen.

I should also note again that the logout/login cycle can not be repeated: If you log out from a topic where the browser still displays a twiki_redirect_cache, then myvar is lost after the next logon.

Could you please log out from twiki.org and then visit Sandbox.UrlParamTest?myvar=1234 (a topic I've created right now, only the both of us have view access) and check whether it works here? And if you copy URLs, please do not omit parts.

-- Harald Jörg - 2020-03-02

Thanks, Harald. I now realise that MyTopic can also be viewed by an unauthorised user. This is set with a topic preference ALLOWVIEW = AllUserGroup. This explains why the URL can be seen by the user who is not (yet) logged in?

-- Emiel Van Riel - 2020-03-03

I think we're back to the first comment of Peter: "OK, it works for links that force a login. TWiki.org is configured to require auth for URL parameter skin, but not for URL parameter ip."

-- Emiel Van Riel - 2020-03-03

TWiki.org has a unusual setup to require auth when URL parameters are used to curb back greedy spiders. Here is the relevant section in the twiki/bin section of the apache config:

    RewriteEngine On
    RewriteCond %{SERVER_NAME} =www.twiki.org
    RewriteRule ^ https://twiki.org%{REQUEST_URI} [END,NE,R=permanent]

    RewriteCond %{QUERY_STRING}  !^$
    RewriteCond %{QUERY_STRING}  !^(slideshow=|note=|search=|skin=text|skin=plain|tag=|dir=|ip=|TWikiGuestCache=)
    RewriteRule view/(.*) /cgi-bin/viewauth/$1

-- Peter Thoeny - 2020-03-03

O.K., challenging!

To let an unauthorised user login to www.myserver.com/MYTWIKI/MyTopic?myvar=1234 with conservation of the URLPARAM, can I add | myvar= to the Apache config line?

   RewriteCond %{QUERY_STRING}  !^(slideshow=|note=|search=|skin=text|skin=plain|tag=|dir=|ip=|TWikiGuestCache=|myvar=)

-- Emiel Van Riel - 2020-03-05

No, the opposite, the RewriteCond has a ! aka "not" condition. If you want to force auth just for myvar add this:

RewriteCond %{QUERY_STRING}  ^myvar=

-- Peter Thoeny - 2020-03-05

I'm sorry, but I still can't fix it. When I -as an unauthorised user- try to login to MyTopic?myvar=1234 (topic preference ALLOWVIEW = AllUserGroup ), I am redirected to /do/login/MyWeb/MyTopic?origurl=/do/view/MyWeb/MyTopic%3fmyvar%3d1234 . Hence, the origurl parameter contains a view, so at login the QUERY_STRING is deleted for the unauthorised user. So I tried a Rewrite like this in Apache config:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^.*/login/.*MyTopic
RewriteCond %{QUERY_STRING} ^(.*)origurl\=/do/view/(.*)
RewriteRule ^(.*)origurl\=/do/view/(.*) $1origurl\=/do/viewauth/$2 [QSA]

-- Emiel Van Riel - 2020-03-06

You could patch your TWiki to not sanitize origurl, basically by reversing Codev.SecurityAlert-CVE-2011-1838, e.g. remove the # Item6673: Cleanup origurl parameter code. This means, your TWiki will be open for this vulnerability, which might be ok or not, depending on your situation.

Or, try first to not remove, but allow the equal sign in twiki/lib/TWiki/LoginManager/TemplateLogin.pm - untested:

    $origurl   =~ s/[^a-zA-Z0-9_\-\.\:\/\?\;\&=]//g;

-- Peter Thoeny - 2020-03-07

Or, is it possible, that in line 208 of LoginManager.pm

$origurl = $twiki->getScriptUrl( 0, 'view', $web, $topic );

Like in line 86

$url   = $twiki->getScriptUrl( 0, 'login', $web, $topic );
        $query->param( -name => 'origurl', -value => $twiki->{request}->uri );
        $twiki->redirect( $url, 1 );

or line 108:

$twiki->getScriptUrl( 0, 'login', $web, $topic,
        origurl => $twiki->{request}->uri );

Emiel Van Riel - 2020-03-08

I found out something. Back to te begin: !MyTopic can be viewed by an unauthorised user. This is set with a topic preference ALLOWVIEW = AllUserGroup . When the unauthenticated user visits MyTopic?myvar=1234 , this topic offers the possibility to login or register. After login, the user is directed to MyTopic, without the URLPARAM (?myvar=1234) .

Now I found out that login generates an URL: !https://www.MyTwiki.com/do/login/...../MyTopic?origurl=/do/view/......./MyTopic%3fmyvar=1234 . I think the problem is in the %3f , meaning a '?' . So the query has two '?' s, while there second should be a ='&' ? Maybe I found the problem, yet don't know how to solve this.

-- Emiel Van Riel - 2020-03-19

No, this is expected behavior. The value of the origurl needs to be URL encoded, so that it will be represented properly in memory when used.

The filtering issue of the URL parameter after login must be somewhere else.

-- Peter Thoeny - 2020-03-19

Okay. Loggin in with two variables MyTopic?myvar=1234&myothervar=okay results in a querystring crypttoken=c0aa6920802417a7b9d8bf0488686b4b;myothervar=okay. So the first URLPARAM is substituted by a crypttoken, the second isn't. And, when logging OUT, both URLPARAM's are preserved well.

-- Emiel Van Riel - 2020-03-20

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.