Problem with XSRF-Checks :(

[Boris]

I disabled Session-cookies on my installation (my vistitors don't need them) and to login I'm using the HTTP-Authentication-Plugin, which works quite good until I tried to change any settings which resulted in the XSRF-Warning, which relies on the session-id for tokens.

I think there should be some way to disable this XSRF-Checks. Perhaps something like $serendipity["imaybestupidbutireallywanttodisableXSRFchecks"] = true set in the config_local.php
That would be enough for me and I'll have to care myself about properly terminating my http-auth-session. I think it's even better to keep it out of the main configuration to prevent users to disable the checks by accident.


Another solution could be to define a long secret somewhere which is used as a hidden parameter in every form. As it's only visible in these forms noone could use it for XSRF-Attacks, right?

[garvinhicking]

Hi!

But s9y depends on PHP sessions with cookies. I don't think we can disable that. XSRF checks could be disabled, but other problems would stay. IMHO it's a good indicator that XSRF checks fail, it makes it easier to see that sessions are broken.

Regards,
Garvin

[Boris]

Of course sessions are broken. I disabled them

As said: The only problem I ran into is the XSRF-check that failes. The rest does not seem to strictly rely on sessions. (as long as you use http-authentication of course)

I could understand if you don't see the problem, as it's likey to affect one a very small part of the users (in other words: me). I'll use a patched version otherwise.

[garvinhicking]

Hi!

Saving and previewing entries relies on sessions

Regards,
Garvin

[Boris]

OK, to be precise. It creates a session, but cannot use it as there's no cookie with the session-id (php_value session.use_cookies 0). So the session is only valid for one single access to the page, after that the server is the only one that knows the ID.

This does not break posting entries, otherwise the link to your pictures would not have made it into my site.

I don't know how this works, but it does. I guess it's because once authenticated via HTTP the browser sends the credentials on every single hit on the domain. Then on every access the http-auth-plugin authenticates me and the normal action continues.

[garvinhicking]

Hi!

Does inserting an image via the media database work? I can't really believe this.

Posting entries this way should only work if you have transparent URI rewiting (session.use_trans_sid) enabled, or if you've disabled the $serendipity['use_iframe'] variable?

Regards,
Garvin

[Boris]

Does inserting an image via the media database work?

No, the XSRF-Check again. Didn't notice that as most of my pictures are on a different site.

Posting entries this way should only work if you have transparent URI rewiting (session.use_trans_sid) enabled

php_value session.use_trans_sid 0

or if you've disabled the $serendipity['use_iframe'] variable?

You found the reason. A coincidence that I had enabled this sometime ago

[garvinhicking]

Hi!

You could check if it works without XSRF checks. Disable them by editing include/serendipity_config.inc.php file and in the function serendipity_checkFormToken() add a line "return true" in the first line. This will bypass XSRF checks.

NOTE: You will definitely be able to be targeted with XSRF attacks this way, because HTTP auth will stay for your session, and people can send you evil links. Only with session cookies you are able to block those attacks.

I completely forgot about this. So, bottom line is that the s9y distribution will not get a bypass function, this is both dangerous as well as have an impact on entry creation, as s9y really requires sessions for that.

Regards,
Garvin

[Boris]

NOTE: You will definitely be able to be targeted with XSRF attacks this way, because HTTP auth will stay for your session, and people can send you evil links.

Yeah, I know. But clearing my http-auth in browser after using s9y should be enough.

So, bottom line is that the s9y distribution will not get a bypass function, this is both dangerous as well as have an impact on entry creation, as s9y really requires sessions for that. [/quote]
Understandable. I will think about another solution that does not require patching in include and may be more comfortable to me. But for the time being i'll do it this way and terminate my auth-session after using s9y.


I tought about only using Cookies for the admin-backend before, but didn't find a good solution to get it working.

[Boris]

I decided the better way is to use session.use_trans_sid in the admin-backend. Who cares about pretty URLs there.
The security-impact of this is minimal as I don't post links to my admin and if I would do, I'd immidiatly see the Session-ID in the link.