270 Security Functions of IBM DB2 10 for z/OS
11.3.3 Lessons learned
Today, many transactions that run on a DB2 subsystem originate outside of z/OS from the
internet. They are initiated by users who authenticate their identities on web-based or
distributed application servers, such as with Spiffy Computer Company.
The ability to monitor and identify remote users behind an application user ID was already
provided by DB2 9 with trusted contexts and the “allow use for” option. With distributed
identity filters, similar extended functionality and auditing is provided by both DB2 10 and
RACF.
A distributed identity filter is a RACF mapping association between a RACF user ID and one
or more distributed user identities. You can use the RACF RACMAP command to associate a
distributed user identity with a RACF user ID.
DB2 10 supports the RACF distributed identity filter. Using this function, we can identify
remote applications and we can have a better monitoring and auditing environment.
You need to look at the DB2 trusted context definition and the RACF mapping to know who is
allowed to use the trusted connection.
11.4 Considerations about SQL injection
SQL injection is yet another common vulnerability that is the result of lax input validation.
Unlike cross-site scripting vulnerabilities that are ultimately directed at your site’s visitors,
SQL injection is an attack on the site itself.
The vulnerability is present when user input is either incorrectly filtered for string literal
escape characters embedded in SQL statements or the user input is not strongly typed and
thereby unexpectedly executed. It is an instance of a more general class of vulnerabilities that
can occur whenever one programming or scripting language is embedded inside another.
SQL injection attacks are also known as SQL insertion attacks.
We can avoid most SQL injection using several techniques, such as implementing secure
coding best practices and limiting web application coding privileges, reducing debugging
information, and testing web applications regularly. We can also use a product like pureQuery,
IBM DataPower®, and so on. For more information about pureQuery, refer to 14.3, “SQL
injection and IBM Optim pureQuery Runtime” on page 340.
11.4.1 Background information
Spiffy Computer Company needs to protect itself from SQL injection attacks by enhancing the
remote dynamic SQL statement application’s security. So they review several product
solutions and methodologies.
11.4.2 Implementation scenario
You need to understand the limitations of security within an application. System security can
use security and integrity mechanisms that are not available to application programs. The
level of assurance that can be provided in system security can be much higher. If the
applications are run on the client or have fewer protection layers and firewalls than the
database, make sure to address those limitations.
Chapter 11. Remote client applications access 271
You should consider implementing the following functions:
򐂰 Input validation.
򐂰 Escaping characters.
򐂰 Encoding (input and output).
򐂰 Using prepared statements (for example, parameterized SQL queries).
򐂰 Accept numbers for a numeric comparison only.
򐂰 Do not allow special characters if they do not apply.
򐂰 Other options
Whitelists: A list of known allowed characters
Blacklists: A list of known bad characters that are never accepted
SQL injection attacks might occur when dynamic SQL statements are constructed from user
input and the input is inadequately checked. You can use several techniques to prevent or
reduce SQL injection attacks:
򐂰 Avoid dynamic SQL, whenever possible.
򐂰 Use SQLJ rather than JDBC for Java.
򐂰 Use system security techniques:
–VIEWs
Trusted connections
Column masking
Row permissions
We have mentioned methodologies that protect against SQL injection, but we also need to
discuss methodologies for detecting SQL injection. Because we cannot prevent SQL injection
in every case, we also need to detect malicious error logs.
RACF message ICH408I, shown in Example 11-22, is the message that occurs when a failed
user attempt against the RACF defined resources or policies occurs. The reason why we
need to check this message is that we can discover failed attempts by identity mapping users
that are not defined to log in to the remote DB2 application.
Example 11-22 RACF messages about logging in failure
ICH408I USER(PAOLOR5 ) GROUP(SYS1 ) NAME(P. ) 140
LOGON/JOB INITIATION - INVALID PASSWORD ENTERED AT TERMINAL TCP67028
ICH408I USER(JIMBO ) GROUP( ) NAME(??? ) 535
LOGON/JOB INITIATION - USER AT TERMINAL NOT RACF-DEFINED
IRR012I VERIFICATION FAILED. USER PROFILE NOT FOUND.
ICH408I USER(STC ) GROUP(SYS1 ) NAME(STARTED TASK ) 533
DISTRIBUTED IDENTITY IS NOT DEFINED:
X<4A>X<49>X<4D>X<42>X<4F> X<D1>X<89>X<94>X<82>X<96>X<D9>X<85>X<87>X<
89>X<A2>X<A3>X<99>X<A8>
IRR012I VERIFICATION FAILED. USER PROFILE NOT FOUND.

Get Security Functions of IBM DB2 10 for z/OS now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.