[Spacewalk-list] SP 2.3: Update user details issue

[Grant Gainey]

----- Original Message -----
> > Running on IE11 11.0.9600.17728 on Win7/64, and haven't been able to
> > reproduce this at all :(
> > 
> > What version of Windows are you on?
> 
> I tested on:
> - Windows Server 2008 R2 SP1 64bit with IE11 11.0.9600.17728
> - Windows 7 64bit with IE11 11.0.9600.17728
> - Windows Server 2008 R2 SP1 64bit with IE9 9.0.8112.16421
> - Windows Server 2003 SP2 with IE7 7.0.5730.13
> 
> Before the Upgrade from 2.2 to 2.3 it worked… very strange.
> 
> I compared the files in /etc/httpd/conf.d from before and after the upgrade.
> Besides of the removal of the perl-stuff it is all the same.
> 
> Can you give me some hints where else to look for error messages or
> configuration changes?

CSRF reject happens here:

https://github.com/spacewalkproject/spacewalk/blob/master/java/code/src/com/redhat/rhn/frontend/servlets/AuthFilter.java#L89

As you can see, it doesn't log - it just returns '403' and the message from the exception.

CSRFTokenValidator lives here:

https://github.com/spacewalkproject/spacewalk/blob/master/java/code/src/com/redhat/rhn/common/security/CSRFTokenValidator.java

If you look starting at #L79 you can see that validation fails if:

 * The *Session* has no CSRF token (you aren't logged in), OR
 * The incoming *Request* has no CSRF token (your page is malformed), OR
 * The session-token and the request-token don't match. 

The message "Validation of CSRF security token failed" is the third case - the token saved in the user's session doesn't match the one that is in the form being POSTed.

The CSRFToken is set in the session as a side-effect of CsrfTag.doStartTag:

https://github.com/spacewalkproject/spacewalk/blob/master/java/code/src/com/redhat/rhn/frontend/taglibs/CsrfTag.java#L45

because the CSRFTokenValidator, if asked to getToken(session) and finds that there is NOT one already, creates-and-stores the new one before returning it:

https://github.com/spacewalkproject/spacewalk/blob/master/java/code/src/com/redhat/rhn/common/security/CSRFTokenValidator.java#L67

Note that 'session' is long-lived - it's created when you successfully log in, and hangs out until you log out, or it times out (in which case you will need to log in again, and your CSRF token will *definitely* not be valid any more)

So - the question is, what is it about your setup, that causes the csrf_token value on the rendered web-page, to not-match the CSRF token stored in your login-session. I can think of ways to make that happen - but they would all break everyone's pages everywhere, every single time. I am having no luck finding a path through the code that would result in

 * session.token != page.token, and
 * your login-session still valid

and only for *some*pages/actions. Ugh.

If you use Firefox or Chrome against your SW instance, is the problem still reproducible?

Does the behavior change in IE if you change to/from compatibility-mode?

Anybody else on the list want to chime in here? I can't make this happen, in any environment I have access to.

G

> Regards,
> Bernhard
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

-- 
Grant Gainey
Principal Software Engineer, Red Hat Satellite