Moodle in English: Cross-Site Request Forgery (CSRF) in Moodle default pages

Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Vincent Gullotta - Saturday, February 21, 2015, 5:44 AM

Hello all Moodle security people. We have a new Moodle Installation 2.8.3+ that is supposed to go live early next week. When we run a scan of our Moodle installation, it's hitting a bunch of forms for:

150071 Form Can Be Manipulated with Cross-Site Request Forgery (CSRF)

So I did a bunch of research and found that SESSKEY is supposed to resolve these. I then found we had Moodle set to use the database for sessioning. When I disabled that, it started adding SESSKEY to some of the URLs. However, we are still getting issues with CSRF being flagged on a few forms. These are the pages that are getting flagged by the scan.

/report/stats/user.php?id=12&course=22
/course/index.php?categoryid=1
/user/index.php?contextid=68&roleid=5
/mod/scorm/player.php
/report/courseoverview/index.php
/user/edit.php?id=12&course=1
/login/change_password.php
/mod/scorm/view.php?id=43
/message/edit.php?id=12
/index.php?usergroup=search&advanced=1
/report/log/user.php?id=12&course=22&mode=all

Can anyone help me get this nailed down? I can't get a public VIP from network engineering until I get approval from Security, and they're not going to give me any approvals on this site until the CSRF issues are worked out.

Any suggestions? The manual says to use moodleforms where available, but this is a relatively default installation. We haven't even installed any custom plugins or anything other than a theme, so I figured all the forms in Moodle were "moodleforms", so I'm not even sure that's the issue.

Thanks in advance,
Vinny

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by ryan sanders - Saturday, February 21, 2015, 8:17 AM

reading http://en.wikipedia.org/wiki/Cross-site_request_forgery and then seeing your statement of "custom theme" and on multi pages. i would say your theme is your problem. maybe a mistype some place in the custom theme?

--------------------

site admin menu -> development -> debugging (turn on options) you might get something.

i want to say there is something in...

site admin menu -> appearance -> theme -> a setting in there. that might show some additional info. to help see theme info.

--------------------

sorry not a security person for moodle.

Average of ratings: -

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Marina Glancy - Saturday, February 21, 2015, 8:23 AM

interesting suggestion, Ryan.

Vincent, before you create an issue, make sure that all those errors are also shown on one of the standard themes.

Average of ratings: -

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Marina Glancy - Saturday, February 21, 2015, 8:21 AM

Hello Vincent,

the urls that you posted above mostly have forms for searching or filtering results or are used to quick jump to other pages, they don't need sesskey and they are not vulnerable for CSRF.
login/change_password.php has sesskey on the actual change of password form but there is also an admin settings search form on this page.

I searched the code of your error and it looks like you have Qualis software installed to automatically scan web pages.

It will be interesting to investigate why Qualis triggers false positives. I suggest you to create an issue in tracker for it. I wonder who else uses similar software and how they dealt with such warnings. Do not mark the issue as security - as I said, there is no security threat here, but marking the issue as security will make it invisible for most of the users.

Also, just to add here that sesskey is added by moodle regardless of the session store method.

Average of ratings:Useful (1)

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Dan Marsden - Saturday, February 21, 2015, 9:14 AM

I've seen similar issues with automated tools.

Moodle implements a method of CSRF protection (to prevent CSRF attacks) that uses a variable called the "sesskey" - many automated tools see the name of this variable and assume that it is the full session id (which is basically used to authenticate the user with the site.) If it did contain the full session id this would be a significant problem with the design of the code and could result in CSRF vulnerabilities but this is not the case with the moodle "sesskey" variable.

The potential solution would be to rename the "sesskey" variable in Moodle to something like "preventcsrf" but it might be hard to justify simply to stop these automated tools from reporting false positives. And would require a lot of code to be changed.

Average of ratings: -

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Vincent Gullotta - Tuesday, February 24, 2015, 12:27 AM

Interesting, so it would seem the Qualis scans are getting false positives from the search box. Perhaps there is an error in the theme. It's a theme we purchased, so I kind of felt it was probably pretty solid, but perhaps there's a typo or something in that search form that is causing the Qualis scans to fail. I will look at the code and see if I can find anything. Thank you.

Average of ratings: -

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Richard Oelmann - Tuesday, February 24, 2015, 1:50 AM

'It's a theme we purchased, so I kind of felt it was probably pretty solid' - hmmmm.....

One way to see if the theme is the issue - carry out the same tests but with the theme set to Clean. Although I'm not sure I see anything in what Marina or Dan have written to suggest this has anything at all to do with the theme, the admin settings search box Marina mentions is part of the Administration block and is theme independent.

Average of ratings: -

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Vincent Gullotta - Tuesday, February 24, 2015, 3:11 AM

So, is there any way to make Moodle add SESSKEY values to every button and link? Also, is it possible to make this more of a CSRF token where it changes with every page refresh instead of being static throughout the session?

My concern is:
While the SESSKEY makes CSRF more difficult, from what I understand, it doesn't necessarily prevent it. All you would need to do is steal the SESSKEY and then trick an admin to load a forum post with some XSS hidden in it before the admin's session has ended, and all of a sudden all users are administrators, or all users are deleted or something along those lines. While I understand it would be difficult to get the SESSKEY, it doesn't seem impossible.

Please correct me if I'm understanding this wrong.

Thanks,
Vinny

Average of ratings: -

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Marina Glancy - Tuesday, February 24, 2015, 5:29 AM

If we add sesskey to the form, we need to add validation of it on the back end (processing of the form submission). Which we should not do for the search/quickjump forms as it will make impossible to create shortcuts or links to the search results. It will negatively affect usability.

"Satisfying qualis" is not the first priority goal for moodle. The actual security and usability are.

Before accusing moodle, as well as any other web site, of the "weak" security protection using sesskey, please write step-by-step instructions how can one "steal" a sesskey. If admin leaves his session open and computer unlocked, os infected with viruses or door key under the mat, moodle can't help, sorry.

P.S. I hope you understand that knowing sesskey alone will not let other user forge a request as admin, the actual session (cookie) is needed too.

Average of ratings:Useful (1)

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Vincent Gullotta - Tuesday, February 24, 2015, 6:18 AM

I don't believe I accused Moodle of being "weak" anywhere.

Average of ratings: -

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Vincent Gullotta - Tuesday, February 24, 2015, 6:43 AM

If we have the step by step instructions on how to do it, do you want them posted here or in the tracker?

Average of ratings: -

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Vincent Gullotta - Wednesday, February 25, 2015, 12:25 AM

Also, not to nitpick or anything, but this entire statement is incorrect:

"Before accusing moodle, as well as any other web site, of the "weak" security protection using sesskey, please write step-by-step instructions how can one "steal" a sesskey. If admin leaves his session open and computer unlocked, os infected with viruses or door key under the mat, moodle can't help, sorry."

1) I never said it was weak, we already covered that before.

2) Step by step instructions can be as simple as looking over someone's shoulder, or a man in the middle attack, or a proxy server gets compromised, things of this nature. Once that static session key is obtained, the rest is just about tricking an admin to load a page with some code on it. The page can just be blank, all it takes is 1 click and everyone on the site is now a Moodle Admin, or deleted, or something along those lines.

3) Moodle CAN help with that by using real CSRF Tokens and not static session keys.

4) Moodle CAN put a popup on every page reminding you not to leave your door key under the mat.

We fully reproduced this yesterday and we were able to script it out to change my admin login information, just as a test, and it absolutely is doable.

Average of ratings: -

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Dan Marsden - Wednesday, February 25, 2015, 4:54 AM

I'm pretty sure our "sesskey" implementation is what OWASP call the Synchronizer Token Pattern (your link above) - we don't implement a per-request token though, we implement a per-session token and we don't randomise the name (it is always called "sesskey") - that is one area that could be improved but doing this can easily cause usability issues for the end-user with multiple windows or use of the back/forward buttons in the browser.

Average of ratings: -

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by James McLean - Wednesday, February 25, 2015, 6:28 AM

MITM, Compromised Proxy etc are all outside the control of Moodle. If you want to prevent these - run your site 100% HTTPS and these are no longer issues. Passwords seen over a users shoulder are an issue with educating your users, again not a direct Moodle issue (though we are actually implementing two factor authentication to mitigate this).

If you have a repeatable proof of concept, lodge a bug in the tracker, mark it as a security issue, and the security people will review it. Don't post the code or details here.

Include the proof of concept code so it can be used for testing.

Average of ratings:Useful (1)

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by James McLean - Wednesday, February 25, 2015, 7:57 AM

I should qualify what I said above regarding two-factor authentication. When I say "we" I mean the institution I work for, not HQ.

Average of ratings: -

Re: Cross-Site Request Forgery (CSRF) in Moodle default pages - help

by Marina Glancy - Wednesday, February 25, 2015, 6:32 AM

Hi Vincent. Yes please, post it on tracker. Comment with the issue number here.

But so far everything you describe is a result of xss or another attack. So it would be completely different security vulnerability. For example tricking admin to load a page containing xss - how can it be possible?

Looking over the shoulder alone is not enough as well, there has to be something else involved

Average of ratings:Useful (1)

Security and privacy

Cross-Site Request Forgery (CSRF) in Moodle default pages - help