Automated security scanning tools are notorious for reporting false positive results and are typically not designed to run by users with no development knowledge - If you do not have any 3rd party plugins installed on your site you can probably ignore the results.
If you want to investigate further you could contract a Moodle Partner to help you review the results of the scan.
Moodle implements a wide range of things to prevent SQL injection - for more information on Moodle security please see:
If you are using 3rd party plugins or have added your own custom code to your site - it is possible that your extra code does have vulnerabilities - you may need to work with the developer responsible for writing the custom/3rd party code to check.
I'm not sure which scanning tool you used but if you search the forums here for other people using the same tool you will likely find other useful related posts.
Thank you for your help, our security team is using IBM Security AppScan Standard 126.96.36.199 iFix002 scanning tool and they didn't accept ignore the results also they deny publish the site before fixing below issues:
Issues Sorted by Issue Type
Blind SQL Injection 22
Cross-Site Scripting 2
Unencrypted Login Request 2
Authentication Bypass Using HTTP Verb Tampering 3
Cross-Site Request Forgery 24
Directory Listing 2
Link Injection (facilitates Cross-Site Request Forgery) 2
Any "Security team" with experience will know that IBM appscan is a tool that often reports false positives.
If your Security team doesn't have the ability or knowledge that allows them to interpret the results of the report and verify that the issues are not valid then you should either:
1) Contract a Moodle partner to help you write a report that your security team will accept (Moodle HQ doesn't provide this service for free).
2) stop trying to host the site yourself and ask a Moodle Partner to host your site for you.
You could also point your security team at the wide range of organisations who use Moodle and who have already performed much deeper level security audits than your security team could by just running a tool like appscan.
Think there are a couple that you, as server admin, could take care of right now .... assuming apache.
This one: Directory Listing 2 ... if you knew the directories, just put a blank (contains nothing) index.html file in those two directories. (or whatever is the default page as defined by your web server (assuming apache and in linux, that would be index.html or index.php)
OR check your web server config (assuming apache) for setting that are allowing directory listing:
This one (Unencrypted Login Request 2) you are going to have to ask the scanning folks to provide some more info ... nothing stops a user from using http://yoursite/ ... *IF* that is the issue.
To negate that, check into setting up a re-write rule that takes any http:// request and re-writes it to https://
The others need further investigation/'defense' (responsible reporting)
While hiring some security expert might still be needed, nothing replaces the OP's knowledge of their own server setup.
'spirit of sharing', Ken
Pardon the 'piggy back', but needed something to scan a old Moodle site.
Mind sharing what you used for scanning? Maybe someone has run the same and can verify ... since I am in need of something that scan's, if I can run it, will investigate for ya (my own servers, of course).
BTW, Dan is correct .... Moodle coders are very concerned about security .... and many scanners do hit on what it thinks is a security issue (false positive) but is not. What does/do your DB server logs or web service logs show? A scanner pointed at a Moodle can't really hide queries. Would be interesting to see some of those clips.
Thanks, in advance, Ken
Don't share details of possible security issues here. (And Ken, please don't encourage people to do so, even if we expect them to be invalid.)
The correct way to report such issues is described on https://docs.moodle.org/dev/Moodle_security_procedures.