Burp Suite Security report shows Issues for Moodle 3.5

Burp Suite Security report shows Issues for Moodle 3.5

by vikas k -
Number of replies: 7

Our moodle site has been tested by Security experts. 

they have reported 2 medium severity level errors

Path:  moodle.com/calendar/export.php

Issue detail

The URL in the request appears to contain a session token within the query string:

Need help on how to resolve this Security issue.

I am currently running Moodle 3.5

Regards

Vikas


Average of ratings: -
In reply to vikas k

Re: Burp security report shows Issues

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
What is the problem that has been identified with this URL, i.e. what bad thing could it cause to happen.
By the way I know very little about security or how Moodle implements it, so I am asking for the benefit for people that do.
Average of ratings: -
In reply to Marcus Green

Re: Burp security report shows Issues

by vikas k -
This is the entire text of the report:

Session Token in URL.
There are 2 instances of this issue:
/mymoodle.com/calendar/export.php
/mymoodle.com/calendar/export.php

Issue background
Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an attacker.

Issue remediation
Applications should use an alternative mechanism for transmitting session tokens, such as HTTP cookies or hidden fields in forms that are submitted using the POST method.

Vulnerability classifications
CWE-200: Information Exposure
CWE-384: Session Fixation
CWE-598: Information Exposure Through Query Strings in GET Request
Average of ratings: -
In reply to vikas k

Re: Burp security report shows Issues

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I think that's just a token to prevent XSS attacks (based on a two minute look at the code). It's the same deal as the session id that turns up in URLs of some admin activities.

It's none of the things in those vulnerability classifications.
Average of ratings: -
In reply to Howard Miller

Re: Burp security report shows Issues

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
https://moodle.org/mod/forum/discuss.php?d=268472
Average of ratings: -
In reply to Marcus Green

Re: Burp security report shows Issues

by vikas k -
Hello Marcus,

Thanks for the link. I had seen it before and replied to the Security Expert with this document. But they have kept the issue as Open. So i was looking for a better solution.

In Dan's reply [Sept 2014 ] he says
That is a really common mistake from security researchers looking at Moodle - I see a handful of these reports every year. it's partly our fault for calling that param "sesskey" - if we'd called it something else like "csrfprotect" it might avoid these reports!

Moodle 3.5 initial release date was 17 May 2018 [ nearly 4 years after].
So this issue is not considered to be serious by the Moodle Developers Team.

Was wondering if it were actually possible to replace 'sesskey' with a name like 'csrfprotect' and what would be the repercussions of the same?

Thanks for the info, Marcus and hope the security auditor accepts this as a closure.
Average of ratings: -
In reply to vikas k

Re: Burp security report shows Issues

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Sounds like you have the right attitude and a bit of "paranoia" can be helpful in the world of security.

Neither I nor Howard are primarily focussed on security but we do read the Moodle posts about it. 

With reference to changing the sesskey name, getting any changes into core Moodle can be a challenge, but that is mainly for good reasons, i.e. they are inspected and tested at length because with (c) 225 million users globally you have to be careful.

Average of ratings: -
In reply to Marcus Green

Re: Burp security report shows Issues

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators
Changing the name of "sesskey" to something else in core would be extremely time consuming, could potentially break a bunch of 3rd party plugins and provide an extremely small benefit - (potentially less false positives in automated reporting tools.)

We used to see these sort of reports in the early days from security researchers unfamiliar with Moodle (not just those automated tools) - but since then the documentation around how Moodle uses the sesskey has improved a lot, and security researchers understanding around csrf tokens like this has also improved.

I'd also guess that some of these automated tools are actually looking for parameters that contain what looks like a random key, so even by changing it from sesskey to something else would still not prevent these false positive reports.

I can't see Moodle HQ priotising time in this sort of change considering the benefits for doing this are quite low. Much better focusing their time on UX like they are for Moodle 4.0! smile
Average of ratings: Useful (1)