Uploaded image for project: 'ZABBIX BUGS AND ISSUES'
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-16144

Qualyscan: Critical Vulnerability ID 150003 SQL Injection

XMLWordPrintable

    • Icon: Problem report Problem report
    • Resolution: Incomplete
    • Icon: Major Major
    • None
    • 3.0.26
    • Frontend (F)
    • None

      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);

            vjaceslavs Vjaceslavs Bogdanovs
            yunongl Adrian LIN
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: