A security concern has been found during scanning. Hope anyone can provide a solution for this. The description as below:

150003 SQL Injection
URL: https://10.76.62.72:8443/zabbix/jsrpc.php?sid=1163c88852b729a5%26type=9%26method=screen.get
%26timestamp=1557950781131%26mode=3%26groupid=0%26hostid=0%26resourcetype=23%26data%5Bhosts_selec ted%5D=false%26data%5Bfullscreen
%5D=0%26data%5Bsort%5D=name%26data%5Bsortorder%5D=ASC%26page=1
Finding # 7845826(312125993) Severity Confirmed Vulnerability - Level 5
Group SQL Injection Detection Date 15 May 2019 16:03 GMT-0400
CWE CWE-89
OWASP A1 Injection
WASC WASC-19 SQL INJECTION
CVSS Base 10 CVSS Temporal8.6
Details
Threat
SQL injection enables an attacker to modify the syntax of a SQL query in order to retrieve, corrupt or delete data. This is accomplished by manipulating query
criteria in a manner that affects the query's logic. The typical causes of this vulnerability are lack of input validation and insecure construction of the SQL query.
Queries created by concatenating strings with SQL syntax and user-supplied data are prone to this vulnerability. If any part of the string concatenation can be
modified, then the meaning of the query can be changed.
Examples:
These two lines demonstrate an insecure query that is created by appending the user-supplied data (userid):
dim strQuery as String
strQuery = "SELECT name,email FROM users WHERE userid=" + Request.QueryString("userid")
If no checks are performed against the userid parameter, then the query may be arbitrarily modified as shown in these two examples of a completed query:
SELECT name,email FROM users WHERE userid=42
SELECT name,email FROM users WHERE userid=42; SHUTDOWN WITH NOWAIT
Impact
The scope of a SQL injection exploit varies greatly. If any SQL statement can be injected into the query, then the attacker has the equivalent access of a
database administrator. This access could lead to theft of data, malicious corruption of data, or deletion of data.
Solution
SQL injection vulnerabilities can be addressed in three areas: input validation, query creation, and database security.
All input received from the Web client should be validated for correct content. If a value's type or content range is known beforehand, then stricter filters should be
applied. For example, an email address should be in a specific format and only contain characters that make it a valid address; or numeric fields like a U.S. zip
code should be limited to five digit values.
Prepared statements (sometimes referred to as parameterized statements) provide strong protection from SQL injection. Prepared statements are precompiled
SQL queries whose parameters can be modified when the query is executed. Prepared statements enforce the logic of the query and will fail if the query cannot
be compiled correctly. Programming languages that support prepared statements provide specific functions for creating queries. These functions are more secure
than string concatenation for assigning user-supplied data to a query.
Stored procedures are precompiled queries that reside in the database. Like prepared statements, they also enforce separation of query data and logic. SQL
statements that call stored procedures should not be created via string concatenation, otherwise their security benefits are negated.
SQL injection exploits can be mitigated by the use of Access Control Lists or role-based access within the database. For example, a read-only account would
prevent an attacker from modifying data, but would not prevent the user from viewing unauthorized data. Table and row-based access controls potentially
minimize the scope of a compromise, but they do not prevent exploits.
Example of a secure query created with a prepared statement:
PreparedStatement ps = "SELECT name,email FROM users WHERE userid=?"; ps.setInt(1, userid);