Découvrez comment intégrer facilement l'analyse statique, les tests unitaires et d'autres méthodes de test de logiciels C et C++ dans votre pipeline CI/CD. Inscrivez-vous pour la démo >>

Injections SQL et sécurité des élections

Par Arthur Hicken

6 novembre 2018

5  min lire

Est-ce que ta tête est dans le sable? Ne pas faire de tests de sécurité adéquats pourrait vous ressentir sûr, mais ne pas connaître les vulnérabilités de votre code ne protégera pas vos systèmes. Découvrez comment obtenir plus de visibilité et intégrer la sécurité dans votre code.

Tout comme des élections justes et précises sont le fondement de la démocratie, un logiciel sécurisé est essentiel à notre vie numérique moderne. Je ne les compare pas pour être mignons, mais plutôt pour creuser l'intersection des deux, ce qui peut être désastreux. Analyse récente de nos systèmes de vote aux États-Unis nous ont montré qu'ils sont criblé d'insécuritéDonnées des électeurs est volé facilement et souvent. Maintenant, lorsque vous pensez à cette vulnérabilité dans les quelque 10,000 XNUMX juridictions électorales locales, il semble bien sûr probable que certains de ces systèmes ne sont pas sécurisés.

La plus effrayante et la plus informative de ces histoires est peut-être récent hackathon DefCon, un enfant de 11 ans a pu accéder aux données des résultats des élections sur un système de test en utilisant mon ancien injection SQL préférée. Cela a pris 10 minutes. Je suppose que je ne suis pas surpris, car j'ai longtemps pensé à l'injection SQL comme un jeu d'enfant (c'est pourquoi j'ai fait le Salle de la honte SQLi). Un organisateur de DefCon a noté:

"Ces sites Web sont si faciles à pirater que nous ne pourrions pas les donner à des pirates adultes - ils se moqueraient de la scène"

Les responsables électoraux, dans ce cas, affirment que les vrais systèmes sont beaucoup plus difficiles à pirater, mais je suis sceptique. Ce type de déni est courant dans l'industrie de la sécurité logicielle jusqu'au moment où un piratage se produit. Revenez simplement à Heartbleed, que la plupart n'ont pas pris au sérieux jusqu'à ce qu'il soit complètement prouvé. Ou lorsque les vulnérabilités dans capteurs de pression des pneus ont été découverts après que des gens de l'industrie aient dit que c'était trop difficile, avec trop de variétés, peu importe, etc. il y a quelques semaines.

Dans un autre mouvement trop courant, de nombreux responsables électoraux je n'ai fait aucun test. Cette approche directe peut les aider à se sentir mieux, mais ne pas savoir quels sont vos risques de sécurité ne protège pas vos systèmes. Je garantis que les mauvais acteurs savent exactement quelles sont les vulnérabilités.

nous devons faire mieux

Nous devons commencer à faire un meilleur travail. Il est déjà assez difficile de sécuriser les systèmes connectés à Internet - nous n'avons pas besoin de donner aux pirates un accès facile.

Il existe un refrain commun dans la communauté de la cybersécurité selon lequel une sécurité à 100% n'est pas possible. Mais bien que cela soit vrai, pour le moment, ce n'est PAS le problème. Le problème est que nous ne faisons même pas le truc facile pour sécuriser notre logiciel - par exemple, ni pour le site Web de l'électeur ni pour machines à voter. Je sais que quiconque veut vraiment ma voiture peut la voler, mais je verrouille toujours les portières et je ne laisse pas les clés dedans. Ne pas sécuriser votre application connectée à Internet contre les attaques basées sur les entrées signifie que vous laissez quelqu'un partir avec toutes vos données.

Comment pouvons-nous faire un meilleur travail?

Quelles que soient les motivations des pirates électoraux, qu'il s'agisse d'États-nations, d'organisations politiques ou de pirates informatiques dans leur sous-sol à la recherche de plaisir, il est important de faire ce que nous pouvons pour augmenter la sécurité et la fiabilité de nos systèmes de vote. Les problèmes peuvent sembler énormes, mais en fait, nous pouvons faire certaines choses de base qui seront efficaces en bouchant les trous les plus évidents dans notre système qui fuit.

Sécurisé dès la conception

Secure-by-design signifie que nous devons commencer à penser différemment à la sécurité des applications et au codage sécurisé. Cela signifie que nous ne pouvons pas plus tester la sécurité de nos logiciels que nous ne pouvons tester la qualité d'un produit. La partie «par conception» signifie que nous pensons d'abord à la sécurité, puis nous construisons des applications sécurisées, et nous faisons des tests de sécurité comme des tests d'intrusion dans le but de valider la sécurité, PAS dans le but de trouver des failles de sécurité.

Posez-vous la question - que faites-vous lorsque le stylo-test trouve quelque chose? Faites-vous un suivi avec une analyse de flux pour trouver des vulnérabilités similaires? Recherchez-vous alors des normes comme celles de CERT pour des stratégies qui vous montrent comment coder de manière à éviter ce que votre test de stylet détecte? Dans le cas de SQLi, cela signifie faire la validation des entrées d'une manière déterministe qui n'a aucune chance de manquer l'entrée de l'utilisateur.

mots de passe

Un moyen courant pour les attaquants d'accéder aux appareils consiste à utiliser des mots de passe. Si les appareils autorisent des mots de passe de mauvaise qualité ou ne se protègent pas contre les tentatives de deviner les mots de passe, ils seront vulnérables. Dans le pire des cas, les appareils sont livrés sans aucun mot de passe jusqu'à ce que vous en configuriez un, ou avec des informations d'identification par défaut codées en dur. C'est un problème dont l'industrie est consciente depuis plusieurs décennies, mais qui persiste encore. La législation récente en Californie oblige les fabricants d'appareils à prendre des mesures de base dans ce domaine. Ce n'est certainement pas une solution complète, mais un excellent début.

Normes de codage sécurisées

Il existe de nombreuses normes et cadres de cybersécurité que vous pouvez utiliser pour vous guider sur les pratiques et les processus à mettre en œuvre pour créer un code sécurisé, tels que les tests unitaires, la mesure de la couverture, l'exécution d'une analyse statique, l'examen par les pairs, etc. Au niveau logiciel, cela doit aboutissent finalement à des normes de codage spécifiques.

Les normes de codage comprennent des directives de différentes variétés. Certains d'entre eux recherchent des défauts de codage, identifiant les problèmes de sécurité sans avoir à exécuter le code. D'autres sont des anti-modèles, ce qui signifie qu'ils recherchent du mauvais code que vous ne devriez jamais utiliser, ou «le code sent». D'autres encore sont normatifs et vous indiquent une meilleure façon de coder.

Ce dernier groupe est le seul moyen de prendre de l'avance sur la cybersécurité. Ces normes sont bien adaptées à une initiative de conception sécurisée et vous aideront à créer un code plus sécurisé en premier lieu. Lorsque vous implémentez votre initiative d'analyse statique pour un codage sécurisé, assurez-vous de regarder les vérificateurs disponibles et assurez-vous d'avoir un bon mélange de détecteurs, d'odeurs et de prévention. Ensemble, les trois peuvent renforcer votre application, non seulement contre l'injection SQL, mais contre toutes les autres attaques courantes basées sur les entrées.

Démarrage rapide

Parasoft prend en charge une grande variété de ces règles pour les développeurs qui utilisent C, C ++, Java et .NET. Nous prenons en charge les normes de sécurité communes telles que CWE, OWASP, CERT et UL 2900, et comme nous avons commencé nos offres d'analyse statique basées sur des normes d'ingénierie, il semble que nous ayons le plus grand ensemble de règles préventives disponibles partout. Par exemple, nous avons une règle de validation d'entrée simple qui, lorsqu'elle est suivie, met fin à la possibilité de SQLi. Il ne le fait pas en essayant de chasser les données corrompues à travers la myriade (et presque infinie) de flux d'une application (sécurisé par test) mais plutôt en créant du code où il n'y a pas de chemins pour la validation d'entrée à contourner (sécurisé- intentionnellement).

C'est une manière fondamentalement différente de penser la sécurité. Si vous avez un diplôme d'ingénieur, ce type d'approche normative vous sera très familier. Si vous avez passé votre vie à créer des logiciels, cela peut sembler nouveau. Mais cela vous permettra de prendre une longueur d'avance en matière de sécurité logicielle. Appelez-nous et essayez-le par vous-même.

Intégrez la sécurité dans votre application dès le début

Par Arthur Hicken

Arthur est impliqué dans la sécurité logicielle et l'automatisation des tests chez Parasoft depuis plus de 25 ans, aidant à la recherche de nouvelles méthodes et techniques (dont 5 brevets) tout en aidant les clients à améliorer leurs pratiques logicielles.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.