Secure programming/fr

│ English (en) │ français (fr) │ polski (pl) │

Avant-propos

Cette page de wiki tente d'enseigner une approche différente dans la façon créer un logiciel. La page utilise des exemples très simples pour montrer que beaucoup de problèmes peuvent être profitables pour prendre l'avantage dans le but de créer une attaque de sécurité sur un ordinateur, un programme ou un système en entier.

Veuillez noter que le document est seulement un début sur la technologie sur comment écrire un meilleur et un code un peu plus sécurisé code, mais il n'essaye pas d'être un guide complet sur la façon de le faire. En fait c'est seulement un résumé de la façon dont nous devons voir notre code et programme , et comment éviter beaucoup de problèmes communs.

Veuillez vous rappeler que ce document vise un meilleur codage et n'est pas là pour montrer comment hacker(bidouiller) ou craquer (casser la protection) de programmes.

Ne faites pas confiance aux entrées

En développant un programme, il est probable qu'il interagira avec un utilisateur de différentes façons, même s'il se limite à lire des fichiers dans le système et présenter les données.

Généralement à l'école et à l'université, quand quelqu'un commence à écrire des programmes, cette personne apprend comment recevoir des données, les professeurs disent généralement à cette personne "supposez que les données que vous recevez sont valide".

Mais Nous ne pouvons pas faire confiance à toute entrée que nous ne pouvons pas contrôler car son contenu est inconnu et pourrait exploiter une vulnérabilité dans notre logiciel.

Lire depuis un fichier est lire depuis une source non sûre, de même que les entrées d'un utilisateur ou les données provenant d'un réseau par exemple.

Pourquoi ne dois-je pas croire aux entrées ?

Pour comprendre pourquoi une entrée est dangereuse, nous devons d'abord comprendre ce qu'est une entrée.

Une entrée peut être lue depuis un clavier, le mouvement de la souris ou des clics de souris, ou depuis la lecture ou l'acceptation d'information de différente façons telles que les flux de données ou même les fonctions système. En fait, tout ce qu'obtient votre programme de l'extérieur est une entrée.

Peu importe le type d'entrée : par exemple, un utilisateur ou un autre système peut nous donner une mauvaise entrée, et les raisons peuvent être intentionnelles ou une erreur. Vous ne pouvez pas contrôler cette entrée, et la raison principale est que vous ne pouvez pas deviner ce que l'entrée sera.

Les résultats peuvent être des "données" vides (NULL) que l'utilisateur nous fournit, un nombre qui est hors de l'étendue attendue, ou une plus grande quantité de caractères que nous attendions, ou même une tentative de changer l'adresse de la variable qui accepte L'entrée de l'utilisateur. Nous ne pouvons tout simplement pas savoir ce que l'utilisateur va fournir.

Tout manipulation "non-sûre" de l'entrée peut aboutir à

• la récupération d'information critique que l'utilisateur n'est pas autorisé à voir,
• la modification non permise de donnée,
• la corruption de donnée,
• l'interruption (crash, plantage) du programme lui-même.

A quel type de problèmes pouvons-nous nous attendre ?

Pour chaque type de bug, vous pouvez sans doute trouver un type d'attaque, mais je vais vous donner une petite liste de types d'attaque communs, au lieu d'écrire beaucoup de types d'attaque.

Le types d'attaque les plus communs sont :

Débordement de tampon

C'est quand une donnée dépasse la quantité de mémoire qui lui est allouée :

var
  iNums : array [0..9] of integer;
  ...
  FillChar (iNums[-1], 100, #0);
  ...
  for i := -10 to 10 do
  readln (iNums[i]);
  ...

Dans cet exemple, nous pouvons voir que le tableau statique iNums n'accepte que 10 nombres, alors que nous entrons dans cette variable 21 nombres.

Veuillez noter que le compilateur sait signaler de tels cas, qui ne sont que des formes peu élaborées.

Si l'utilisateur peut entrer de la donnée qui est envoyée dans un tampon, il peut entrer certaines valeurs pouvant être interprétées par les instructions en code machine, qui seront écrites en dehors de notre tampon. L'ordinateur pourra alors exécuter ce code au lieu du code qui aurait dû être là.

C'est le débordement de tampon.

Attaque par déni de service (DoS)

Le déni de service n'est pas seulement un problème de réseau, il peut exister dans d'autres formes :

procedure Recurse;
begin
  while (True) do
    begin
      Recurse;
    end;
end;

Cette procédure s'exécutera jusqu'à ce que le système soit à court de ressources car il alloue plus de mémoire de pile à chaque récursion, cela provoquera l'arrêt de réponse du système, ou même le crash. Bien que certains systèmes, comme GNU/Linux, tentera de vous donner la possibilité d'arrêter le programme, cela prendra un certain temps pour se faire.

Veuillez remarquer que cela n'est qu'un exemple statique, mais nous pouvons faire une attaque DoS sur un système en exécutant ce code.

Une autre attaque DoS connue est le manque de libération de ressources système telle que la mémoire, les sockets, les descripteurs de fichiers, ...

Par exemple :

...
  begin
    while True do
      begin
        Getmem(OurPtr, 10);
        OurPtr := Something;
      end;
  end.

Cet exemple montre une allocation de mémoire (Getmem est comme malloc en langage C ; il réserve de la mémoire pour utilsiation), mais nous sortons de l'exécution sans avoir libérer la mémoire après emploi.

Injections

Quand l'utilisateur nous donne une entrée avec laquelle nous travaillons sans l'avoir assainie, l'utilisateur peut mettre dedans des marque SQL ou du code (comme du script, ou du code machine) par exemple, qui amènera notre programme à réaliser quelque action indésirable (p.ex. supprimer des enregistrements/tables, retourner des données protégées telles que des structures de bases de données/tables, utilisateur et mot de passe, contenu de dossier ou de fichier ou même exécuter un programme sur l'ordinateur).

Un exemple d'injection SQL :

Entrée d'utilisateur :

 SVP, entrez votre nom : a' OR 1=1

Dans le code :

...
Write('SVP, entrez votre nom : ');
ReadLn(sName);
Query1.SQL.Add('SELECT Password FROM tblUsers WHERE Name='#32 + sName + #32);
...

En soumettant cette instruction SQL avec l'entrée de l'utilisateur, il résultera de l'ajout de OR 1=1 dans la requête passée à la base de donnée : dans ce cas, la condition sera toujours vraie et l'utilisateur aura obtenu un éccès au programme et pourra connaître la liste des mots de passe (NdT : on fait l'hypothèse que ces derniers sont enregistrés en clair, mauvaise idée).

Accès à vos données et modifications

Ce n'est pas uniquement votre programme qui aura accès aux données qu'il utilise. Si vous stockez de la donnée dans des fichiers ou des bases de données (distantes), un attaquant peut obtenir l'accès à travers le système d'exploitation (et/ou la base de données et/ou la couche réseau/protocole de base de données).

Chiffrement : est-ce suffisant ?

Pour contrer la menace décrite ci-dessus, les programmeurs utilise souvent le chiffrement, il peut être utilisé pour fournir :

• la protection de la confidentialité des données
• la non-répudiation (est-ce que la donnée a été créée par la personne qui le prétend) et l'intégrité (la donnée est-elle inchangée), en utilisant des mécanismes supplémentaires de signature numérique/hachage).

ensemble pour

• la communication des données
• stockage/récupération des données

Si vous utilisez ces méthodes, vos données ne sont toutefois pas automatiquement sûres.

Il y a de multiples attaques possibles sur les données chiffrées :

• attaque sur des algorithmes mal sécurisés ou leur implémentation (p.ex. en utilisant une attaque avec du texte brut connu)
• attaque sur les clés de chiffrement (p.ex. en faisant une rétro-analyse de votre programme, si vous stocker des clés dans un fichier ou en dur dans le programme, ou en corrigeant le programme pour intercepter les clés/mots de passe entrés par l'utilisateur).

Si vous ne savez pas exactement ce que vous allez faire (et vous ne saurez pas, à moins d'avoir une formation en cryptographie), svp utilisez (par ordre décroissant de préférence) :

• des bibliothèques réputées qui sont maintenues/corrigées (p.ex. les bibliothèque internes de FPC, et des bibliothèques telles que DCPCrypt ou des bibliothèques externes comme OpenSSL ou cryptlib) qui utilise des protocoles réputés et largement utilisés qui utilisent des algorithmes réputés et largement utilisés.
  • Utilisez p.ex. Trusted Authentication/SSPI pour la connectivité SQL Server/Firebird pour éviter l'envoi de mots de passe a travers le câble (dans Firebird >= 2.0 : en texte clair !) et s'appuie sur la sécurité du système d'exploitation pour l'authentification.
  • Utilisez Cryptlib ou OpenSSL avedc Synapse pour implémenter SSL/TSL au lieu d'une solution personnelle.
• des protocoles et APIs réputés et largement utilisés au lieu de solutions personnelles. Ces protocoles doivent utiliser des algorithmes de cryptographie/hachage bien compris et largement employés. Exemples :
  • GPG/PGP
  • TLS (SSL) avec PKI/CAs (de préférence ne faites pas confiance au CAs dont vous avez besoin, et réalisez des certificats d'authenthification client si votre analyse de la menace l'exige).
  • SSH (e.g. avec clé d'authentification publique/privée, si nécessaire avec renforcement par des périphrases pour les clés)
  • Dans Windows, utilisez l'API pour obtenir l'utilisateur actuellement authentifié. Si vous mettez en application la sécurité adaptée du système (longueur de mot de passe, modification, accès physiques etc), vous n'aurez pas besoin de gérer votre propore mécanisme de nom de connexion/mot de passe au niveau de l'application.
• des algorithmes bien connus de crypto/hachage (tels que AES/Rijndael, 3DES et SHA512). Soyez conservateur dans les algorithmes que vous acceptez (p.ex. MD5 n'est pas sûr dans la signature de message).

Le chiffrement est une partie de l'ensemble possible des mesures de sécurité ; l'effort/l'argent dépensé doit être évalué comme faisant partie de l'analyse de la sécurité (voir plus bas).

Mythes et suppositions

De nombreux problèmes de sécurité existent à cause de l'ignorance d'importants avertissements et d'information donnés par le compilateur et par la conviction que votre programme ne contient pas de problème exploitable.

Voici quelques exemples pour ce type de problème :

Mythes:

• La sécurité par l'obscurité - Quand personne ne connaît un problème, personne ne peut en profiter ; p.ex. utiliser un nom de colonne obscur pour stocker des mots de passe dans votre base de données.
• Les langages de programmation sûrs : il y a des langages tels que Perl dont des gens pensent à tort qu'ils sont sûrs face aux débordements de tampon et autres vulnérabilité.
• Un mot de passe hachés est sûr - Un fichier qui a un mot de passe haché n'est pas sûr. (non traduit car incompris : ) Hash can only passed one and you can not retrieve the original data. I don't get this. Does the author mean that a hashed password can be retrieved by a brute force or rainbow table attack and that it therefore needs a salt, or multiple hash rounds? --BigChimp 16:19, 24 July 2011 (CEST).
• Personne ne peut casser mon programme - Penser que vous êtes le seul programmeur dans le monde qui écrive du code non fautif est sans doute un peu optimiste. Peut-être êtes-vous chanceux et vous avez juste écrit du code qui ne marche bien sans vulnérabilité de sécurité exploitable ...

Suppositions:

• L'équipe qualité va trouver et corriger mes bugs de sécurité.
• L'utilisateur (ou quelqu'un d'autre) n'attaquera pas mon programme ni ses données.
• Mon programme ne sera utilisé que pour son utilisation prévue.
• Toutes les exceptions peuvent rester en l'état (unhandled)

Analyse pour comprendre les menaces et la sécurité

En général, un programmeur (ou son employeur) devrait réaliser une analyse de toutes les menaces (depuis les accès physiques/attaques jusqu'aux attaques logiques et d'ingénierie sociales) qui devrait être faite sur le système entier (y compris l'infrastructure - système d'exploitation, base de données aussi bien que sur les machines physiques/câblage/batiments/connexions externes) pour analyser si vous n'avez pas laisser ouvert une brêche de sécurité qui est inacceptable (dans une perspective risque/bénéfice).

L'extension de cette analyse devrait dépendre de la valeur des données/processus que le système protège. Il est évident que cela est superflu d'analyser à fond la sécurité de votre maison quand vous développez un programme de loisir pout garder la trace de vos scores de bridge.

Bénéfices de cette sorte d'analyses :

• les risques restants après ces mesures de sécurité deviennent connus et explicites. Souvent, il y a des discussion sur les chances de survenue du risque, ou sur l'impact qui lui associé, mais la fait qu'il subsiste un vecteur d'attaque est au moins clair et les décisions peuvent être rendues basées sur cette information.
• vous pouvez loyalement facilement voir que les mesures sont sur-conçues (overengineered) ("too secure", gaspillage d'argent) ou sous-conçues ("pas assez sûres"). Si vous ne pouvez pas utiliser cette information maintenant, vous pouvez au moins apprendre d'elle pour d'autres projets, y compris de future maintenance/modification de votre programme.

Solutions spécifiques

Maintenant nous connaissons certains problèmes que nous allons rencontrés en développant des programmes, nous devrions apprendre à corriger ces problèmes. Tous les problèmes que nous avons vu au-dessus se manifestent en deux types : suppositions et manque de programmation sûre. Et pour apprendre à les corriger, nous devons d'abord apprendre à penser d'une manière différente que nous avions jusqu'à maintenant.

Débordement

Pour corriger le débordement de donnée, comme les tampons ou autre type d'entrée, nous avons besoin avant tout d'identifier le type de donnée dont nous avons besoin :

Débordement de tampon

Si nous revenons à notre exemple de :

var
  iNums: array [0..9] of Integer;
  ...
  FillChar(iNums[-1], 100, #0);
  ...
  for i := -10 to 10 do
    ReadLn(iNums[i]);
  ...

Nous voyons là une étendue qui a été dépassée par nos valeurs, sans même vérifier si l'index est correct.

Dans les tableaux dynamiques/ouverts de Pascal, nous pouvons connaître les limites de la mémoire allouée. Ainsi, il suffit juste de contrôler si la taille est trop petite ou trop grande pour notre tampon, et de limiter ce qu'elle doit accepter.

Ainsi l'exemple devrait être changé en :

var
  iNums: array [0..9] of Integer;
 
  ...
  FillChar (iNums[Low(iNums)], High(iNums), #0);
  ...
 
  for i := Low(iNums) to High(iNums) do
    ReadLn(iNums[i]);
  ...

Mais attendez, quelque n'est pas encore juste !

La routine ReadLn accepte une quantité illimitée de caractères et rien ne nous promet que cela sera un entier ou de l'étendue que nous pouvons gérer.

Débordement numérique

Alors qu'une chaîne en Pascal est un pur tableau (humm humm..pas vraiment, du moins pas en FreePascal, mais nous l'admettrons quelques temps, Ok ?) ainsi readln tentera de trouver et voir ce que sont ces limites et ne tentera pas de dépasser l'étendue que nous avons donné à ce type, mais les nombres ne sont pas pareils.

Les nombres ont des limites, un ordinateur/compilateur a des limites de toutes sortes concernant la mémoire et les nombres. Il peut attribuer une "petite" quantité de mémoire pour les nombres (virgule flottante et entiers). Et souvent, nous n'avons pas besoin d'une grande étendue de nombre à utiliser (tels que les booléens qui ne demandent que deux valeurs).

Dans l'exemples du dessus, nous pouvons avoir un dépassement de tampon qui provoquera une erreur de contrôle d'étendue qui nous donnera un mauvais nombre (problèmes de rappel(reminder) de drapeau de retenue... que je n'expliquerai pas ici), et nous avons un effet DoS, car notre programme s'arrêtera à ce point.

Donc que pouvons-nous faire pour régler cela ?

En premier lieu, nous pouvons désirer travailler avec une variable chaîne qui sera de la taille du nombre le plus grand +1 (pour le signe moins), ou nous pouvons créer notre propre procédure/fonction ReadLn qui se spécialisera avec le type entier.

Pour la première option, nous pouvons faire ce qui suit (copié depuis la documentation FPC) :

Program Example74;
 
{ Program to demonstrate the Val function. }
Var 
  I, Code: Integer; 
begin
  Val(ParamStr(1), I, Code);
  If Code <> 0 then
    Writeln('Error at position ', code, ' : ', Paramstr(1)[Code])
  else
    Writeln('Value : ', I);  
end.

Nous voyons là comment convertir une chaîne en un entier avec une gestion très simple de l'erreur. La fonction StrToInt peut aussi faire l'affaire mais il faudra traiter l'exception résultante d'une erreur.

Voici un petit exemple pour un petit readln comme procédure pour des nombres entiers.

program MyReadln;
uses 
  CRT;
 
procedure MyIntReadLn(var Param: Integer; ParamLength: Integer);
var
  Line: string; 
  ch: char;
  Error: Integer;
   
begin
  Line  := '';
 
  repeat
    ch := ReadKey;
    if (Length (Line) <> ParamLength) then
      begin
       if (ch in ['0'..'9']) then
        begin
          Line := Line + ch;
          write (ch);
        end
       else
       if (ch = '-') and (Length(Line) = 0) then
        begin
          Line := '-';
          write (ch);
        end;
       end;
       
     if (ch = #8) and (Length(Line) <> 0) then // backspace
      begin
       Line := Copy(Line, 1, Length(Line) - 1);
       gotoxy(WhereX - 1, WhereY);
       write(' ');
       gotoxy(WhereX - 1, WhereY);
      end;
   until (ch = #13);
 
   val(Line, Param, Error);
 
   if (Error <> 0) then
     Param := 0;
 
  writeln;
end;
 
var
  Num : Integer;
 
begin
  Write('Number: ');
  MyIntReadLn(Num, 2);
  WriteLn('The number is: ', Num);
end.

Veuillez noter que vous pouvez la faire mieux, et plus efficace si vous le voulez. C'est seulement un petit exemple pour montrer comment le faire.

Quels sont les risques de sécurité dans les débordement ?

Un dépassement de mémoire peut permettre l'exécution d'un code CPU arbitraire et que les utilisateurs peuvent exécuter quelque soit le type de code qu'il désire et rien ne peut les arrêter.

Dénis de service

Le deni de service (DoS) est l'un des types d'attaque les plus difficile à empêcher, les raisons sont :

• Le déni de service peut même être exécuté sans bug exploitable, comme en utilisant le programme "ping" sur un paquets de machines pour bloquer une machine connectée à Internet.
• Toute ressource système peut être la cible d'un possible DoS, comme l'ouverture d'une socket, la lecture de fichiers ou l'allocation de mémoire.
• La suppression de fichiers comme un module du noyau peut causer un gros problème. (I don't get this line --BigChimp 19:32, 24 July 2011 (CEST))
• Un manque de configuration ou une mauvaise configuration peut provoquer un déni de service s'il permet de mal employer des resources vulnérables.
• Trop de permissions ou un manque d'elles (I don't get that not enough permissions can be a problem. Neither too many, either? Is a security risk, obviously but not a DoS problem. --BigChimp 19:32, 24 July 2011 (CEST)
• Presque tout type d'exploit peut aboutir à un déni de service.

Donc comme vous pouvez le voir, un déni de service peut presque être n'importe quoi qui arrête le système dans ce qu'il devrait faire à cause de l'exploitation ou d'un code bugué ou juste un programme qui capture des ressources système.

Dans l'exemple de déni de service du dessous :

procedure Recurse;
begin
  while (True) do
    begin
      Recurse;
    end;
end;

J'ai créé un débordement de pile (un autre type de débordement de tampon), qui amène l'ordinateur à avoir besoin de plus de mémoire pour continuer à exécuter le code.

Toute ressource système disponible pour le programme peut être détournée en ne la rendant pas au système lorsque le programme «n'en a plus besoin». La conservation de ressources système comme la mémoire, ou des sockets enlève à d'autres programmes la possibilité d'effectuer certaines de leurs actions. De cette façon, la plupart des programmes arrêteront leur exécution et signaleront une erreur, et certains se bloqueront et continueront à chercher les ressources système.

Notez que l'utilisation abusive des ressources système existe à cause d'un bogue dans la programmation, comme l'attente d'un tampon de 150 Ko, alors que le tampon réel n'est que de 2 octets et que le programme cherche toujours le tampon de 150 Ko, une nouvelle demande d'un tampon de 150k est fait, etc. jusqu'à ce que le système ne soit plus en mesure de répondre à aucune des requêtes (c'est un type connu d'attaque).

Une bonne solution de contournement pour ce bogue est de limiter le nombre de buffers non complets peuvent être alloués en même temps. Si le tampon n'est pas plein après un délai, il devrait être libre. Toutefois, cette solution entraînera également un déni de service, car la communication s'arrêtera de toute façon à un certain moment, ou une connexion lente peut entraîner la perte de données.

Injection

Il y a de nombreuses façons d'injecter certain type de code dans vos programmes. Comme nous pouvons le voir dans l'exemple du dessus.

Entrée de l'utilisateur :

 SVP, veuillez entrer votre nom : a' OR 1=1

Inside the code:

... 
write('  SVP, veuillez entrer votre nom : '); 
readln(sName); 
Query1.SQL.Add('SELECT Password FROM tblUsers WHERE Name='#32 + sName + #32); 
...

L'injection se rencontre quand nous ne filtrons pas les données entrées dans notre code (assainir est un mot plus professionnel:)) : ceci signifie que nous recevons seulement ce qui a été exactement frappé de l'entrée que nous cherchons et rien d'autre.

Par exemple, nous pourrions contrôler si sName contient des espaces. Si c'est ainsi, ne pas contrôler le reste de la variable.

Ceci aide si le nom d'utilisateur peut être une seul mot contenant des lettres, peut-être une apostrophe et peut-être même un souligné et c'est tout. Si nous entrons un nombre, cela serait illégal.

Il ya plusieurs manière d'assainir votre donnée. La moins efficace (mais souvent utilisée) est la suivante :

Désinfection inefficace

function ValidVar (const S: AnsiString; AllowChars: TCharset): Boolean;
var
  i: Word;
begin
  i := 0;
  Result := True;
  
  while (Result) and (i <= Length(S)) do
  begin
    Inc(i);
    Result := S[i] in AllowChars;
  end;
end;

La fonction retourne true si nous avons un contenu correspondant à celui spécifié par AllowChars dans la variable S. Veuillez noter que cette fonction est seulement une preuve du concept et demande plus de travail pour être pleinement utilisable.

Une autre solution pour faire la même chose consiste à utiliser une expression régulière comme suit (c'est une preuve de concept seulement pour Pearl. FPC n'a pas un support complet des expressions régulières qui permet de modifier les chaînes) (NdT : alors pourquoi en parler ?) :

$sName =~ s/[^a-z0-9\_\']//gi;

L'expression régulière retire tous les caractères invalides de la chaîne et retourne la chaîne purgée. Veuillez noter qu'autant que je le sache, cette expression régulière tournera aussi dans le moteur ereg, mais avec des ajustements minimaux (le drapeau g demande à Pearl de remplacer tous les modèles correspondants trouvés. i est pour l'insensibilité à la casse).

Maintenant nous connaissons que notre entrée est valide, nous devons voir quel est l'utilisation du contenu de la variable. Si la variable va aller dans une base de données, ou un script CGI ou autre chose qui a sa propre syntaxe, nous devons éliminer du contenu les caractères de contrôle ou non permis du langage (p.ex. SQL pour les bases de données).

Il y a plusieurs façons d'échapper ce type de contenu. Supposons pour maintenant que ce contenu va aller dans une requête de base de données. Maintenant en premier lieu, nous devons nous assurer que notre échappement n'augmentera pas la taille au dessus de la longueur limite de notre champ de base de données. Parce s'il le font, alors nous passerons d'une injection à une perte de donnée/un déni de service/un débordement de tampon (une base de données respectée généralement tronque la donnée et parfois pas au bon endroit.

Généralement, ce que nous faisons pour utiliser une chaîne dans une base de données est seulement d'échapper l'apostrophe (certaines bases de données peuvent avoir des problèmes avec plus de caractères). Ainsi nous devons représenter l'apostrophe d'une façon qu'elle n'ait pas d'effet dans le moteur de la base de données, en le précédant d'une barre de fraction inverse (\') ou en doublant l'apostrophe (''), ou peut-être même en employant un autre caractère en remplacement dans la requête puis en le faisant le remplacement inverse lors de l'affichage à l'utilisateur.

Restriction des entrées avec les paramètres de requêtes SQL

Après nous être assuré du respect des limites, nous pouvons continuer dans nos tentatives. Pour échapper le code, nous pouvons utiliser plusieurs approches. Une approche sympa de moindre débogage, mais une façon sûre d'avoir un échappement correct est d'utiliser la technique des paramètres (NdT : ouf on y est !)

Query1.SQL.Add('SELECT Password FROM tblUsers WHERE Name=?');
Query1.Parameters.Add(sName);
if (Query1.Execute) then
...

Cette technique permet au moteur de base de données pour échapper le paramètre d'une manière que nous puissions utiliser le contenu sans problème de caractères illégaux. En outre, certaines bases de données ont augmenté les performances pour les appels répétés à ce code, car il peut préparer une déclaration interne avec des paramètres pour cela. Le mauvais côté est que nous ne pourrons jamais déboguer le resultat de la requête. Autrement dit, nous ne pouvons pas voir comment le contenu de sName intégré dans l'instruction SQL, et nous ne pouvons jamais voir si notre requête était correcte à cause de cela.

De toutes façons, une fois que vous avez testé la requête sans paramètre, l'ajout des paramètres est assez facile, donc en pratique, le problème n'est pas aussi grand qu'il n'y paraît.

Code efficace

Les mesures de sécurité mentionnées au dessus compliquent le code si vous avez utilisé le code le plus efficace pour obtenir les fonctionnalités voulues. Heureusement, vous pouvez parfois contourner les complications du code avec un framework/une bibliothèque qui traite cela. Par exemple : dans l'exemple DoS SQL, vous pouvez laisser le moteur de base de données traiter les données d'échappement en utilisant des requêtes paramétrées avec un petit coût pour avoir utiliser des paramètres dans votre code.

Toutefois, écrire des programmes efficaces en performance mais vulnérables en sécurité n'aidera personne mis à part des juristes en fiabilité et des experts en forensique.

Au-delà du document

Alors que j'ai tenté dans ce document quelques exemples courts et l'information sur la façon de créer un meilleur code, il y ad'autres problèmes qui ne sont pas évoqués dans ce document. Une partie d'entre eux sont les privilèges utilisateur pour l'exécution des programmes, les root kits système et autres problèmes que notre code doit prendre en considération (les variables d'environnement en sont un unique exemple).

Veuillez lire plus de ressources techniques telles que :

Débordement de tampon :

• http://www.securiteam.com/securityreviews/5QP0L0AFFS.html
• http://www.securiteam.com/securityreviews/5OP0B006UQ.html
• http://www.securiteam.com/securityreviews/5IP0G1P8AM.html
• http://www.securiteam.com/securityreviews/6Q00L00BFI.html
• http://www.securiteam.com/securityreviews/5UP0B0A60Y.html

Déni de service:

• http://www.securiteam.com/securityreviews/5AP0V0AA1W.html
• http://www.securiteam.com/securityreviews/6Z00T0K95O.html

Injection SQL :

• http://www.securiteam.com/securityreviews/5DP0N1P76E.html
• http://www.securiteam.com/securityreviews/5UP010A6AA.html
• http://www.securiteam.com/securityreviews/5GP0E2K7FO.html