FranceHack Index du Forum
S’enregistrerRechercherFAQMembresGroupesConnexion
[SQL] Structured Query Language

 
Répondre au sujet    FranceHack Index du Forum » Débutant » Failles Web Sujet précédent
Sujet suivant
[SQL] Structured Query Language
Auteur Message
Mugiwara
Invité

Hors ligne




Message [SQL] Structured Query Language Répondre en citant
Description :




Une injection SQL consiste à insérer ou " injecter " une requête SQL via les données d'entrées du client à l'application.
Une fois l'injection SQL réussi, vous pouvez accéder au fichiers sensible d'une base de données ( Insérer/Mise à jour/ Supprimer), effectuer des opération d'administration sur la base de donnée ( comme éteindre le SGBD), récupérer le contenu d'un fichier présent sur les fichiers système de la DMBS, dans certains cas vous pouvez même donner des ordres au système d'exploitation.
Les SQL injections sont des types d'attaques dans lesquels des commandes SQL sont injecter dedans le plan de données dans l'ordre pour effectuer des commande SQL prédéfinies.


Modélisation des menaces :


Les SQL injections permettent au pirates de cacher leur identités, altérer les données existantes, les publication de reniement de cause comme l'annulation de transaction ou le changement de soldes, causent l'apparition de toute les données ou deviennent indisponible et vous devenez l'administrateur de la base de données du serveur.
Les SQL injections sont très compatible avec les application PHP et ASP en raison de la prévalence des vieux interfaces fonctionnelles. En raison de la nature de l'interface de programmation disponible, les applications J2EE et ASP.NET sont moins susceptibles au faille de type SQL facilement exploitables.
La gravité des attaques par injection SQL est limitée par l'habileté et l'imagination de l'attaquant, et dans une moindre mesure, la défense des contre-mesures approfondies, comme l'autorisation de bas privilèges tels que la connexion à la base de données,etc. En conclusion, les injections SQL ont un fort impact pour l'application.


Description :


Les failles SQL apparaissent quand :
Des données qui entrent dans un programme à partir d'une source non fiable.Les données ont eu l'habitude de dynamiquement construire une question SQL.


Les principales conséquences sont les suivantes :
Confidentialité : Généralement, les base de données SQL contiennent des informations sensibles, les pertes de données confidentielles est un problème fréquent avec les vulnérabilité SQL.
Authentification : Si des commandes nuisible pour une applications en SQL sont utilisées pour trouver des noms d'utilisateur et des mots de passe, il peut être possible de se connecter à un système avec un certains nom d'utilisateur sans pour autant connaître le mot de passe.
Autorisation : Si l'information d'autorisation est maintenu dans une base de données SQL, il peut être possible de change cette information grâce à l'exploitation d'une faille SQL.Intégrité : Tout comme il peut être possible d'obtenir des informations sensible, il est également possible d'y apporter des modification ou même de les supprimer avec une injection SQL.



Généralement, les base de données SQL contiennent des informations sensibles, les pertes de données confidentielles est un problème fréquent avec les vulnérabilité SQL.
Si des commandes nuisible pour une applications en SQL sont utilisées pour trouver des noms d'utilisateur et des mots de passe, il peut être possible de se connecter à un système avec un certains nom d'utilisateur sans pour autant connaître le mot de passe.



Exemples :


Exemple 1 :


En SQL :






select id, firstname, lastname from authors









Si un fourni :






Firstname: evil'ex
Lastname: Newman









la chaîne de requête deviendra :






select id, firstname, lastname from authors where forename = 'evil'ex' and surname ='newman'








que la base de données essaye d'exécuter comme :







Incorrect syntax near il' as the database tried to execute evil. 










Une version sécrurisée de l'instruction SQL ci-dessus en Java donnerait :






String firstname = req.getParameter("firstname");
String lastname = req.getParameter("lastname");
// FIXME: do your own validation to detect attacks
String query = "SELECT id, firstname, lastname FROM authors WHERE forename = ? and surname = ?";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, firstname );
pstmt.setString( 2, lastname );
try
{
ResultSet results = pstmt.execute( );
}










Exemple 2 :


Le code suivant en C# construit dynamiquement et exécute une requête SQL qui cherche les éléments correspondant à un nom bien précis.
La requête limite l'affichage d’éléments par compte à partir du nom d'utilisateur de la personne qui se connecte.






...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = "'" 
     + userName + "' AND itemname = '"
     + ItemName.Text + "'";
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
...









La requête que ce code à l'intention d'exécuter est :






SELECT * FROM items
WHERE owner = 
AND itemname = ;









Cependant, parce que la requête est construite dynamiquement par la concaténation d'une chaîne de requête de base constante et une chaîne d'entrée de l'utilisateur, la requête ne se comporte correctement si itemName ne contient pas de guillemet simple (').
Si une attaquant avec le nom d'utilisateur Wiley entre la chaîne "name" OR 'a'='a pour itemName, la requête devient la suivante :






SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';






L'ajout de OR 'a'='a comme condition ramène la clause WHERE toujours à vrai, alors la requête devient logiquement :






SELECT * FROM items;









Cette simplification de la requête permet à l'attaquant de contourner l'exigence que la requête ne renvoi qu'à un utilisateur authentifié ; la requête renvoi maintenant tout e les entrées stockées dans la table des éléments, quel que soit le propriétaire spécifié.




Exemple 3 :


Cet exemple examine les effet d'une différente valeur malicieuse transmise à la requête construire et exécutée dans l'exemple 1.
Si un attaquant avec le nom d’utilisateur hacker rentre la chaîne "name'); DELETE FROM items; --" comme itemName, la requête devient les deux requête suivante :






SELECT * FROM items
WHERE owner = 'hacker'
AND itemname = 'name';

DELETE FROM items;

--'














Beaucoup de serveurs de base de données, y compris Microsoft SQL Server 2000, permettent l'exécution de plusieurs commandes à la fois séparées par des points-virgules.Biens que les résultats de cette chaîne résulte à une erreur dans Oracle et d'autre base de données qui n'autorisent pas l'exécution des batch des instructions séparées par des points-virgules, dans les bases de données, ceux qui autorisent l'exécution des batch, ces types d'attaques permettent à l'attaquant d'exécuter des commandes arbitraires contre la base de données.




Notez que la paire traînant de traits d'union (-), qui précise à la plupart des bases de données que le reste de la déclaration doit être traité comme un commentaire et n'est pas exécutée. Dans ce cas, le caractère de commentaire sert à éliminer ce qui se trouve à sa droite. Dans une base de données où les commentaires ne sont pas autorisés, l'attaquant pourrait encore être efficace en utilisant un truc similaire à celui présenté dans l'exemple 1. Si un attaquant rentre la chaîne :
"name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a
les trois déclaration suivante seront créés :






SELECT * FROM items 
WHERE owner = 'hacker'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';









Une approche traditionnelle à la prévention des attaques par injections SQL est de les traiter comme un problème de validation d'entrée et accepter uniquement les caractères d'un liste blanche des valeurs sûres ou de créer une liste noire listant les valeurs potentiellement malveillantes. La liste blanche peut être un moyen très efficace de faire respecter les règles de validation d'entrée strictes, mais la paramétrisation des instructions SQL ne nécessitent pas beaucoup d'entretien et peuvent offrir plus de garanties en matière de sécurité.
Comme c'est presque toujours le cas, la liste noire est criblé de lacunes qui font qu'elle est inefficace pour la prévention d'attaques par injections SQL. Par exemple les attaquants peuvent exploiter :
Domaines cibles qui ne sont pas quotté (')
Trouver des façons de contourner la sécurité de blocage de certains méta-caractères
Utiliser des procédures stockées pour cacher des méta-caractères
Échapper manuellement au caractères dans la saisie aux questions SQL peut aider, mais il ne fera pas votre demande sécurisée d'attaques d'injection SQL.
Une autre solution couramment proposée pour faire face à des attaques par injection SQL est d'utiliser des procédures stockées.
Bien que les procédures stockées aident à la prévention contre certains types d'attaque par injections SQL, ils ne parviennent pas à protéger contre de nombreuses autre. Par exemple, la procédure PL / SQL suivante est vulnérable à la même attaque par injection SQL montré dans le premier exemple.






procedure get_item (
itm_cv IN OUT ItmCurTyp,
  usr in varchar2,
  itm in varchar2)
is
  open itm_cv for ' SELECT * FROM items WHERE ' ||
 'owner = '''|| usr || 
  ' AND itemname = ''' || itm || '''';
end get_item;








Les procédures de stockage aident généralement à la prévention des attaques par injections SQL en limitant les types de déclarations qui peuvent être transmises à leurs paramètre. Cependant, il y a beaucoup de façon de contourner les limitations et les nombreuses déclaration intéressantes qui peuvent encore être transmises à des procédures stockées. Encore une fois, les procédures stockées peuvent empêcher certains exploits, mais il ne sécuriserons pas votre application contre les attaques de type injection SQL.


Ven 11 Avr - 20:36 (2014)
Publicité






Message Publicité
PublicitéSupprimer les publicités ?

Ven 11 Avr - 20:36 (2014)
Azrakel
Invité

Hors ligne




Message [SQL] Structured Query Language Répondre en citant
Très bon tuto même si un débutant risque de ne rien piger x)


Ven 11 Avr - 21:07 (2014)
Mugiwara
Invité

Hors ligne




Message [SQL] Structured Query Language Répondre en citant
Je le pense aussi x)


Ven 11 Avr - 21:39 (2014)
Contenu Sponsorisé






Message [SQL] Structured Query Language

Aujourd’hui à 03:06 (2016)
Montrer les messages depuis:    
Répondre au sujet    FranceHack Index du Forum » Débutant » Failles Web Toutes les heures sont au format GMT + 2 Heures
Page 1 sur 1

 

Portail | Index | créer un forum gratuit | Forum gratuit d’entraide | Annuaire des forums gratuits | Signaler une violation | Conditions générales d'utilisation
Powered by phpBB © 2001, 2005 phpBB Group
Design by Freestyle XL / Music Lyrics.Traduction par : phpBB-fr.com