We are considering moodle to be used as internal learning platform but before the go-live, we have some standard application security assessment, which is conducted to check the security of the application and to our surprise the assessment report shows somewhere near to 1500 instances of SQL Injection in the moodle 4.4 fresh code(we have simply downloaded the code and asked for security assessment). Anyone who has faced a similar situation? or any suggestions on how we can tackle this?
First, do not report security issues in this irresponsible way. https://www.bugcrowd.com/resources/guide/what-is-responsible-disclosure/. The the case of Moodle the links for how to report issues responsibly is give at the top of this forum: https://moodle.org/mod/forum/view.php?id=7301
However, in this case, no harm done. Whatere tool you have used appears to have just generated 1500 false-postitive. The examples you give are not SQL injection vulnerabilites. (If you paid for this report, or tool, ask for your money back.)
However, in this case, no harm done. Whatere tool you have used appears to have just generated 1500 false-postitive. The examples you give are not SQL injection vulnerabilites. (If you paid for this report, or tool, ask for your money back.)
Thanks for your reply, Tim.
First of all, really sorry for not following the standards while posting this query.
Secondly, I too feel that the issues are baseless. The real pain is this is not performed by some other vendor, instead these were reported by our internal IT team before deploying the site on an internal server. Do you think getting the name of the tool they have used to get the report would be of some help?
The issue with all of these tools is they are often misused as in this case. They can at best report a possible risk, the tool doesn't have enough context of the overall code to understand if that risk is exploitable or not. In the examples shown it looks like several of those are tests ("_test") which is code that is never executed in production so no risk there. For some of the others I'd be guessing because the call uses a variable directly in an SQL statement is why its flagged. Again if that variable could never be set by an end user, even a malicious one, such as in the case of a quiz id there is no risk. These tools are designed to give a security professional or programmer a flag to know where to start looking and assessing a risk, not to give a definitive answer.
Thanks for your inputs, Brett. I do agree with what you just said, I will provide the same explanation to my internal team.