Is native IMS vulnerable to injections?

Question

As shown in this article, DB2 might be vulnerable to SQL Injections:

* Potential SQL injection if X, Y or Z host variables come from untrusted input 
STRING "INSERT INTO TBL (a,b,c) VALUES (" X "," Y "," Z ")" INTO MY-SQL.
EXEC SQL PREPARE STMT FROM :MY-SQL END-EXEC.
EXEC SQL EXECUTE STMT END-EXEC.

My question is if native IMS commands are vulnerable of this kind (or similar) injections? For instance, by imputing malicious input in the ISRT DLI command.

Answer 1

It depends on how you plan to access the IMS database.

Quoting from an IBM document.

The SQL statements that you issue through the web interface or the ISPF interface are executed as IMS application programming API in the IMS SPUFI application program in z/OS®. You can select COBOL or Java™ for the language environment to execute SQL statements.

If you use SQL, you're possibly vulnerable to SQL injection.

If you use native IMS commands, probably not. But it's still a good idea to sanitize your inputs, even for native IMS commands.

Answer 2

Yes, all SQL databases that support runtime parsing of an SQL query string are susceptible to SQL injection.

SQL injection is not a flaw in the database technology, it's a flaw in the client code you write that builds the SQL query string.

Answer 3

No, an IMS DL/I database doesn't parse the record at all. See it as an early version of a NoSQL database like Cassandra. The segment key is parsed as a binary value but you can't do injections like in a SQL database.

And depending on the skill of the programmers/IMS-admins the attack vector might be closed by limiting the range of available CRUD actions that are available for the program using the PROCOPT's of the PCB in the PSB.

Most IMS-system+DB2 use static SQL's so the statement is already prepared and not vulnerable to SQL injection attacks.

Answer 4

I’m a member of the IBM IMS team.

IMS DL/I calls are not dynamic and for that reason are not susceptible like SQL calls. There is no injection risk for CALL xxxTDLI IMS APIs. That being said, a COBOL program can open up risk by allowing input to the program to influence the SSA list or IOAREA parameters being passed to the xxxTDLI. So, secure engineering practices should be followed while programing against these interfaces.