Best practice forum (Archived)

Blind SQL Injection Findings

 
Sam Hemelryk
Re: Blind SQL Injection Findings
by Sam Hemelryk - Tuesday, 20 October 2015, 2:15 PM
Group Totara

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