Best practice forum (Archived)

Blind SQL Injection Findings

Hello everyone!

We just had a security scan of our Totara environment and came up with 4 High Severity findings for Blind SQL injection. I was wondering if any of the core developers could maybe point me in the right direction or possible explain what these pages in question do in an attempt to resolve the issue.

3 out of 4 findings are related to the page found at /lib/javascript.php.

The 3 instances of using this page that came back as a blind sql injection were the following:

https://totara/lib/javascript.php/1439383669/lib/javascript-static.js
https://totara/lib/javascript.php/1439383669/totara/core/js/lib/jquery.treeview.min.js
https://totara/lib/javascript.php/1439383669/totara/core/js/icon.preview.js

The scan tool reported these as blind sql injection with the following description as to why. It had to do with appending other numbers / characters to the number portion of the URL. (Side note, is the number portion in the url a file revision number or something like that? Any explanation on what's going on there would be great!)

"Difference: Parameter manipulated from: 1439383669 to: 0+0+0+1439383669
Reasoning: The test result seems to indicate a vulnerability because it shows that values can be appended to parameter values, indicating that they were embedded in an SQL query. In this test, three (or sometimes four) requests are sent. The last is logically equal to the original, and the next-to-last is different. Any others are for control purposes. A comparison of the last two responses with the first (the last is similar to it, and the next-to-last is different) indicates that the application is vulnerable"

The 4th finding was in regards to the /user/profile.php page. You can append &lang= to the URL to switch the language of the user, however, you can also add erroneous data along with the language input like the following:

https://totara/user/profile.php?id=2&lang=en_us

Modified to:

https://totara/user/profile.php?id=2&lang=%27+%7C%7C+%27%27+%7C%7C+%27en

I'm hoping that these findings are more of a false positive, but i need some concrete evidence of this in order for us to get sign off from our security team. Can anyone here point me in the right direction or help me to explain these findings?

Permalink | Reply

Hi John,

Four false positives here.

The first 3 are in fact all one file lib/javascript.php.
This file mediates core javascript and uses slash arguments (arguments in the form you see) in order to provide optimised caching of its response.
The number that is being modified is used to control caching revisions, Totara increases this number when the user purges caches or performs an upgrade in order to ensure that cached JS is no longer used and instead now the JS is mediated again with any updated JS that may now be available.
This number is internally cleaned immediately after being retrieved. Cleaning involves casting it to an integer to ensure it is numeric only.
The noted exploits result in 0 being used as the revision.
This manipulation of that number can not be exploted in any way.

The final exploit changing the value of the lang param is also a false positive.
That parameter can be set on any page.
It is cleaned immediately after being retrived.
Cleaning involves ensuring it contains only the following characters "a-zA-Z0-9_-".
After cleaning it gets checked against the sites known list of languages and only gets used if it is exists as a known language.
There is no way to exploit this parameter.

I see Simon has responded to your help desk report as well, just sharing this here for the benefit of the community.

Kind regards
Sam

Permalink | Show parent | Reply