Le rapport Ponemon offre un aperçu intéressant :
SQL est martelé par les méchants . Pourquoi est-ce , et c'est là tout ce qui peut être fait pour remédier à la situation ? Une récente étude du Ponemon sur les injections SQL et les solutions possibles sont discutés.
SQL a été autour depuis les années 1970 , donc on assumerait tous les bugs de la vulnérabilité du language ont été éliminés.Pourtant, il existe encore de nombreux rapports d'attaquants pouvant tirer parti des faiblesses dans SQL à enfreindre systématiquement les entreprises de grande envergure .
On m'a dit que c'est la nature de la bête . Chaque fois que les gens sont autorisés à accéder aux informations stockées sur les serveurs backend,le problème est juste une requête plus loin .Méchants utilisent une injection SQL pour libérer les données du serveur hébergeant la base de données sous attaque .
En quoi consiste exactement une attaque par injection SQL ?
Selon l'Institut Ponemon , injection SQL est utilisée pour :
" Applications pilotées par les données d'attaque : dans les instructions SQL malveillants sont insérés dans un champ de saisie pour l'exécution (par exemple pour vider le contenu de base de données à l'attaquant ) injections SQL exploitent les failles de sécurité dans le logiciel d'une application injection SQL est plus communément connu comme un . . vecteur d'attaque par des sites grand public , mais peut être utilisée pour attaquer des bases de données SQL dans une variété de façons . "
Pourquoi les attaques par injection SQL sont encore répandue ?
Le fait que les attaques par injection SQL ont été découverts il y a plus de 15 ans par Jeff Forristal et sont encore exécuté par beaucoup de gens frustrés .
D'autres applications vulnérables sont finalement fixés , mais pas SQL . Le projet Open Web Application Security ( OWASP ) propose cette explication :
«Les attaques par injection SQL sont malheureusement très commun , et cela est dû à deux facteurs : . La prévalence des vulnérabilités d'injection SQL et l'attractivité de la cible ( bases de données contenant les données intéressantes / critiques pour l'application ) "
La prévalence de la vulnérabilité et l'apparente incapacité de faire quoi que ce soit à ce sujet le Dr Larry Ponemon perplexe , président et fondateur de l'Institut Ponemon , un organisme de recherche indépendant . Dr Ponemon a décidé de faire ce qu'il fait le mieux : la recherche du problème .
Avec le parrainage de DB Networks, l'Institut Ponemon a recueilli les réponses de près de 600 membres du personnel de TI et les professionnels de la sécurité pour tenter de comprendre comment les organisations réagissent aux menaces d'injection SQL et la prise de conscience des participants sur la façon de gérer le risque - les choses simplement , pourquoi les attaques par injection SQL se produisent encore .
De l'enquête les réponses des répondants , l'Institut Ponemon dérivé résultats intéressants qu'il a publié dans l'étude SQL Injection de la menace .
Méthodologie de l'enquête
Avant d'arriver à ce découvert Ponemon , je vais partager la façon dont il a mis en place l'enquête , en particulier la sélection des participants :
SQL est martelé par les méchants . Pourquoi est-ce , et c'est là tout ce qui peut être fait pour remédier à la situation ? Une récente étude du Ponemon sur les injections SQL et les solutions possibles sont discutés.
SQL a été autour depuis les années 1970 , donc on assumerait tous les bugs de la vulnérabilité du language ont été éliminés.Pourtant, il existe encore de nombreux rapports d'attaquants pouvant tirer parti des faiblesses dans SQL à enfreindre systématiquement les entreprises de grande envergure .
On m'a dit que c'est la nature de la bête . Chaque fois que les gens sont autorisés à accéder aux informations stockées sur les serveurs backend,le problème est juste une requête plus loin .Méchants utilisent une injection SQL pour libérer les données du serveur hébergeant la base de données sous attaque .
En quoi consiste exactement une attaque par injection SQL ?
Selon l'Institut Ponemon , injection SQL est utilisée pour :
" Applications pilotées par les données d'attaque : dans les instructions SQL malveillants sont insérés dans un champ de saisie pour l'exécution (par exemple pour vider le contenu de base de données à l'attaquant ) injections SQL exploitent les failles de sécurité dans le logiciel d'une application injection SQL est plus communément connu comme un . . vecteur d'attaque par des sites grand public , mais peut être utilisée pour attaquer des bases de données SQL dans une variété de façons . "
Pourquoi les attaques par injection SQL sont encore répandue ?
Le fait que les attaques par injection SQL ont été découverts il y a plus de 15 ans par Jeff Forristal et sont encore exécuté par beaucoup de gens frustrés .
D'autres applications vulnérables sont finalement fixés , mais pas SQL . Le projet Open Web Application Security ( OWASP ) propose cette explication :
«Les attaques par injection SQL sont malheureusement très commun , et cela est dû à deux facteurs : . La prévalence des vulnérabilités d'injection SQL et l'attractivité de la cible ( bases de données contenant les données intéressantes / critiques pour l'application ) "
La prévalence de la vulnérabilité et l'apparente incapacité de faire quoi que ce soit à ce sujet le Dr Larry Ponemon perplexe , président et fondateur de l'Institut Ponemon , un organisme de recherche indépendant . Dr Ponemon a décidé de faire ce qu'il fait le mieux : la recherche du problème .
Avec le parrainage de DB Networks, l'Institut Ponemon a recueilli les réponses de près de 600 membres du personnel de TI et les professionnels de la sécurité pour tenter de comprendre comment les organisations réagissent aux menaces d'injection SQL et la prise de conscience des participants sur la façon de gérer le risque - les choses simplement , pourquoi les attaques par injection SQL se produisent encore .
De l'enquête les réponses des répondants , l'Institut Ponemon dérivé résultats intéressants qu'il a publié dans l'étude SQL Injection de la menace .
Méthodologie de l'enquête
Avant d'arriver à ce découvert Ponemon , je vais partager la façon dont il a mis en place l'enquête , en particulier la sélection des participants :
" Un cadre d'échantillonnage de 16520 a connu TI et praticiens de la sécurité situées aux États-Unis ont été sélectionnés comme participants à cette enquête. Rendement total s'élève à 701 . Dépistage et les vérifications de fiabilité requis la suppression de 106 enquêtes . L'échantillon final était composé de 595 enquêtes . "
Le nombre d'organisations attaquées
Une conférence téléphonique a eu lieu avec le Dr Ponemon et Michael Sabo , vice- président du marketing pour DB Networks, pour discuter des résultats . L' ampleur du problème a fait surface lors de l'examen des réponses des répondants aux questions suivantes :
Au cours des 12 derniers mois , votre entreprise at- expérience une ou plusieurs attaques réussies par injection SQL ?
Si oui , combien de temps at-il fallu pour détecter l'attaque ?
Si oui , combien de temps at-il fallu pour contenir l'attaque ?
Soixante- cinq pour cent des organisations représentées dans cette étude a connu une attaque par injection SQL qui a évité avec succès leurs défenses périmétriques dans les 12 derniers mois . Vingt et un pour cent ( le plus grand groupe en termes de pourcentage ) a déclaré qu'il a pris six mois pour détecter l'attaque , et vingt- un pour cent ( le plus grand groupe en termes de pourcentage ) dit qu'il a fallu un mois pour contenir l'attaque .
Pourquoi le taux de réussite ?
La prochaine série de questions a essayé de déchiffrer pourquoi tant d'attaques ont réussi , et pourquoi il a fallu tant de temps pour détecter et contenir les attaques :
Comment êtes-vous familier avec le terme comme arme d'attaque par injection SQL ?
Combien de fois ne scanne votre entreprise pour les bases de données actives ?
Est-ce que votre test de l'entreprise et de valider des logiciels tiers afin de s'assurer qu'elle n'est pas vulnérable à des attaques par injection SQL ?
Quarante- huit pour cent des répondants n'étaient pas familiers avec le terme comme arme attaques par injection SQL . Comme pour la numérisation de bases de données actives , vingt -cinq pour cent le faire à intervalles irréguliers , et vingt-deux pour cent ne recherche pas du tout . Cinquante -deux pour cent des répondants ne va pas tester ou valider un logiciel tiers pour leur sensibilité à attaques par injection SQL .
Essayer d'identifier les faiblesses
Ensuite, les participants ont été invités à évaluer les déclarations suivantes .
La question se référant au BYOD semblait hors de propos. Pour expliquer , Sabo mentionné attaques par injection SQL via un PC a commencé avec le navigateur Web , dont il ne reste que quelques versions et relativement facile à obtenir . Considérant que, BYOD , le plus souvent chaque application se connecte à un serveur SQL , ce qui rend presque impossible de protéger les appareils et les données , et d'expliquer pourquoi 56 pour cent des répondants sont préoccupés par BYOD .
les conclusions
Comme la plupart des enquêtes , l'étude SQL Injection de la menace fournit les informations , mais pas de conclusions . Ponemon et Sabo ont été invités à spéculer sur les conclusions du rapport d'enquête . Tous deux centrés sur la façon dont le maillon faible de SQL est la requête , et que la garantie de toutes les requêtes font ce qu'ils sont censés et rien de plus est une tâche difficile .
Sabo a également mentionné que , jusqu'à récemment , il fallait un haut niveau d'expertise pour construire une requête illicite . Maintenant, l'Internet est inondé avec des outils qui permettent aux individus inexpérimentés à obscurcir les requêtes malveillantes , ce qui rend facile d'être un mauvais gars(Pirate/Hacker) , et encore plus difficile pour les mesures de sécurité SQL pour détecter les requêtes malveillantes.
" Le processus commence par l'apprentissage automatique et la modélisation du comportement de génération de SQL correcte de l'application. L'IDS de base utilise alors une suite de procédures de tester et d'évaluer chaque instruction SQL sur le modèle de comportement appris. Logique floue est appliquée pour déterminer la menace globale de chaque instruction SQL . "
Scepticisme sur les solutions est justifiée sur la base du passé de SQL . Mais , Joe McCray , un consultant indépendant en sécurité et vétéran Pen testeur, dans cette vidéo YouTube, a expliqué que la réponse de DB réseau à injection SQL bloqué toutes les attaques qu'il a essayé :
" La façon dont le produit fonctionne est unique . Le suivi en temps réel et la détection basée sur les anomalies - était quelque chose que je n'avais pas vu dans cet espace de l'application. Elle a été en mesure de montrer à tous les attentats que je tentais , même quelques trucs très sophistiqués que j'utilise " .
Aucun commentaire:
Publier un commentaire