Qu'est-ce que Robert C. Martin entend par SQL inutile? [fermé]


45

Je lis / regarde beaucoup de contenu de Robert C. Martin. Je l'ai rencontré en train de dire que SQL n'était pas nécessaire à cause des disques SSD. Lorsque je recherche d'autres sources pour sauvegarder cela, je reçois une série d'articles aléatoires décrivant la différence de performances SQL entre les disques durs et les disques SSD (ce qui est lié mais pas ce que j'essaie de rechercher).

En fin de compte, je ne comprends pas à quoi il veut en venir. Est-il en train de dire de remplacer SQL par les technologies No-SQL? Est-il en train de dire de stocker des données dans des fichiers dans un système de fichiers? Ou veut-il simplement que les gens arrêtent d'utiliser SQL / Relational Databases en raison d'attaques SQLi? Je crains de ne pas comprendre ce qu'il essaie de dire.

Je vais fournir quelques liens ici pour que vous puissiez lire directement dans son esprit:

  1. Tables Bobby
  2. Conférence sur l'architecture propre

Premièrement, il déclare que SQL devrait être entièrement supprimé du système.

La solution. La seule solution. C’est éliminer complètement le code SQL du système. S'il n'y a pas de moteur SQL, il ne peut y avoir d'attaques SQLi.

Et bien qu'il parle de remplacer SQL par une API, je ne pense pas qu'il veuille dire mettre SQL derrière une API à cause de cette citation précédente et de ce qu'il a dit plus tôt dans l'article.

Les frameworks ne traitent pas le problème; ...

Note latérale: En disant SQL, je suis presque certain que Robert veut dire la plupart des bases de données relationnelles. Peut-être pas tout sauf la plupart. Dans tous les cas, la plupart des gens utilisent quand même SQL. alors...

Si SQL n'est pas utilisé pour conserver des données, que devons-nous utiliser?

Avant de répondre à cela, je devrais également noter. Robert souligne que les disques SSD devraient changer les outils que nous utilisons pour conserver les données. La réponse de Søren D. Ptæus le souligne.

Je dois également répondre au groupe "mais intégrité des données". Après quelques recherches, Robert recommande d' utiliser des bases de données transactionnelles telles que datomic . Puis CRUD se transforme en CR (créer et lire) et les transactions SQL disparaissent complètement. L'intégrité des données est bien sûr importante.

Je ne peux pas trouver une question qui englobe tout cela. Je suppose que je cherche des alternatives qui correspondent aux directives de Robert. Datomic en est un, mais est-ce cela? Quelles autres options correspondent à ces directives? Et fonctionnent-ils réellement mieux avec les disques SSD?


5
@ christo8989 - "Qu'est-ce qu'il veut dire par remplacer SQL par une API?". Je l’interprète comme signifiant que vous n’avez pas de langage de requête textuel (qui est transmis à un moteur SQL) dans l’ensemble de votre base de code. Vous masquez cela derrière une API qui expose uniquement des mécanismes sûrs pour décrire les requêtes. En interne à l'API, quelque chose doit générer des commandes pour le moteur SQL, mais il s'agit d'une surface plus petite dans laquelle vous pouvez imposer l'utilisation de la liaison de paramètres, etc., contrôler qui effectue les modifications, etc.
andrew

42
Mais, mais, mais ... SQL est une API. C'est l'API d'un SGBDR. Il se trouve que c'est une API très puissante qui peut être facilement utilisée à mauvais escient.
Bart van Ingen Schenau

25
Si vous créez une API DB qui ne dispose pas d' une interface textuelle, tôt ou tard , un pauvre programmeur d' écrire du code qui ressemble à ceci: eval(request.GET["table_name"] + ".get(pk=" + request.GET["pk"] + ")")). Ce n'est pas SQL qui est vraiment en faute, mais des programmeurs pauvres et ignorants.
Lie Ryan

6
@ JimmyJames SQL est un langage oui, mais cela ne veut pas dire que ce n'est pas une API. SQL est un langage qui fournit une API pour accéder à un stockage sous-jacent.
Cubique

5
@nocomprende SQL a toujours été conçu pour être utilisé avec des applications. Cela aurait été pratiquement inutile sinon. Le but était toujours de donner aux applications un moyen de stocker et de récupérer des données sans se gêner avec des formats personnalisés étranges ni même de se préoccuper énormément de la manière dont les données sont stockées.
Cubique

Réponses:


74

Bob Martin exagère clairement pour clarifier son propos. Mais quel est son point?

Veut-il simplement que les gens arrêtent d'utiliser SQL / Bases de données relationnelles à cause d'attaques SQLi?

À ce que je sache, dans cet article de blog (votre premier lien), Martin tente de convaincre les gens d'arrêter d'utiliser SQL, mais pas les bases de données relationnelles. Ce sont deux choses différentes .

SQL est un langage extrêmement puissant et standardisé dans une certaine mesure. Il permet de créer des requêtes et des commandes complexes de manière très compacte, de manière lisible, compréhensible et facile à apprendre. Il ne dépend pas d'un autre langage de programmation, il est donc utilisable par la plupart des programmeurs d'applications, qu'ils préfèrent Java, C, C ++, C #, Python, Ruby, JavaScript, Basique, Go, Perl, PHP ou autre chose.

Cependant, ce pouvoir a un coût : écrire des requêtes / commandes SQL sécurisées est plus difficile que d’écrire des requêtes / commandes non sécurisées. Une API sécurisée devrait faciliter la création de requêtes sécurisées "par défaut". Les personnes potentiellement dangereuses devraient avoir besoin de plus d'efforts mentaux ou du moins de dactylographie. C’est pourquoi, à mon humble avis, Martin s’oppose à SQL sous sa forme actuelle.

Le problème n'est pas nouveau et il existe des API plus sûres que le SQL standard pour accéder à une base de données relationnelle. Par exemple, tous les mappeurs OR que je connais essaient de fournir une telle API (bien qu’ils soient généralement conçus pour d’autres objectifs principaux). Les variantes SQL statiques rendent difficile la création de requêtes dynamiques avec des données d'entrée non authentifiées (et il ne s'agit pas d'une nouvelle invention: le SQL incorporé, qui utilise souvent du SQL statique, date d'environ 30 ans).

Malheureusement, je ne connais aucune API aussi souple, standardisée, mature, indépendante du langage et aussi puissante que SQL, en particulier le SQL dynamique. C'est pourquoi j'ai des doutes sur la suggestion de Martin de "ne pas utiliser SQL" comme moyen réaliste de résoudre les problèmes mentionnés. Alors lisez son article comme une pensée allant dans la bonne direction, et non comme une "pratique exemplaire" que vous pourrez suivre aveuglément à partir de demain.


2
Au moins, nous pouvons éviter de l’utiliser pour toute opération d’écriture, généralement avec ce que fournissent les éléments ORM. Pour interroger la base de données, vous pouvez déjà faire beaucoup de choses sans écrire votre propre SQL. De nos jours, seule l'utilisation "avancée" des capacités de la base de données devrait nécessiter l'écriture de code SQL ou l'utilisation d'un type de données complexe (graphique, données géographiques, récursif).
Walfrat

7
Martin fait spécifiquement valoir que l’API à utiliser ne devrait pas être aussi puissant que SQL; Son argument selon lequel la puissance de SQL est le problème, pas une fonctionnalité. L'API pour laquelle il plaide devrait être spécifique à l'application et être aussi flexible et puissant que l'application en a absolument besoin, pas plus. Il discute spécifiquement contre l’invention d’un autre langage de requête basé sur des chaînes.
Cubique

3
@Cubic: toute solution aux problèmes mentionnés par Martin doit probablement être moins puissante ou moins facile à utiliser que SQL - c'est leur bénédiction et leur malédiction.
Doc Brown

1
@Barmar: SQL est du plus haut niveau possible, et Bob affirme qu'il est manifestement dangereux.
Robert Harvey

3
@ christo8989: Je ne pense pas que ce soit logique d'essayer de rédiger une réponse en réponse à tout ce que Martin a écrit ou dit dans sa carrière. Ma réponse était l'une des questions posées dans votre titre, expliquant principalement comment l'interprétation du blog dans le premier lien que vous avez donné devrait être interprétée.
Doc Brown

57

L’opinion de Bob Martin n’est que cela; l'opinion d'un homme.

Un programmeur est censé comprendre le système qu’il écrit assez bien pour prendre des mesures raisonnables pour assurer sa sécurité et ses performances. Cela signifie que si vous parlez à une base de données SQL, vous faites ce que le site Web de Bobby Tables dit: vous désinfectez vos données d'entrée. Cela signifie que vous placez votre base de données SQL sur une machine offrant des performances suffisantes. Il existe des moyens très connus et bien compris de faire ces choses, et bien qu'ils ne garantissent pas une sécurité absolue ni des performances optimales, rien d'autre ne le fait.

L'affirmation selon laquelle nous n'avons plus besoin de SQL, car nous disposons maintenant de disques SSD, est simplement spécieuse. SQL n'a pas été inventé car les disques durs à grande vitesse n'existaient pas encore; il a été inventé parce que nous avions besoin d'un moyen standard de l'industrie pour exprimer les concepts de récupération de données. Outre la rapidité et la sécurité, les systèmes de bases de données relationnelles présentent de nombreuses autres qualités qui les rendent idéales pour les opérations commerciales; en particulier, ACID . L'intégrité des données est au moins aussi importante que la rapidité ou la sécurité. Si vous ne l'avez pas encore, à quoi sert-il de sécuriser les mauvaises données ou de les récupérer le plus rapidement possible?

Avant de prendre l'hystérie d'un homme comme évangile, je vous suggère d'en apprendre davantage sur la sécurité et les performances des applications et des systèmes, à leur manière, et non en lisant des articles Internet aléatoires. La sécurité, les performances et la conception de systèmes robustes vont bien au-delà de la simple "éviter cette technologie".

Nous n'interdisons pas les couteaux de cuisine car quelques personnes malchanceuses réussissent à se couper les doigts par accident.


16
Je n'interprète pas les articles de Martin comme préconisant l'abandon des SGBDR, mais plutôt d'utiliser d'autres moyens d'interagir avec eux, par exemple LINQ-to-SQL ou l'API JPA Criteria, plutôt que d'encoder ou de manipuler directement des chaînes SQL dans notre code source.
Jules

27
Donc, nous ne devrions pas suivre aveuglément ce qu'il dit ... mais que dit-il ?
TRiG

33
Une des choses que je n'aime pas vraiment dans la communauté, c'est que dès que vous posez une question sur quelque chose comme Clean Code / Oncle Bob , vous dites que les gens vous disent comment faire autrement . "Comment peindre comme van Gogh?" - "van Gogh avait tort, tu devrais peindre comme Picasso à la place".
R. Schmitz

21
La désinfection des données d'entrée pour éviter les attaques par injection devrait être l'option de sauvegarde après l'utilisation de méthodes paramétrées pour séparer le code de l'entrée.
Monstre à cliquet

17
Toute la technologie est condamnée et essentiellement défectueuse. Ce n'est qu'une question de temps. En attendant, nous avons des tâches à faire, avec nos technologies défectueuses et vouées à l'échec.

15

Qu'est-ce qu'il dit réellement?

Est-il en train de dire de remplacer SQL par les technologies No-SQL?

TL; DR: oui (en quelque sorte)

Dans une conversation plus récente que celle à laquelle vous vous êtes lié, il a déclaré: "La base de données est un détail. Pourquoi avons-nous des bases de données?" .

Il affirme que la base de données a été créée pour faciliter l'accès aux données à partir de disques en rotation, mais qu'à l'avenir, "[...] il n'y aura pas de disques" grâce à la nouvelle technologie et à ce qu'il appelle "une mémoire vive persistante" et qu'il sera plus facile de stocker des données en utilisant les structures utilisées par les programmeurs, telles que les tables de hachage ou les arbres.

Il poursuit en prédisant que les bases de données relationnelles dans un ensemble vont en grande partie disparaître en raison de leur nouvelle concurrence:

Si j'étais Oracle, j'aurais très peur parce que la raison de mon existence est en train de s'évaporer sous moi. [...] La raison de l'existence de la base de données est en train de disparaître.

Il y aura probablement des tables relationnelles qui survivront, mais maintenant, il y a une concurrence saine .

Donc non, pour lui, il ne s'agit pas uniquement d'injection SQL, même s'il est d'avis que SQL est fondamentalement défectueux à cet égard .


Note de l'auteur:

Les déclarations contenues dans ce message ne sont que des citations pour comprendre le point de vue de Robert C. Martin sur ce sujet et ne représentent pas l'opinion de l'auteur. Pour un point de vue plus différencié, voir la réponse de Robert Harvey .


2
La «RAM persistante» ne concerne apparemment que l'utilisation de bases de données pour la sérialisation de l'état actuel de l'application sans aucun égard pour la compatibilité ascendante ou descendante. Bien sûr, certaines bases de données sont utilisées de cette manière, mais pas toutes (je réalise que c'est Martin qui le dit, pas vous).
Cubique

7
Donc, Martin dit en fait que le seul point des bases de données est l’abstraction sur un stockage lent? Sensationnel. Cela confirme la réponse de Robert Harvey: son opinion doit être prise avec un énorme grain de sel. Par exemple, ce point de vue ne parvient pas à considérer que la valeur d'une base de données conserve un modèle de données cohérent et persistant. Son idée des structures de données en «RAM persistante» (SSD?) Est à la fois lente et ouvre la voie à une perte de données. Même les bases de données NoSQL utilisent souvent des structures de journalisation et de données immuables pour mettre à jour des enregistrements persistants en toute sécurité.
amon

3
@ amon Oui, Robert Harvey a raison d'offrir un point de vue plus différencié. Mais depuis que le PO a demandé spécifiquement ce que Robert C. Martin essayait de dire, j'ai retranscrit une partie de son discours "plus récent".
Søren D. Ptæus

3
@amon - voir la première phrase de la réponse de Doc Brown ci-dessus. Martin fait souvent des déclarations qui sont des exagérations massives de son propos afin de le faire passer. Il ne signifie pas que toutes les opérations de base de données peuvent être remplacées par des magasins en mémoire, pas plus qu'il ne signifie simplement que le fait de disposer d'un composant de votre application qui touche SQL sous une forme quelconque constitue un risque de sécurité suffisamment important pour qu'il soit évité dans tous les cas. cas, pourtant sur le visage de ses mots, il peut être interprété comme disant cela. Mais tout ce qu’il essaie de faire, c’est que tout le monde s’arrête et réfléchisse: est-ce que SQL / RDBMS convient à mon application?
Jules

12
@Jules je comprends qu'il exagère souvent. Mais compte tenu de sa portée et de sa réputation, il est peu utile que "Oncle Bob" ne précise pas quand il exagère et où il dit réellement ce qu'il veut dire. S'il est supposé enseigner quelque chose, il n'est pas faisable de doubler et de réinterpréter tout ce qu'il dit jusqu'à ce que cela ait du sens , surtout qu'il ne réfléchit pas et ne critique pas ses idées lui-même. À un moment donné, il est plus facile de dire «ne l'écoutez pas», ou même: oncle Bob considéré comme nuisible .
amon

11

SQL est un détail. La connaissance d'un détail ne devrait pas se propager.

Comme SQL est utilisé dans de plus en plus d'endroits dans votre code, votre code en devient de plus en plus dépendant.

Au fur et à mesure que vous apprenez de plus en plus d’astuces SQL, vous résolvez de plus en plus de problèmes à l’aide de SQL. Cela signifie que le passage à une autre API pour persister implique plus que la simple traduction. Vous devez résoudre des problèmes que vous n'aviez pas compris.

Vous rencontrez cette même basculement entre les bases de données. L'un d'eux propose la fonctionnalité 5 fantaisie whizzbang, vous ne l'utilisez donc que dans un certain nombre d'endroits pour découvrir que la fonctionnalité 5 fantaisie de whizzbang est exclusive. Vous avez maintenant un problème de licence qui va coûter très cher. Vous avez donc beaucoup de travail à creuser partout où vous avez utilisé la fonctionnalité 5 et à résoudre le problème vous-même, pour découvrir plus tard que vous utilisez également la fonctionnalité whizzbang 3.

Une des choses qui rend Java si portable est que certaines fonctionnalités du processeur ne sont tout simplement pas disponibles. S'ils étaient disponibles, je les utiliserais. Et tout à coup, il y a des processeurs sur lesquels mon code Java ne fonctionnera pas car ils ne possèdent pas ces fonctionnalités. C'est la même chose avec les fonctionnalités de base de données.

C’est trop facile de sacrifier son indépendance sans s’en rendre compte. SQL est un choix pas une donnée. Si vous décidez d'utiliser SQL, placez-le à un endroit. Faites-le d'une manière qui peut être défaite.

Le fait que SQL pose des problèmes de sécurité et que nous passions à des modèles de mémoire persistante ne signifie pas que SQL est condamné. Cela fait bien comprendre que c'est un choix. Si vous voulez conserver le droit de faire ce choix, vous devez faire le travail.


Il convient de noter que le mouvement de la base de données des années 80 et de l’oncle Bob a une histoire plutôt désagréable. Il a eu tous ses problèmes résolus avec un système de fichiers à plat lorsque la direction a forcé un administrateur de base de données à entrer dans sa vie. Cet événement l'a poussé dans sa carrière de consultant. (Il raconte cette histoire dans l'un de ses premiers livres épurés, oubliez lequel) Il sait comment résoudre les problèmes sans DB et a peu de patience pour ceux qui agissent comme si les utiliser était une donnée.

Il raconte également comment reporter l’ajout d’une base de données à une application jusqu’à la dernière minute, lorsqu'un client l’a demandé, et l’a ajouté en une journée, en tant que fonctionnalité facultative. À mon avis, il voit la façon dont la plupart d'entre nous utilisons DB comme une dépendance. Il essaie de nous montrer comment éliminer l'habitude.


1
Gosh, Einstein, bien sûr.

1
Ah, je ne savais pas qu'Einstein connaissait Bob. Ou que Bob était Dieu. Bien que cela puisse paraître, il a tout pour plaire.
candied_orange

9
@nocomprende vous vivez sur un régime constant d'affiches de motivation?
candied_orange

2
Mais Bob est Dieu. Pour certains au moins.
Peter Mortensen

3
Je refuse de croire que Dieu est si doué pour parler en public.
candied_orange

5

La citation de votre première citation est (souligné par moi),

La solution. La seule solution. C’est éliminer complètement le SQL du système . S'il n'y a pas de moteur SQL, il ne peut y avoir d'attaques SQLi.

Qu'est-ce qui remplacerait SQL? Une API bien sûr! Et PAS une API qui utilise un langage textuel. À la place, une API qui utilise un ensemble approprié de structures de données et d’appels de fonction pour accéder aux données nécessaires.

Ce discours est contre le fait de laisser les programmeurs d’applications utiliser SQL.

Le correctif suggéré est de les laisser utiliser une API à la place: ce qui n'est pas du SQL et ne permet pas l'injection.

OMI, des exemples de telles API peuvent inclure:

  • http://bobby-tables.com/csharp suggère aux programmeurs C # d'utiliser l'API ADO.NET.

    Ce n’est pas un exemple parfait, car ADO.NET est une API large ou profonde (c’est-à-dire puissante ou polyvalente), qui permet également à ses utilisateurs de saisir du SQL brut (ou brut).

  • Certains développeurs SQL ou administrateurs de bases de données suggèrent qu'une base de données soit configurée de telle sorte qu'elle n'autorise l'accès que via des procédures stockées ( rédigées de manière experte) et que les développeurs d'applications ne soient pas autorisés à écrire leurs propres requêtes SQL (dangereuses).

  • Un autre moyen "d'éliminer le code SQL du système" consiste à placer la base de données (qui expose le code SQL) sur un autre système, accessible via une API REST ou similaire.

Ainsi, IMO, la solution globale ou les systèmes peuvent toujours utiliser une base de données (d’autant plus qu’un moteur de base de données implémente des propriétés ACID utiles et qu’il s’adapte bien, etc. spécifique à une application).

Les exigences du client sont satisfaites si l'API SQL de la base de données est cachée des développeurs d'applications, derrière une autre API (par exemple, ADO, peut-être un ORM, un service Web, etc.).

Plus généralement, je suppose que cela signifie avoir un DAL spécifique à l'application (une "couche d'accès aux données" ou "couche d'abstraction de base de données"). Un DAL isole l'application des détails de comment et où les données sont stockées et / ou récupérées. Le DAL peut ou non être implémenté à l'aide d'une base de données SQL.


J'ai travaillé sur un produit qui faisait exactement cela il y a 30 ans. De plus, la base de données sous-jacente ne prenait même pas (encore) en charge SQL. Et, l'ensemble des tables liées était stocké dans (attendez ...) dans une base de données. Le gars qui a proposé ça était vraiment intelligent. Ce n'est plus un programmeur.

J'aime cette réponse mais je pense qu'il ne le dit peut-être pas. Il a également déclaré: "Les frameworks ne gèrent pas le problème ...". D'après votre réponse, il semble que vous disiez qu'utiliser Linq-to-Sql est correct, mais n'est-ce pas un framework qui gère le problème?
christo8989

@ christo8989 Je ne sais pas. Il cite Hibernate comme exemple de cadre qui ne gèrera pas le problème. Et effectivement, OWASP a déclaré : "Hibernate n'accorde pas l'immunité à SQL Injection, on peut mal utiliser l'API à sa guise. HQL (sous-ensemble de Hibernates de SQL) n'a rien de spécial qui le rend plus ou moins susceptible." Alors que certaines des API que j'ai mentionnées seraient de meilleurs isolants, sans exposer SQL du tout. Hibernate est peut-être quelque chose que vous pourriez utiliser pour mettre en œuvre un DAL (mais n'est pas en soi un DAL entièrement isolant).
ChrisW

1
@ christo8989 augustl.com/blog/2016/… suggère que Datomic soit (simplement) un autre wrapper / layer autour d'une base de données (éventuellement SQL) - "Datomic n'écrit pas directement dans le système de fichiers. Vous pouvez plutôt utiliser un nombre. de différentes bases de données en tant que système de stockage pour Datomic: toute base de données JDBC SQL, etc. "
ChrisW

Il convient de noter que la solution pour éviter l'injection SQL dans ADO.NET n'est pas si compliquée: utilisez des espaces réservés dans SQL, utilisez des paramètres dans la commande et définissez la valeur de ces paramètres.
Zev Spitz

3

Tout le monde semble répondre à cette question du point de vue de la sécurité ou avec une optique SQL.

J'ai assisté à une conférence de Robert Martin dans laquelle il raconte qu'en tant que programmeurs, nous utilisons différentes structures de données optimales pour nos programmes spécifiques. Ainsi, plutôt que de stocker universellement toutes les données dans une structure tabulaire, nous devrions stocker nos données dans des tables de hachage, des arborescences, etc. afin que nous puissions récupérer les données et accéder directement au programme.

J’ai interprété son message comme une simple affirmation: nous devrions rejeter un instant nos hypothèses sur le stockage persistant pour envisager d’autres possibilités que le vieux format tabulaire SQL. Le SSD est une solution candidate, mais pas la seule.


Que pourrait-il penser de la lecture / écriture simultanée des données par plusieurs utilisateurs?
ChrisW

1
@ChrisW Je ne pense pas qu'il s'agisse d'une question de mise en œuvre, mais plutôt d'une idée générale de trouver un moyen d'améliorer le stockage persistant des données.
Keenan

@ChrisW Il parle également de bases de données transactionnelles. Mettre la technologie de contrôle de source comme outil de persistance. En cela, vous créez et lisez uniquement ce qui est beaucoup plus convivial que les transactions et les mises à jour.
christo8989

@ Keenan Donc, il n'offre pas vraiment de solution via la mise en œuvre. Il vient de dire, pensez à ce qui pourrait être?
christo8989

1
@ christo8989 Je ne sais pas s'il a personnellement dirigé le développement de solutions potentielles au problème de stockage persistant en informatique. Cela n'entre pas dans le cadre de la question du PO. Uncle Bob est tout au sujet de l'architecture de plug-in. La norme actuelle du secteur en matière de développement d’applications est étroitement liée à une base de données et à la construction de l’application autour de celle-ci. L’application dépend de la base de données, alors que la base de données doit dépendre de l’application. Oncle Bob propose plutôt que "la base de données est un détail" et devrait être découplée et remplaçable.
Keenan

2

En fait, il ne doit pas utiliser les bases de données et SQL - de manière assez explicite. La première référence est une question bien connue, la deuxième référence sonnera comme un coup de gueule. Bien que, je l’interprète comme une bonne raison d’utiliser des bases de données et de ne pas utiliser SQL. De mon point de vue, ce n'est même pas un conseil raisonnable.

Malheureusement, l'exemple qu'il utilise est un exemple bien connu avec une solution bien connue qu'il souligne ensuite. Cela se produit généralement lorsqu'un programmeur ne réalise pas ce qu'il fait. Par exemple, construire des chaînes contenant du SQL comme:

    my $sql="select a from b where a=$ui_val;";
    prepare($sql)
    execute($sql)

par opposition à

    my $sql="select a from b where a=?;";
    prepare($sql)
    execute($sql,$ui_val);

C'est un exemple comme DBI perl pour le code ruby ​​on rails. Le code de rails qu'il fournit est facile à confondre entre le sûr et le non sécurisé. Comme beaucoup d'ORM, cache le SQL sous-jacent et vous avez souvent affaire à une interface qui construit et exécute le SQL pour vous. Cela ne ressemble-t-il pas à ce qu'une API ferait pour vous?

Mon interprétation de la première référence est qu'il suggère de remplacer un problème bien connu pour lequel une solution est bien connue.

Il est également regrettable qu’il ne mentionne pas que, si cela est fait correctement, le code sera plus facile à écrire et plus lisible, bien que, s’il est bien fait, il sera peut-être plus difficile à écrire et moins lisible. De plus, il ne mentionne pas que SQL est vraiment très facile à lire et fait ce que vous attendez généralement de lui.

Il est partiellement correct, nous aurons finalement une mémoire infiniment grande et rapide et un processeur infiniment rapide. Jusqu'à ce que nous nous échappions de la physique actuelle qui contraint l'informatique, il n'a pas raison.

Oui, les disques en rotation appartiennent au passé et nous utilisons maintenant des disques SSD. Les disques fonctionnent avec environ 10 millisecondes par transfert de données, les disques SSD avec un temps d'accès aux données d'environ 0,5 millisecondes (500 microsecondes). La RAM est de l’ordre de 100 nanosecondes, les processeurs fonctionnent à une centaine de secondes. C'est pourquoi nous avons besoin de bases de données. Les bases de données gèrent le transfert de données entre des disques en rotation ou des disques SSD dotés de la mémoire principale. L'avènement des disques SSD n'a pas éliminé le besoin de bases de données.


4
"STOP USE SQL" (cité dans le premier lien) ressemble beaucoup à ce qu'il dit de ne pas utiliser SQL, à ma connaissance.
Doc Brown

6
C'est un problème d'ordre des mots. En réalité, il s’agissait à l’origine d’un télégramme: USING SQL STOP

6
@nocomprende Vous dites donc qu'il est victime d'une situation de concurrence? Eh bien, oups. Il aurait pu éviter cela en utilisant des transactions SQL.
Konrad Rudolph

Peut-être que c'est un très court mélange de Visual Basic et de Fortran. Où tout cela se terminera-t-il?

1
@ KonradRudolph: Eh bien, je pense que nous serions d'accord pour dire que pratiquement personne n'utilisera TSX directement de l'assemblage. Il y aura des abstractions de niveau supérieur. Ces transactions abstraites seront-elles des transactions SQL? Je crois que non. En tant que langage interprété, SQL entraîne une surcharge de performances. Peu importait vraiment lorsque vous accédiez à des données sur la rotation de disques durs. Il est toutefois inabordable lors de l'accès aux données dans la RAM.
MSalters

2

Répondre

veut-il simplement que les gens arrêtent d'utiliser SQL / Bases de données relationnelles à cause d'attaques SQLi?

L'article de 'Bobby Tables' semble suggérer que ceci, en soi, est une raison de ne pas utiliser SQL:

La solution. La seule solution. C’est éliminer complètement le code SQL du système. S'il n'y a pas de moteur SQL, il ne peut y avoir d'attaques SQLi.

Il pourrait avoir d'autres raisons dont il discute ailleurs. Je ne saurais pas parce que je ne lis pas beaucoup de choses sur lui.

Digression

Cette partie n’est pas vraiment une réponse, mais je pense que la question de la valeur de SQL est beaucoup plus intéressante (tout comme d’autres, apparemment.)

J'ai beaucoup d'expérience avec SQL et je pense bien comprendre ses forces et ses faiblesses. Mon sentiment personnel est qu’il a été surexploité et abusé, mais que l’idée que nous ne devrions jamais l’utiliser est un peu ridicule. L'idée qu'il faut choisir 'SQL toujours' ou 'SQL jamais' est une fausse dichotomie.

En ce qui concerne l'injection SQL comme argument pour ne pas utiliser SQL, c'est risible. C'est un problème bien compris avec une solution assez simple. Le problème avec cet argument est que SQLi n'est pas la seule vulnérabilité existante. Si vous pensez que l'utilisation des API JSON vous sécurise, vous serez surpris.

Je pense que tous les développeurs devraient visionner cette vidéo intitulée "Vendredi 13: Attaque de JSON - Alvaro Muñoz & Oleksandr Mirosh - AppSecUSA 2017"

Si vous n'avez ni le temps ni l'envie de regarder à travers, voici l'essentiel: De nombreuses bibliothèques de désérialisation JSON comportent des vulnérabilités d'exécution de code à distance. Si vous utilisez XML, vous avez encore plus à vous inquiéter. L'interdiction de SQL à partir de votre architecture ne rendra pas votre système sécurisé.


Personne n'a affirmé que l'interdiction de SQL rendrait en soi votre système sécurisé. Oncle Bob affirme que cela sécurise davantage votre système et que, depuis plus de 10 ans, l'injection de SQL demeure le principal risque en matière de sécurité des applications Web, vous ne devriez pas négliger à la légère la nécessité pour le secteur d'améliorer sa communication avec les bases de données .
Meriton - en grève le

@ Meriton Désolé, mais "la solution, la seule solution" semble assez claire. La solution au problème de SQLi est connue et assez simple. Les personnes qui ne sont pas dérangées par les instructions de préparation vont créer des systèmes non sécurisés, qu’elles arrêtent ou non d’utiliser SQL. Ce sont des personnes non professionnelles qui doivent commencer à suivre les bonnes pratiques de base ou à trouver un nouvel emploi.
JimmyJames

2

Je veux aborder seulement une courte déclaration:

Ou veut-il simplement que les gens arrêtent d'utiliser SQL / Relational Databases en raison d'attaques SQLi?

Non, c'est une hypothèse fausse. Nous ne pouvons pas dire que nous devons cesser d'utiliser des voitures, car elles sont responsables du décès de personnes dans des accidents de voiture. De la même manière, les bases de données relationnelles / SQL (ou tout autre élément dans ce contexte, tel que le SGBDR) ne sont pas responsables des charges SQL malveillantes qu'un attaquant peut effectuer sur votre application Web. Je ne doute pas que l’auteur n’a pas voulu dire cela, car il existe une feuille de triche pour la prévention des injections SQL à cette fin.


2
Les voitures automatisées préviendraient environ 98% des accidents de voiture. Nous devons faire davantage confiance à la machine , heh heh heh.

3
"Nous ne pouvons pas dire que nous devons cesser d'utiliser des voitures [sauf circonstances exceptionnelles et / ou soigneusement contrôlées] car elles sont responsables du décès de personnes dans un accident de voiture." - Uhm. On peut absolument dire ça. Et beaucoup de gens raisonnables le font.
Konrad Rudolph

1
Vous dites en gros: Une application développée en Java est piratée, nous devons donc cesser d’utiliser Java . Le vote négatif est suffisant et pour le reste, je ne suis pas là pour vous enseigner le bon sens. @KonradRudolph
Billal Begueradj

2
@BillalBEGUERADJ C'est une équivalence quelque peu fausse (puisque rien n'est à l'abri du piratage informatique), mais ce n'est pas tout à fait loin non plus: il existe des langages qui, dans l'ensemble, ne devraient pas être utilisés car il existe de meilleures alternatives; Par exemple, si vous utilisez le C en dehors du contexte de la programmation système, vous le faites mal. Quoi qu'il en soit, je ne l' ai pas downvote votre réponse mais il est faux: parce que , contrairement à ce que vous prétendez, qui est exactement ce que Bob Martin dit (comme d' autres réponses montrent).
Konrad Rudolph

2

Le problème de Martin semble être lié au fait que les programmeurs construisent du SQL dynamique directement à partir d'une entrée utilisateur, par exemple (pardonnez-moi, je suis principalement un programmeur C et C ++):

sprintf( query, "select foo from bar where %s;", user_input );

qui est absolument une recette pour les brûlures d'estomac (d'où le strip Bobby Tables ). Tout programmeur qui met un tel code dans un système de production mérite une paddlin '.

Vous pouvez atténuer (voire éliminer complètement) le problème en utilisant des instructions préparées et en nettoyant correctement vos entrées. Si vous pouvez masquer le code SQL derrière une API de telle sorte que les programmeurs ne construisent pas directement de chaînes de requête, tant mieux (ce qui fait partie de ce que préconise Martin).

Mais quant à la suppression complète de SQL, je ne pense pas que ce soit pratique ou souhaitable. Les modèles relationnels sont utiles , c'est pourquoi ils existent tout d'abord, et SQL est probablement la meilleure interface pour travailler avec des modèles relationnels.

Comme toujours, il s’agit d’utiliser le bon outil pour le poste. Si votre application de panier d'achat n'a pas besoin d'un modèle relationnel complet, n'utilisez pas de modèle relationnel (cela signifie que vous n'avez pas besoin d'utiliser SQL). Pour les moments où vous avez besoin d'un modèle relationnel, alors vous allez certainement travailler avec SQL.


Bien sprintfque ne contenant pas le type de désinfection requis par SQL, les fonctions spécialement conçues à cet effet le sont et sont parfaitement sûres. Exemple: SqlQuery dans Entity Framework .
Robert Harvey

@RobertHarvey: Je suppose que c'est le cas. Pour ma part, je travaille principalement côté serveur en C et C ++, je vois donc encore occasionnellement des exemples (heureusement rares) de personnes se contentant de sprintfSQL dynamique, qui n'est pas comment vous le faites.
John Bode

1

Les deux sources que vous associez véhiculent des messages différents:

L'article de blog dit que la logique d'accès aux données ne devrait pas exister sous forme de texte au moment de l'exécution, sinon elle serait mélangée à une entrée utilisateur non fiable. C'est-à-dire que l'article de blog condamne l'écriture de requêtes en concaténant des chaînes.

La conférence est différente. La première différence est dans le ton: la conférence spécule et remet en question, mais ne condamne pas. Il ne dit pas que les bases de données sont diaboliques, mais nous met au défi d'imaginer la persistance sans base de données. Il fait valoir qu'au cours des 30 années écoulées depuis que les bases de données relationnelles se sont généralisées, beaucoup de choses ont changé et met en exergue deux facteurs susceptibles d'affecter notre choix de technologie de persistance:

  • l’espace de stockage a été multiplié par environ 1 million - à des prix comparables! Par conséquent, il est moins nécessaire de conserver le stockage, et en particulier, il n'est plus nécessaire de supprimer. En utilisant le stockage avec ajout uniquement, le contrôle des accès simultanés peut être simplifié, car les verrous en lecture sont inutiles. Cela peut éliminer le besoin de transactions.
  • les temps d'accès ont diminué, car la plupart des jeux de données sont désormais stockés dans la RAM, ce qui réduit considérablement le temps de latence des lectures.

Ces changements de circonstances changent-ils la technologie de persistance optimale? Fait intéressant, oncle Bob ne dit pas - probablement parce qu’il pense qu’aucune réponse ne serait correcte pour tous les programmes. C'est pourquoi il nous met en garde de traiter notre choix de technologie de persistance comme un détail plutôt que de l'enregistrer dans des tablettes de pierre et de le transmettre comme une sagesse reçue à nos pairs.

Existe-t-il des alternatives?

L'écriture de logique d'accès aux données sans chaînes est tout à fait possible. En Java, vous pouvez utiliser QueryDSL , dans lequel les requêtes sont décrites à l'aide d'une API fluide de type sécurisée générée à partir de votre schéma de base de données. Une telle requête pourrait ressembler à ceci:

JPAQuery<?> query = new JPAQuery<Void>(entityManager);
Customer bob = query.select(customer)
  .from(customer)
  .where(customer.firstName.eq("Bob"))
  .fetchOne();

Comme vous pouvez le constater, la logique de la requête n'est pas exprimée sous forme de chaîne, séparant clairement la structure sécurisée de la requête des paramètres non fiables (et bien entendu, QueryDSL n'inclut jamais les paramètres dans le texte de la requête, mais utilise des instructions préparées pour séparer la requête. pour ses paramètres au niveau JDBC). Pour réaliser l'injection SQL avec QueryDSL, vous devez écrire votre propre analyseur syntaxique afin d'analyser une chaîne et de la traduire en arborescence syntaxique. Même si vous procédiez ainsi, vous n'ajouteriez probablement pas de prise en charge, par exemple select ... into file. En bref, QueryDSL rend l'injection SQL impossible, améliore également la productivité du programmeur et augmente la sécurité du refactoring. Prévention du plus grand risque pour la sécurité des applications Web, qui existe depuis assez longtemps pour engendrer des gagset dynamisé la productivité des développeurs? J'ose dire que si vous écrivez toujours des requêtes sous forme de chaînes, vous le faites mal.

Pour ce qui est des alternatives aux bases de données relationnelles, il est curieux de savoir que le contrôle de la concurrence multi-version de Postgres est exactement ce genre de structure de données pour append, dont parle seulement Oncle Bob, même s'il pensait probablement davantage aux magasins d’événements , et au sourcing d’événements. motif en général, ce qui cadre aussi parfaitement avec la notion de maintien de l’état actuel dans la RAM.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.