OpenControls Logo

STIG Viewer

STIGViewer Support

The MySQL Database Server 8.0 and associated applications, when making use of dynamic code execution, must scan input data for invalid values that may indicate a code injection attack.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-235158MYS8-00-007500SV-235158r961158_ruleCCI-001310medium
Description
With respect to database management systems, one class of threat is known as SQL Injection, or more generally, code injection. It takes advantage of the dynamic execution capabilities of various programming languages, including dialects of SQL. In such cases, the attacker deduces the manner in which SQL statements are being processed, either from inside knowledge or by observing system behavior in response to invalid inputs. When the attacker identifies scenarios where SQL queries are being assembled by application code (which may be within the database or separate from it) and executed dynamically, the attacker is then able to craft input strings that subvert the intent of the query. Potentially, the attacker can gain unauthorized access to data, including security settings, and severely corrupt or destroy the database. The principal protection against code injection is not to use dynamic execution except where it provides necessary functionality that cannot be utilized otherwise. Use strongly typed data items rather than general-purpose strings as input parameters to task-specific, pre-compiled stored procedures and functions (and triggers). When dynamic execution is necessary, ways to mitigate the risk include the following, which should be implemented both in the on-screen application and at the database level, in the stored procedures: -- Allow strings as input only when necessary. -- Rely on data typing to validate numbers, dates, etc. Do not accept invalid values. If substituting other values for them, think carefully about whether this could be subverted. -- Limit the size of input strings to what is truly necessary. -- If single quotes/apostrophes, double quotes, semicolons, equal signs, angle brackets, or square brackets will never be valid as input, reject them. -- If comment markers will never be valid as input, reject them. In SQL, these are -- or /* */ -- If HTML and XML tags, entities, comments, etc., will never be valid, reject them. -- If wildcards are present, reject them unless truly necessary. In SQL these are the underscore and the percentage sign, and the word "ESCAPE" is also a clue that wildcards are in use. -- If SQL key words, such as SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, ESCAPE, UNION, GRANT, REVOKE, DENY, MODIFY will never be valid, reject them. Use case-insensitive comparisons when searching for these. Bear in mind that some of these words, particularly Grant (as a person's name), could also be valid input. -- If there are range limits on the values that may be entered, enforce those limits. -- Institute procedures for inspection of programs for correct use of dynamic coding, by a party other than the developer. -- Conduct rigorous testing of program modules that use dynamic coding, searching for ways to subvert the intended use. -- Record the inspection and testing in the system documentation. -- Bear in mind that all this applies not only to screen input, but also to the values in an incoming message to a web service or to a stored procedure called by a software component that has not itself been hardened in these ways. Not only can the caller be subject to such vulnerabilities; it may itself be the attacker. The MySQL Firewall runs within the MySQL server and enables database administrators to permit or deny SQL statement execution based on matching against whitelists of accepted statement patterns. This hardens MySQL Server against attacks such as SQL injection or attempts to exploit applications by using them outside of their legitimate query workload characteristics.
STIGDate
Oracle MySQL 8.0 Security Technical Implementation Guide2024-09-04

Related Frameworks

1 mapping across 4 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (6) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

CFG-02Secure Baseline Configurations
1.00
CRY-01Use of Cryptographic Controls
1.00
DCH-01Data Protection
1.00
IAC-21Least Privilege
1.00
NET-12Safeguarding Data Over Open Networks
0.50
TDA-18Input Data Validation
0.50
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (11) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AU-10(1)Association of Identities
1.00
AU-10(2)Validate Binding of Information Producer Identity
1.00
CM-6Configuration Settings
1.00
IA-5(2)Public Key-based Authentication
1.00
SC-13Cryptographic Protection
1.00
SC-20Secure Name/Address Resolution Service (Authoritative Source)
1.00
SC-20(2)Data Origin and Integrity
1.00
SC-21Secure Name/Address Resolution Service (Recursive or Caching Resolver)
1.00
SC-23Session Authenticity
1.00
SC-8(2)Pre- and Post-transmission Handling
1.00

+1 more (top 10 by confidence shown)

CCI1 mapping
CCI-001310
1.00
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (1) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

PR.DS-10
1.00

Who does this work

7 NICE work roles and 7 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-235158r961158_chk)

Review MySQL Database Server 8.0 source code (stored procedures, functions, and triggers) and application source code to identify cases of dynamic code execution. Determine if the MySQL Enterprise Firewall is installed and trained to recognize normal behavior and block or alert of abnormal requests. Run the following command: SHOW GLOBAL VARIABLES LIKE 'mysql_firewall_mode'; Review firewall users and Mode. SELECT * FROM INFORMATION_SCHEMA.MYSQL_FIREWALL_USERS; If no rows are returned and no firewall allow lists are active, this is a finding. If LEARNING is returned, the firewall is building an allow list for the userhost user. If PROTECTING is returned, the firewall will only permit SQL on the allow list for the userhost user to execute. If DETECTING is returned, the firewall will write to the firewall log SQL not on the allow list for the userhost user to execute. If dynamic code execution is employed without protective measures against code injection, this is a finding.

Fix Text (F-38340r623595_fix)

Where dynamic code execution is used, modify the code to implement protections against code injection. Enable the MySQL Enterprise Firewall by running this script, which is located in the mysql home share sub directory. mysql -u root -p mysql < linux_install_firewall.sql Train the firewall for users where dynamic code injection is possible, for examples applications that allow user input. CALL mysql.sp_set_firewall_mode('fwuser@localhost', 'RECORDING'); Once the allowlist for the user/host has been captured, the firewall can be placed in PROTECTING (active blocking) or DETECTING(logging) mode. CALL mysql.sp_set_firewall_mode('fwuser@localhost', 'PROTECTING'); CALL mysql.sp_set_firewall_mode('fwuser@localhost', 'DETECTING');