Anne  de Morel

Anne de Morel

1656070140

Qu'est-ce Que L'injection SQL Et Pourquoi Est-ce Dangereux ?

Les développeurs traitant d'applications Web voient beaucoup de choses menaçant de nuire aux choses qu'ils construisent. Certaines de ces choses incluent des attaques ciblées sur des personnes (par exemple, l'ingénierie sociale), certaines de ces attaques (attaques DoS ou DDoS, Cross-Site Scripting, Cross-Site Request Forgery, Broken Authentication, Sensitive Data Exposure, Broken Access Control, Insecure désérialisation, etc.) ciblent des parties d'applications Web. Cependant, certaines attaques ciblent principalement votre base de données et les données qui y sont stockées. L'une de ces attaques est l'injection SQL (SQLi en abrégé). Dans cet article de blog, nous examinerons les impacts qu'une telle attaque pourrait avoir.

Qu'est-ce que l'injection SQL et pourquoi est-ce dangereux ?

L'injection SQL est une attaque fréquemment ciblée sur les applications Web. Le but d'une telle attaque est souvent d'exfiltrer des données sensibles de la base de données et de les utiliser pour le gain personnel de l'attaquant. Une telle attaque est si répandue et dangereuse précisément parce que de nombreux développeurs négligent l'importance de la sécurité lors de la création de solutions publiques orientées Web. Lorsque les failles de sécurité sont ignorées, les parties malveillantes les trouvent et les exploitent souvent. Ces acteurs néfastes exploitent ces vulnérabilités car ils peuvent tirer profit de la vente de données volées lors de la violation.

Les impacts d'une telle attaque dépendent de votre application Web. Supposons que votre application ne stocke pas d'informations sensibles, auquel cas l'attaque n'aurait probablement pas de conséquences importantes. Cependant, si ce n'est pas le cas, vous pourriez avoir un sérieux problème entre vos mains : des données sensibles pourraient être volées et vendues à des fins lucratives, causant des problèmes pour votre entreprise et des problèmes inutiles pour vos clients en raison de la réinitialisation des mots de passe et de la modification d'informations ailleurs.

Comment fonctionne l'injection SQL ?

Le concept d'injection SQL est assez simple : une telle attaque fonctionne parce que certains développeurs placent tout ce que l'utilisateur écrit dans un champ de saisie donné dans une requête et le transmettent à une base de données. Un extrait de base de code vulnérable ressemblerait à ceci (vous pouvez également utiliser $_GET au lieu de $_POST, le principe est le même) :

$Input = $_POST['input'];

SELECT * FROM demo_table WHERE column [= | < | > | <= | >= | LIKE ...] '$Input';

Comme vous pouvez le voir, dans certains cas, le code vulnérable est assez simple (il peut aussi devenir complexe, nous aborderons différents scénarios plus tard) - un tel code vulnérable est ensuite exploité par des attaquants utilisant fréquemment le guillemet (') pour induire des erreurs. Une fois qu'il induit des erreurs, les attaquants savent que le code est vulnérable et ils peuvent attaquer nos applications.

Types d'injection SQL

Les attaques par injection SQL appartiennent à deux catégories :

  • Injection SQL classique - un type d'injection SQL de base lorsque l'attaquant vise à exécuter du code SQL dans une base de données pour accéder à une application ou à tout autre système qui a implémenté MySQL dans son architecture de base de données.
  • Injection SQL basée sur l'union - un type d'injection SQL où un attaquant utilise la clause UNION dans MySQL pour combiner les résultats de requêtes qui renvoient une réponse utile pour l'attaquant.
  • Injection SQL basée sur les erreurs - un type d'injection SQL où l'attaquant collecte des données principalement par le biais de messages d'erreur affichés (ou absents) sur l'application attaquée. L'injection SQL basée sur les erreurs a quelques types en soi.
  • Injection SQL hors bande (OOB) - un type d'injection SQL où un attaquant ne peut pas utiliser la même application pour attaquer et collecter les résultats. Un type d'injection SQL moins connu, mais un type néanmoins.

Les attaquants utilisent chacun des types décrits ci-dessus pour atteindre différents objectifs - l'injection SQL classique est utile si l'attaquant a des connaissances implicites sur le fonctionnement interne du système, l'injection SQL basée sur l'union peut être utile si l'attaquant combine les résultats d'un couple d' SELECTinstructions dans un seul ensemble de résultats, l'injection SQL basée sur les erreurs est utilisée lorsque l'application est "silencieuse" (ce qui signifie qu'elle ne renvoie aucune réponse, de sorte que l'attaquant recherche des modifications de fonctionnalité lors de l'émission de certains types de requêtes)

Protéger votre application contre l'injection SQL

À ce stade, vous devriez avoir une assez bonne compréhension de ce qu'est l'injection SQL et de ses types, mais comment protégez-vous vos applications d'une telle attaque ? Heureusement, il existe quelques moyens bien connus de réduire le risque qu'une telle vulnérabilité soit exploitée maintenant ou à l'avenir :

  • Maintenez à jour tous les composants de votre application et installez tous les correctifs de sécurité nécessaires . La mise à jour des composants de l'application doit constituer une première ligne de défense efficace contre toute attaque.
  • Valider l'entrée - comme le succès d'une telle attaque dépend fortement de l'entrée que l'attaquant fournit au système, la validation des entrées pourrait être un autre moyen efficace d'empêcher les attaques par injection SQL maintenant et à l'avenir.
  • Utilisez des instructions paramétrées - l'utilisation d'instructions paramétrées est peut-être le moyen le plus efficace de se défendre contre les attaques par injection SQL. Lorsque des instructions paramétrées sont utilisées, le serveur interprète toujours l'entrée utilisateur comme une valeur et ne l'analyse pas. Par exemple:
/* Prepare MySQL statement */

if (!($statement = $mysqli->prepare(
	"SELECT customerID 
    FROM orders 
    WHERE item = ?"
    ))) {
    	echo "Failed: (" . $mysqli->errno . ") " . $mysqli->error;
}

/* 
Bind variables to statement as parameters using bind_param().
The type (first) parameter can take integers (i), doubles (d), 
strings(s), and blobs (b).
*/

$purchasedItem = 'ice cream';
if (!$statement->bind_param("s", $purchasedItem)) {    
    echo "Failed: (" . $statement->errno . ") " . $statement->error;
}

/* Execute prepared MySQL statement */
if (!$statement->execute()) {
    echo "Failed: (" . $statement->errno . ") " . $statement->error;
}

 

  • Utilisez un pare-feu d'application Web - l'utilisation d'un pare-feu d'application Web (WAF) est une autre ligne de défense efficace, car les pare-feu d'application Web sont généralement capables d'identifier et de bloquer plusieurs types d'attaques, y compris l'injection SQL, les scripts intersites et la falsification de requête intersite. , contrôle d'accès cassé, exposition de données sensibles, attaques DoS ou DDoS, entre autres. Un pare-feu d'application Web doit idéalement être utilisé avec des instructions paramétrées pour une efficacité et une défense maximales contre l'injection SQL et d'autres types d'attaques.
  • Utilisez des applications axées sur la sécurité fournies par MySQL ou d'autres fournisseurs - MySQL offre un moyen de protéger vos applications contre l'injection SQL au niveau de l'entreprise en utilisant un outil MySQL Enterprise Firewall, qui peut fournir une protection en temps réel contre les menaces spécifiques à la base de données. De plus, plusieurs autres fournisseurs méritent d'être discutés plus en détail (à part MySQL, certains d'entre eux incluent MariaDB, MinervaDB, MongoDB, Oracle, Manynines et d'autres). Pourtant, pour ce billet de blog, nous n'allons pas trop entrer dans les détails.
  • Évitez d'accorder des privilèges administratifs lorsqu'ils ne sont pas nécessaires - éviter d'accorder des privilèges inutiles peut être une forteresse efficace contre de nombreux types d'attaques, y compris l'escalade de privilèges et, bien sûr, l'injection SQL. Par exemple, si l'utilisateur qui utilise votre application n'a besoin que de certains droits d'accès, pensez à n'accorder que les autorisations nécessaires pour effectuer les tâches. Appliquer la règle du moindre privilège au niveau de la base de données est également une excellente idée.

Garder ces points à l'esprit devrait aider votre application à bien fonctionner.

Protéger votre base de données de l'injection SQL

L'utilisation d'instructions préparées, l'utilisation de plugins axés sur la sécurité fournis par MySQL, le fait d'éviter d'accorder des privilèges administratifs inutiles et de prendre en compte les autres précautions susmentionnées devraient vous mettre, vous et votre base de données, sur la bonne voie. Cependant, si vous souhaitez approfondir MySQL et comprendre pourquoi les requêtes SQL fonctionnent comme elles le font et pourquoi l'utilisation, par exemple, d'un pare-feu d'application Web (WAF) peut vous protéger contre de nombreux types d'attaques, y compris l'injection SQL, considérez ceci :

  • Considérez chaque requête comme une tâche importante composée de tâches plus petites.
  • Les tâches de la requête peuvent être observées en exécutantSHOW PROFILE FOR QUERY [query id here];

S'il est utilisé correctement, dans la plupart des cas, la sortie vous fournira ce que la requête a fait et la durée de la tâche. Vous pourrez également observer un tas de choses intéressantes, notamment obtenir des réponses à des questions telles que :

  • Combien de temps la requête a-t-elle mis pour démarrer ?
  • Combien de temps la requête a-t-elle pris pour vérifier les autorisations ?
  • Combien de temps a-t-il fallu à MySQL pour ouvrir les tables ?
  • Combien de temps a-t-il fallu à MySQL pour initialiser les processus ?
  • Combien de temps a-t-il fallu à MySQL pour optimiser, préparer et (ou) exécuter la requête ?
  • Combien de temps a-t-il fallu à MySQL pour vous renvoyer les données à consulter ?
  • Combien de temps a-t-il fallu à MySQL pour terminer la requête, fermer les tables, libérer des éléments ?

Certaines des réponses à ces questions pourraient vous aider à comprendre pourquoi l'injection SQL fonctionne comme elle le fait. Par exemple, relancez une SHOW PROFILE FOR QUERYrequête et vous verrez ce qui suit :

Une partie de la sortie de la requêteSHOW PROFILE FOR QUERY

La ligne marquée indique que juste après le début de l'exécution de la requête, MySQL vérifie les autorisations. Vous souvenez-vous de ce dont nous avons discuté plus tôt ? Vous devez éviter d'accorder des privilèges inutiles précisément pour cette raison - si le compte MySQL ciblé par un attaquant n'a pas suffisamment d'autorisations, la requête échouera. Étant donné que la fonctionnalité des SHOW PROFILE FOR QUERYrequêtes n'entre pas dans le cadre de cet article de blog, nous n'allons pas entrer dans trop de détails ici, mais vous pouvez voir comment et pourquoi il est important de suivre les conseils ci-dessus.

La plupart des conseils décrits ci-dessus sont également applicables dans l'espace de la base de données :

  • La mise à jour de tous les composants de votre application inclut phpMyAdmin.
  • La validation des entrées inclut la validation de toutes les entrées, pas seulement la validation des entrées qui font partie de quelque chose.
  • Les instructions paramétrées peuvent (et doivent) être utilisées dans toutes les occasions où des requêtes SQL sont utilisées pour éviter l'exfiltration de données de certaines tables.
  • L'utilisation d'un pare-feu d'application Web et l'utilisation de plugins axés sur la sécurité peuvent empêcher les attaquants d'accéder à votre base de données.
  • Éviter d'accorder trop de privilèges peut également sauver votre base de données d'un désastre (reportez-vous à l'exemple ci-dessus)

Tenez compte des conseils ci-dessus et vous devriez être sur la bonne voie pour atténuer les problèmes d'injection SQL qui pourraient affecter votre base de données maintenant ou à l'avenir.

Sommaire

Comme vous pouvez le constater, la plupart des conseils qui vous aident à sécuriser vos applications et vos bases de données contre l'injection SQL sont assez généraux et simples. Cependant, sécuriser vos bases de données à partir de l'injection SQL n'est pas sorcier non plus - gardez à l'esprit les directives décrites ci-dessus, et vous devriez être prêt à partir ! 

Source : https://arctype.com/blog/sql-injection/

#sql 

What is GEEK

Buddha Community

Qu'est-ce Que L'injection SQL Et Pourquoi Est-ce Dangereux ?
Cayla  Erdman

Cayla Erdman

1594369800

Introduction to Structured Query Language SQL pdf

SQL stands for Structured Query Language. SQL is a scripting language expected to store, control, and inquiry information put away in social databases. The main manifestation of SQL showed up in 1974, when a gathering in IBM built up the principal model of a social database. The primary business social database was discharged by Relational Software later turning out to be Oracle.

Models for SQL exist. In any case, the SQL that can be utilized on every last one of the major RDBMS today is in various flavors. This is because of two reasons:

1. The SQL order standard is genuinely intricate, and it isn’t handy to actualize the whole standard.

2. Every database seller needs an approach to separate its item from others.

Right now, contrasts are noted where fitting.

#programming books #beginning sql pdf #commands sql #download free sql full book pdf #introduction to sql pdf #introduction to sql ppt #introduction to sql #practical sql pdf #sql commands pdf with examples free download #sql commands #sql free bool download #sql guide #sql language #sql pdf #sql ppt #sql programming language #sql tutorial for beginners #sql tutorial pdf #sql #structured query language pdf #structured query language ppt #structured query language

Anne  de Morel

Anne de Morel

1656070140

Qu'est-ce Que L'injection SQL Et Pourquoi Est-ce Dangereux ?

Les développeurs traitant d'applications Web voient beaucoup de choses menaçant de nuire aux choses qu'ils construisent. Certaines de ces choses incluent des attaques ciblées sur des personnes (par exemple, l'ingénierie sociale), certaines de ces attaques (attaques DoS ou DDoS, Cross-Site Scripting, Cross-Site Request Forgery, Broken Authentication, Sensitive Data Exposure, Broken Access Control, Insecure désérialisation, etc.) ciblent des parties d'applications Web. Cependant, certaines attaques ciblent principalement votre base de données et les données qui y sont stockées. L'une de ces attaques est l'injection SQL (SQLi en abrégé). Dans cet article de blog, nous examinerons les impacts qu'une telle attaque pourrait avoir.

Qu'est-ce que l'injection SQL et pourquoi est-ce dangereux ?

L'injection SQL est une attaque fréquemment ciblée sur les applications Web. Le but d'une telle attaque est souvent d'exfiltrer des données sensibles de la base de données et de les utiliser pour le gain personnel de l'attaquant. Une telle attaque est si répandue et dangereuse précisément parce que de nombreux développeurs négligent l'importance de la sécurité lors de la création de solutions publiques orientées Web. Lorsque les failles de sécurité sont ignorées, les parties malveillantes les trouvent et les exploitent souvent. Ces acteurs néfastes exploitent ces vulnérabilités car ils peuvent tirer profit de la vente de données volées lors de la violation.

Les impacts d'une telle attaque dépendent de votre application Web. Supposons que votre application ne stocke pas d'informations sensibles, auquel cas l'attaque n'aurait probablement pas de conséquences importantes. Cependant, si ce n'est pas le cas, vous pourriez avoir un sérieux problème entre vos mains : des données sensibles pourraient être volées et vendues à des fins lucratives, causant des problèmes pour votre entreprise et des problèmes inutiles pour vos clients en raison de la réinitialisation des mots de passe et de la modification d'informations ailleurs.

Comment fonctionne l'injection SQL ?

Le concept d'injection SQL est assez simple : une telle attaque fonctionne parce que certains développeurs placent tout ce que l'utilisateur écrit dans un champ de saisie donné dans une requête et le transmettent à une base de données. Un extrait de base de code vulnérable ressemblerait à ceci (vous pouvez également utiliser $_GET au lieu de $_POST, le principe est le même) :

$Input = $_POST['input'];

SELECT * FROM demo_table WHERE column [= | < | > | <= | >= | LIKE ...] '$Input';

Comme vous pouvez le voir, dans certains cas, le code vulnérable est assez simple (il peut aussi devenir complexe, nous aborderons différents scénarios plus tard) - un tel code vulnérable est ensuite exploité par des attaquants utilisant fréquemment le guillemet (') pour induire des erreurs. Une fois qu'il induit des erreurs, les attaquants savent que le code est vulnérable et ils peuvent attaquer nos applications.

Types d'injection SQL

Les attaques par injection SQL appartiennent à deux catégories :

  • Injection SQL classique - un type d'injection SQL de base lorsque l'attaquant vise à exécuter du code SQL dans une base de données pour accéder à une application ou à tout autre système qui a implémenté MySQL dans son architecture de base de données.
  • Injection SQL basée sur l'union - un type d'injection SQL où un attaquant utilise la clause UNION dans MySQL pour combiner les résultats de requêtes qui renvoient une réponse utile pour l'attaquant.
  • Injection SQL basée sur les erreurs - un type d'injection SQL où l'attaquant collecte des données principalement par le biais de messages d'erreur affichés (ou absents) sur l'application attaquée. L'injection SQL basée sur les erreurs a quelques types en soi.
  • Injection SQL hors bande (OOB) - un type d'injection SQL où un attaquant ne peut pas utiliser la même application pour attaquer et collecter les résultats. Un type d'injection SQL moins connu, mais un type néanmoins.

Les attaquants utilisent chacun des types décrits ci-dessus pour atteindre différents objectifs - l'injection SQL classique est utile si l'attaquant a des connaissances implicites sur le fonctionnement interne du système, l'injection SQL basée sur l'union peut être utile si l'attaquant combine les résultats d'un couple d' SELECTinstructions dans un seul ensemble de résultats, l'injection SQL basée sur les erreurs est utilisée lorsque l'application est "silencieuse" (ce qui signifie qu'elle ne renvoie aucune réponse, de sorte que l'attaquant recherche des modifications de fonctionnalité lors de l'émission de certains types de requêtes)

Protéger votre application contre l'injection SQL

À ce stade, vous devriez avoir une assez bonne compréhension de ce qu'est l'injection SQL et de ses types, mais comment protégez-vous vos applications d'une telle attaque ? Heureusement, il existe quelques moyens bien connus de réduire le risque qu'une telle vulnérabilité soit exploitée maintenant ou à l'avenir :

  • Maintenez à jour tous les composants de votre application et installez tous les correctifs de sécurité nécessaires . La mise à jour des composants de l'application doit constituer une première ligne de défense efficace contre toute attaque.
  • Valider l'entrée - comme le succès d'une telle attaque dépend fortement de l'entrée que l'attaquant fournit au système, la validation des entrées pourrait être un autre moyen efficace d'empêcher les attaques par injection SQL maintenant et à l'avenir.
  • Utilisez des instructions paramétrées - l'utilisation d'instructions paramétrées est peut-être le moyen le plus efficace de se défendre contre les attaques par injection SQL. Lorsque des instructions paramétrées sont utilisées, le serveur interprète toujours l'entrée utilisateur comme une valeur et ne l'analyse pas. Par exemple:
/* Prepare MySQL statement */

if (!($statement = $mysqli->prepare(
	"SELECT customerID 
    FROM orders 
    WHERE item = ?"
    ))) {
    	echo "Failed: (" . $mysqli->errno . ") " . $mysqli->error;
}

/* 
Bind variables to statement as parameters using bind_param().
The type (first) parameter can take integers (i), doubles (d), 
strings(s), and blobs (b).
*/

$purchasedItem = 'ice cream';
if (!$statement->bind_param("s", $purchasedItem)) {    
    echo "Failed: (" . $statement->errno . ") " . $statement->error;
}

/* Execute prepared MySQL statement */
if (!$statement->execute()) {
    echo "Failed: (" . $statement->errno . ") " . $statement->error;
}

 

  • Utilisez un pare-feu d'application Web - l'utilisation d'un pare-feu d'application Web (WAF) est une autre ligne de défense efficace, car les pare-feu d'application Web sont généralement capables d'identifier et de bloquer plusieurs types d'attaques, y compris l'injection SQL, les scripts intersites et la falsification de requête intersite. , contrôle d'accès cassé, exposition de données sensibles, attaques DoS ou DDoS, entre autres. Un pare-feu d'application Web doit idéalement être utilisé avec des instructions paramétrées pour une efficacité et une défense maximales contre l'injection SQL et d'autres types d'attaques.
  • Utilisez des applications axées sur la sécurité fournies par MySQL ou d'autres fournisseurs - MySQL offre un moyen de protéger vos applications contre l'injection SQL au niveau de l'entreprise en utilisant un outil MySQL Enterprise Firewall, qui peut fournir une protection en temps réel contre les menaces spécifiques à la base de données. De plus, plusieurs autres fournisseurs méritent d'être discutés plus en détail (à part MySQL, certains d'entre eux incluent MariaDB, MinervaDB, MongoDB, Oracle, Manynines et d'autres). Pourtant, pour ce billet de blog, nous n'allons pas trop entrer dans les détails.
  • Évitez d'accorder des privilèges administratifs lorsqu'ils ne sont pas nécessaires - éviter d'accorder des privilèges inutiles peut être une forteresse efficace contre de nombreux types d'attaques, y compris l'escalade de privilèges et, bien sûr, l'injection SQL. Par exemple, si l'utilisateur qui utilise votre application n'a besoin que de certains droits d'accès, pensez à n'accorder que les autorisations nécessaires pour effectuer les tâches. Appliquer la règle du moindre privilège au niveau de la base de données est également une excellente idée.

Garder ces points à l'esprit devrait aider votre application à bien fonctionner.

Protéger votre base de données de l'injection SQL

L'utilisation d'instructions préparées, l'utilisation de plugins axés sur la sécurité fournis par MySQL, le fait d'éviter d'accorder des privilèges administratifs inutiles et de prendre en compte les autres précautions susmentionnées devraient vous mettre, vous et votre base de données, sur la bonne voie. Cependant, si vous souhaitez approfondir MySQL et comprendre pourquoi les requêtes SQL fonctionnent comme elles le font et pourquoi l'utilisation, par exemple, d'un pare-feu d'application Web (WAF) peut vous protéger contre de nombreux types d'attaques, y compris l'injection SQL, considérez ceci :

  • Considérez chaque requête comme une tâche importante composée de tâches plus petites.
  • Les tâches de la requête peuvent être observées en exécutantSHOW PROFILE FOR QUERY [query id here];

S'il est utilisé correctement, dans la plupart des cas, la sortie vous fournira ce que la requête a fait et la durée de la tâche. Vous pourrez également observer un tas de choses intéressantes, notamment obtenir des réponses à des questions telles que :

  • Combien de temps la requête a-t-elle mis pour démarrer ?
  • Combien de temps la requête a-t-elle pris pour vérifier les autorisations ?
  • Combien de temps a-t-il fallu à MySQL pour ouvrir les tables ?
  • Combien de temps a-t-il fallu à MySQL pour initialiser les processus ?
  • Combien de temps a-t-il fallu à MySQL pour optimiser, préparer et (ou) exécuter la requête ?
  • Combien de temps a-t-il fallu à MySQL pour vous renvoyer les données à consulter ?
  • Combien de temps a-t-il fallu à MySQL pour terminer la requête, fermer les tables, libérer des éléments ?

Certaines des réponses à ces questions pourraient vous aider à comprendre pourquoi l'injection SQL fonctionne comme elle le fait. Par exemple, relancez une SHOW PROFILE FOR QUERYrequête et vous verrez ce qui suit :

Une partie de la sortie de la requêteSHOW PROFILE FOR QUERY

La ligne marquée indique que juste après le début de l'exécution de la requête, MySQL vérifie les autorisations. Vous souvenez-vous de ce dont nous avons discuté plus tôt ? Vous devez éviter d'accorder des privilèges inutiles précisément pour cette raison - si le compte MySQL ciblé par un attaquant n'a pas suffisamment d'autorisations, la requête échouera. Étant donné que la fonctionnalité des SHOW PROFILE FOR QUERYrequêtes n'entre pas dans le cadre de cet article de blog, nous n'allons pas entrer dans trop de détails ici, mais vous pouvez voir comment et pourquoi il est important de suivre les conseils ci-dessus.

La plupart des conseils décrits ci-dessus sont également applicables dans l'espace de la base de données :

  • La mise à jour de tous les composants de votre application inclut phpMyAdmin.
  • La validation des entrées inclut la validation de toutes les entrées, pas seulement la validation des entrées qui font partie de quelque chose.
  • Les instructions paramétrées peuvent (et doivent) être utilisées dans toutes les occasions où des requêtes SQL sont utilisées pour éviter l'exfiltration de données de certaines tables.
  • L'utilisation d'un pare-feu d'application Web et l'utilisation de plugins axés sur la sécurité peuvent empêcher les attaquants d'accéder à votre base de données.
  • Éviter d'accorder trop de privilèges peut également sauver votre base de données d'un désastre (reportez-vous à l'exemple ci-dessus)

Tenez compte des conseils ci-dessus et vous devriez être sur la bonne voie pour atténuer les problèmes d'injection SQL qui pourraient affecter votre base de données maintenant ou à l'avenir.

Sommaire

Comme vous pouvez le constater, la plupart des conseils qui vous aident à sécuriser vos applications et vos bases de données contre l'injection SQL sont assez généraux et simples. Cependant, sécuriser vos bases de données à partir de l'injection SQL n'est pas sorcier non plus - gardez à l'esprit les directives décrites ci-dessus, et vous devriez être prêt à partir ! 

Source : https://arctype.com/blog/sql-injection/

#sql 

Cayla  Erdman

Cayla Erdman

1596441660

Welcome Back the T-SQL Debugger with SQL Complete – SQL Debugger

When you develop large chunks of T-SQL code with the help of the SQL Server Management Studio tool, it is essential to test the “Live” behavior of your code by making sure that each small piece of code works fine and being able to allocate any error message that may cause a failure within that code.

The easiest way to perform that would be to use the T-SQL debugger feature, which used to be built-in over the SQL Server Management Studio tool. But since the T-SQL debugger feature was removed completely from SQL Server Management Studio 18 and later editions, we need a replacement for that feature. This is because we cannot keep using the old versions of SSMS just to support the T-SQL Debugger feature without “enjoying” the new features and bug fixes that are released in the new SSMS versions.

If you plan to wait for SSMS to bring back the T-SQL Debugger feature, vote in the Put Debugger back into SSMS 18 to ask Microsoft to reintroduce it.

As for me, I searched for an alternative tool for a T-SQL Debugger SSMS built-in feature and found that Devart company rolled out a new T-SQL Debugger feature to version 6.4 of SQL – Complete tool. SQL Complete is an add-in for Visual Studio and SSMS that offers scripts autocompletion capabilities, which help develop and debug your SQL database project.

The SQL Debugger feature of SQL Complete allows you to check the execution of your scripts, procedures, functions, and triggers step by step by adding breakpoints to the lines where you plan to start, suspend, evaluate, step through, and then to continue the execution of your script.

You can download SQL Complete from the dbForge Download page and install it on your machine using a straight-forward installation wizard. The wizard will ask you to specify the installation path for the SQL Complete tool and the versions of SSMS and Visual Studio that you plan to install the SQL Complete on, as an add-in, from the versions that are installed on your machine, as shown below:

Once SQL Complete is fully installed on your machine, the dbForge SQL Complete installation wizard will notify you of whether the installation was completed successfully or the wizard faced any specific issue that you can troubleshoot and fix easily. If there are no issues, the wizard will provide you with an option to open the SSMS tool and start using the SQL Complete tool, as displayed below:

When you open SSMS, you will see a new “Debug” tools menu, under which you can navigate the SQL Debugger feature options. Besides, you will see a list of icons that will be used to control the debug mode of the T-SQL query at the leftmost side of the SSMS tool. If you cannot see the list, you can go to View -> Toolbars -> Debugger to make these icons visible.

During the debugging session, the SQL Debugger icons will be as follows:

The functionality of these icons within the SQL Debugger can be summarized as:

  • Adding Breakpoints to control the execution pause of the T-SQL script at a specific statement allows you to check the debugging information of the T-SQL statements such as the values for the parameters and the variables.
  • Step Into is “navigate” through the script statements one by one, allowing you to check how each statement behaves.
  • Step Over is “execute” a specific stored procedure if you are sure that it contains no error.
  • Step Out is “return” from the stored procedure, function, or trigger to the main debugging window.
  • Continue executing the script until reaching the next breakpoint.
  • Stop Debugging is “terminate” the debugging session.
  • Restart “stop and start” the current debugging session.

#sql server #sql #sql debugger #sql server #sql server stored procedure #ssms #t-sql queries

Cayla  Erdman

Cayla Erdman

1596448980

The Easy Guide on How to Use Subqueries in SQL Server

Let’s say the chief credit and collections officer asks you to list down the names of people, their unpaid balances per month, and the current running balance and wants you to import this data array into Excel. The purpose is to analyze the data and come up with an offer making payments lighter to mitigate the effects of the COVID19 pandemic.

Do you opt to use a query and a nested subquery or a join? What decision will you make?

SQL Subqueries – What Are They?

Before we do a deep dive into syntax, performance impact, and caveats, why not define a subquery first?

In the simplest terms, a subquery is a query within a query. While a query that embodies a subquery is the outer query, we refer to a subquery as the inner query or inner select. And parentheses enclose a subquery similar to the structure below:

SELECT 
 col1
,col2
,(subquery) as col3
FROM table1
[JOIN table2 ON table1.col1 = table2.col2]
WHERE col1 <operator> (subquery)

We are going to look upon the following points in this post:

  • SQL subquery syntax depending on different subquery types and operators.
  • When and in what sort of statements one can use a subquery.
  • Performance implications vs. JOINs.
  • Common caveats when using SQL subqueries.

As is customary, we provide examples and illustrations to enhance understanding. But bear in mind that the main focus of this post is on subqueries in SQL Server.

Now, let’s get started.

Make SQL Subqueries That Are Self-Contained or Correlated

For one thing, subqueries are categorized based on their dependency on the outer query.

Let me describe what a self-contained subquery is.

Self-contained subqueries (or sometimes referred to as non-correlated or simple subqueries) are independent of the tables in the outer query. Let me illustrate this:

-- Get sales orders of customers from Southwest United States 
-- (TerritoryID = 4)

USE [AdventureWorks]
GO
SELECT CustomerID, SalesOrderID
FROM Sales.SalesOrderHeader
WHERE CustomerID IN (SELECT [CustomerID]
                     FROM [AdventureWorks].[Sales].[Customer]
                     WHERE TerritoryID = 4)

As demonstrated in the above code, the subquery (enclosed in parentheses below) has no references to any column in the outer query. Additionally, you can highlight the subquery in SQL Server Management Studio and execute it without getting any runtime errors.

Which, in turn, leads to easier debugging of self-contained subqueries.

The next thing to consider is correlated subqueries. Compared to its self-contained counterpart, this one has at least one column being referenced from the outer query. To clarify, I will provide an example:

USE [AdventureWorks]
GO
SELECT DISTINCT a.LastName, a.FirstName, b.BusinessEntityID
FROM Person.Person AS p
JOIN HumanResources.Employee AS e ON p.BusinessEntityID = e.BusinessEntityID
WHERE 1262000.00 IN
    (SELECT [SalesQuota]
    FROM Sales.SalesPersonQuotaHistory spq
    WHERE p.BusinessEntityID = spq.BusinessEntityID)

Were you attentive enough to notice the reference to BusinessEntityID from the Person table? Well done!

Once a column from the outer query is referenced in the subquery, it becomes a correlated subquery. One more point to consider: if you highlight a subquery and execute it, an error will occur.

And yes, you are absolutely right: this makes correlated subqueries pretty harder to debug.

To make debugging possible, follow these steps:

  • isolate the subquery.
  • replace the reference to the outer query with a constant value.

Isolating the subquery for debugging will make it look like this:

SELECT [SalesQuota]
    FROM Sales.SalesPersonQuotaHistory spq
    WHERE spq.BusinessEntityID = <constant value>

Now, let’s dig a little deeper into the output of subqueries.

Make SQL Subqueries With 3 Possible Returned Values

Well, first, let’s think of what returned values can we expect from SQL subqueries.

In fact, there are 3 possible outcomes:

  • A single value
  • Multiple values
  • Whole tables

Single Value

Let’s start with single-valued output. This type of subquery can appear anywhere in the outer query where an expression is expected, like the WHERE clause.

-- Output a single value which is the maximum or last TransactionID
USE [AdventureWorks]
GO
SELECT TransactionID, ProductID, TransactionDate, Quantity
FROM Production.TransactionHistory
WHERE TransactionID = (SELECT MAX(t.TransactionID) 
                       FROM Production.TransactionHistory t)

When you use a MAX() function, you retrieve a single value. That’s exactly what happened to our subquery above. Using the equal (=) operator tells SQL Server that you expect a single value. Another thing: if the subquery returns multiple values using the equals (=) operator, you get an error, similar to the one below:

Msg 512, Level 16, State 1, Line 20
Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression.

Multiple Values

Next, we examine the multi-valued output. This kind of subquery returns a list of values with a single column. Additionally, operators like IN and NOT IN will expect one or more values.

-- Output multiple values which is a list of customers with lastnames that --- start with 'I'

USE [AdventureWorks]
GO
SELECT [SalesOrderID], [OrderDate], [ShipDate], [CustomerID]
FROM Sales.SalesOrderHeader
WHERE [CustomerID] IN (SELECT c.[CustomerID] FROM Sales.Customer c
INNER JOIN Person.Person p ON c.PersonID = p.BusinessEntityID
WHERE p.lastname LIKE N'I%' AND p.PersonType='SC')

Whole Table Values

And last but not least, why not delve into whole table outputs.

-- Output a table of values based on sales orders
USE [AdventureWorks]
GO
SELECT [ShipYear],
COUNT(DISTINCT [CustomerID]) AS CustomerCount
FROM (SELECT YEAR([ShipDate]) AS [ShipYear], [CustomerID] 
      FROM Sales.SalesOrderHeader) AS Shipments
GROUP BY [ShipYear]
ORDER BY [ShipYear]

Have you noticed the FROM clause?

Instead of using a table, it used a subquery. This is called a derived table or a table subquery.

And now, let me present you some ground rules when using this sort of query:

  • All columns in the subquery should have unique names. Much like a physical table, a derived table should have unique column names.
  • ORDER BY is not allowed unless TOP is also specified. That’s because the derived table represents a relational table where rows have no defined order.

In this case, a derived table has the benefits of a physical table. That’s why in our example, we can use COUNT() in one of the columns of the derived table.

That’s about all regarding subquery outputs. But before we get any further, you may have noticed that the logic behind the example for multiple values and others as well can also be done using a JOIN.

-- Output multiple values which is a list of customers with lastnames that start with 'I'
USE [AdventureWorks]
GO
SELECT o.[SalesOrderID], o.[OrderDate], o.[ShipDate], o.[CustomerID]
FROM Sales.SalesOrderHeader o
INNER JOIN Sales.Customer c on o.CustomerID = c.CustomerID
INNER JOIN Person.Person p ON c.PersonID = p.BusinessEntityID
WHERE p.LastName LIKE N'I%' AND p.PersonType = 'SC'

In fact, the output will be the same. But which one performs better?

Before we get into that, let me tell you that I have dedicated a section to this hot topic. We’ll examine it with complete execution plans and have a look at illustrations.

So, bear with me for a moment. Let’s discuss another way to place your subqueries.

#sql server #sql query #sql server #sql subqueries #t-sql statements #sql

Ruth  Nabimanya

Ruth Nabimanya

1621850444

List of Available Database for Current User In SQL Server

Introduction

When working in the SQL Server, we may have to check some other databases other than the current one which we are working. In that scenario we may not be sure that does we have access to those Databases?. In this article we discuss the list of databases that are available for the current logged user in SQL Server

Get the list of database
Conclusion

#sql server #available databases for current user #check database has access #list of available database #sql #sql query #sql server database #sql tips #sql tips and tricks #tips