When i inspect moodle site, it show some information like sesskey,sessiontimeout,themerev will it impact on security
M.cfg = {"wwwroot":"http:\/\/XYZ\/moodle","sesskey":"y9tjmPnNnX","sessiontimeout":"28800","themerev":"1705409586","slasharguments":1,"theme":"boost","iconsystemmodule":"core\/icon_system_fontawesome","jsrev":"1705409586","admin":"admin","svgicons":true,"usertimezone":"Asia\/Kolkata","contextid":2,"langrev":1705409586,"templaterev":"1705409586","developerdebug":true};var yui1ConfigFn = function(me) {if(/-skin|reset|fonts|grids|base/.test(me.name)){me.type='css';me.path=me.path.replace(/\.js/,'.css');me.path=me.path.replace(/\/yui2-skin/,'/assets/skins/sam/yui2-skin')}};
Hi Karan,
The M.cfg variable holds information that sometimes needs to be accessible by JavaScript. The "sesskey" is not the session token used to identify you (ie it is not the same token as you would find in your browser cookies). Despite the name, "sesskey" is actually a cross-site request forgery (CSRF) protection token, which helps add a layer of security when you submit forms, add/update/delete data etc, to ensure those operations only work if you have performed some action within the site (and can't be tricked into performing some operation just by clicking a link on an external website or email, for example). This could be needed by JavaScript for things like dynamically submitted forms or web service (API) requests that don't require a page (re)load.
You can find some more information about sesskey and CSRF in general in our Cross-site request forgery documentation.
I hope that helps answer your question!
Given the number of false-positive reports we get because our csrftoken is called sesskey, I wonder it would actually be worth the pain inovlved in renaming it? That might acutally be less painful than trying to educate all the careless 'security researchers' in the world who take one look at something and jump a false conclusion?!
Acutally, that might be doable following Moodle's deprecations process.
- Note, I am not suggesting that we change the name of any of Moodle's API functions like require_sesskey(), sesskey() etc. Just changing the URL/POST parameter they use. (Though we could acutally rename them, following the deprecation process, if we acutally thoght that was less confusing. Or make a new autoloaded core\xsrf_token class.)
- The things we need to change are the names or URL parameters, hidden form fields, etc.
- Obviously in core, we can just change everything directly. ('just' ... well ...). But, how to support third-party code during the transition.
- In moodleurl, we can make it so that if you set a param sesskey, it actually sets csrftoken and outputs a debugging message.
- In formslib, we can make it iso that if you create a field called sesskey, it acutally gets called csrftoken, with debugging.
- Possibly, we could also make it so that if you ask optional/required param for sesskey, it acutally gets you csrftoken, and if you ask for csrftoken, and that does not exist, but sesskey does, then it fetches that with a warning.
Not sure it is acutally worth it, but perhaps worth considering?
I agree, and I would support changing the API functions too. It's not just people looking at things like this, I've seen internal technical discussions get sidetracked in the confusion between sesskey and the actual session token.
To me it feels like the number of reports from clients/community members about the sesskey being a security issue has decreased - 8-10 years ago I think we saw this reported a lot more - these days the false reports I've seen tend to be around other things like "SQL blind injection on login form" and variations on those.
I would like to see it renamed, but like you mention I'm not completely sure it's worth the effort from HQ ... unless someone in the community does the heavy lifting?
I would like to see it renamed, but like you mention I'm not completely sure it's worth the effort from HQ ... unless someone in the community does the heavy lifting?
This happened so often that I wrote a wiki page which is now migrated to here:
https://moodledev.io/general/development/process/security/penetration-testing#the-sesskey-param-is-a-csrf-token
Ever time we get a client wanting a pen test we point them at that first
+1 for renaming it, but yeah would be a very rainy day kinda thing
https://moodledev.io/general/development/process/security/penetration-testing#the-sesskey-param-is-a-csrf-token
Ever time we get a client wanting a pen test we point them at that first
+1 for renaming it, but yeah would be a very rainy day kinda thing