Comme indiqué dans cet article , DB2 peut être vulnérable aux injections SQL:
* 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.
Ma question est de savoir si les commandes IMS natives sont vulnérables aux injections de ce type (ou similaires)? Par exemple, en imputant une entrée malveillante dans la commande ISRT DLI .
4 Réponses :
Oui, toutes les bases de données SQL qui prennent en charge l'analyse d'exécution d'une chaîne de requête SQL sont susceptibles d'être injectées SQL.
L'injection SQL n'est pas une faille dans la technologie de base de données, c'est une faille dans le code client que vous écrivez qui construit la chaîne de requête SQL.
Cela dépend de la manière dont vous prévoyez d'accéder à la base de données IMS.
Citation d'un document IBM .
Les instructions SQL que vous émettez via l'interface Web ou l'interface ISPF sont exécutées en tant qu'API de programmation d'application IMS dans le programme d'application IMS SPUFI dans z / OS®. Vous pouvez sélectionner COBOL ou Java ™ pour l'environnement du langage pour exécuter les instructions SQL.
Si vous utilisez SQL, vous êtes probablement vulnérable à l'injection SQL.
Si vous utilisez des commandes IMS natives, probablement pas. Mais c'est toujours une bonne idée de nettoyer vos entrées, même pour les commandes IMS natives.
Merci! Cependant, je recherche un exemple spécifique d'IMS natif (j'ai édité la question pour être plus précis).
Vous n'avez pas spécifié de langage de codage, je ne suis donc pas sûr de l'exemple spécifique que vous recherchez. Voici la liste des commandes DLI pour accéder à une base de données IMS. ibm.com/support/knowledgecenter/SSEPH2_15.1.0/...
Oui, je veux dire avec une commande ISRT, par exemple. Cela serait-il possible?
En général non pour les commandes IMS natives. Vous pouvez configurer un système dans lequel les utilisateurs saisissent tous les paramètres IMS, auquel cas ils peuvent faire tout ce qu'ils veulent.
Je suis membre de l'équipe IBM IMS.
Les appels IMS DL / I ne sont pas dynamiques et, pour cette raison, ne sont pas sensibles comme les appels SQL. Il n'y a aucun risque d'injection pour les API IMS CALL xxxTDLI. Cela étant dit, un programme COBOL peut créer des risques en permettant à l'entrée du programme d'influencer la liste SSA ou les paramètres IOAREA transmis au xxxTDLI. Ainsi, des pratiques d'ingénierie sécurisées doivent être suivies lors de la programmation sur ces interfaces.
Non, une base de données IMS DL / I n'analyse pas du tout l'enregistrement. Voyez-le comme une première version d'une base de données NoSQL comme Cassandra. La clé de segment est analysée comme une valeur binaire mais vous ne pouvez pas faire d'injections comme dans une base de données SQL.
Et selon la compétence des programmeurs / administrateurs IMS, le vecteur d'attaque pourrait être fermé en limitant la gamme des actions CRUD disponibles qui sont disponibles pour le programme en utilisant les PROCOPT du PCB dans le PSB.
La plupart des systèmes IMS + DB2 utilisent des SQL statiques, donc l'instruction est déjà préparée et n'est pas vulnérable aux attaques par injection SQL.
Essayer d'exécuter une entrée utilisateur non approuvée rend votre code vulnérable à l'injection SQL et à toutes sortes d'autres choses désagréables; cela n'a rien à voir avec IMS ou DB2.