Difference between revisions of "Secure programming/fr"

From Lazarus wiki
Jump to navigationJump to search
m (Fixed syntax highlighting)
 
(6 intermediate revisions by one other user not shown)
Line 40: Line 40:
 
===Débordement de tampon===
 
===Débordement de tampon===
 
C'est quand une donnée dépasse la quantité de mémoire qui lui est allouée :
 
C'est quand une donnée dépasse la quantité de mémoire qui lui est allouée :
−
<syntaxhighlight>var
+
<syntaxhighlight lang=pascal>var
 
   iNums : array [0..9] of integer;
 
   iNums : array [0..9] of integer;
 
   ...
 
   ...
Line 61: Line 61:
 
Le déni de service n'est pas seulement un problème de réseau, il peut exister dans d'autres formes :  
 
Le déni de service n'est pas seulement un problème de réseau, il peut exister dans d'autres formes :  
  
−
<syntaxhighlight>procedure Recurse;
+
<syntaxhighlight lang=pascal>procedure Recurse;
 
begin
 
begin
 
   while (True) do
 
   while (True) do
Line 77: Line 77:
  
 
Par exemple :
 
Par exemple :
−
<syntaxhighlight>...
+
<syntaxhighlight lang=pascal>...
 
   begin
 
   begin
 
     while True do
 
     while True do
Line 97: Line 97:
  
 
Dans le code :
 
Dans le code :
−
<syntaxhighlight>...
+
<syntaxhighlight lang=pascal>...
 
Write('SVP, entrez votre nom : ');
 
Write('SVP, entrez votre nom : ');
 
ReadLn(sName);
 
ReadLn(sName);
Line 170: Line 170:
 
=== Débordement de tampon ===
 
=== Débordement de tampon ===
 
Si nous revenons à notre exemple de :
 
Si nous revenons à notre exemple de :
−
<syntaxhighlight>var
+
<syntaxhighlight lang=pascal>var
 
   iNums: array [0..9] of Integer;
 
   iNums: array [0..9] of Integer;
 
   ...
 
   ...
Line 184: Line 184:
  
 
Ainsi l'exemple devrait être changé en :
 
Ainsi l'exemple devrait être changé en :
−
<syntaxhighlight>var
+
<syntaxhighlight lang=pascal>var
 
   iNums: array [0..9] of Integer;
 
   iNums: array [0..9] of Integer;
 
   
 
   
Line 211: Line 211:
  
 
Pour la première option, nous pouvons faire ce qui suit (copié depuis la documentation FPC) :
 
Pour la première option, nous pouvons faire ce qui suit (copié depuis la documentation FPC) :
−
<syntaxhighlight>Program Example74;
+
<syntaxhighlight lang=pascal>Program Example74;
 
   
 
   
 
{ Program to demonstrate the Val function. }
 
{ Program to demonstrate the Val function. }
Line 227: Line 227:
  
 
Voici un petit exemple pour un petit ''readln'' comme procédure pour des nombres entiers.
 
Voici un petit exemple pour un petit ''readln'' comme procédure pour des nombres entiers.
−
<syntaxhighlight>program MyReadln;
+
<syntaxhighlight lang=pascal>program MyReadln;
 
uses  
 
uses  
 
   CRT;
 
   CRT;
Line 286: Line 286:
  
 
=== Quels sont les risques de sécurité dans les débordement  ? ===
 
=== Quels sont les risques de sécurité dans les débordement  ? ===
−
Overflow of memory can allow arbitrary CPU code to be executed and users may run whatever type of code they wish, and nothing can stop them.
+
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 ==
 
== Dénis de service ==
−
Denial of Service (DoS) is one of the hardest types of attacks to prevent. The reasons are:
+
Le deni de service (DoS) est l'un des types d'attaque les plus difficile à empêcher, les raisons sont :  
−
* The denial of service can even be executed without any exploitable bug, like using the "ping" program on a lot of machines to DoS a machine connected to the internet.
+
* 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.
−
* Every system resource can be a possible denial of service, like opening sockets, reading files or allocating memory.
+
* 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.
−
* Removal of files like a kernel module can cause a big problem. ''I don't get this line --[[User:BigChimp|BigChimp]] 19:32, 24 July 2011 (CEST)''
+
* La suppression de fichiers comme un module du noyau peut causer un gros problème. (''I don't get this line --[[User:BigChimp|BigChimp]] 19:32, 24 July 2011 (CEST)'')
−
* Lack of configuration or wrong configuration can cause a denial of service as well if it allows vulnerable resources to be misused.
+
* 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.
−
* Too much permissions or lack of them ''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. --[[User:BigChimp|BigChimp]] 19:32, 24 July 2011 (CEST) --[[User:BigChimp|BigChimp]] 19:32, 24 July 2011 (CEST)''.
+
* 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. --[[User:BigChimp|BigChimp]] 19:32, 24 July 2011 (CEST)''
−
* Almost any type of exploit can result in a denial of service.
+
* Presque tout type d'exploit peut aboutir à un déni de service.
  
−
So as you can see, a denial of service can be almost anything that can stop the system from working as it should, because of exploitation or buggy code or just a program that captures system resources..
+
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.
  
−
In the above denial of service example:
+
Dans l'exemple de déni de service du dessous :
−
<syntaxhighlight>procedure Recurse;
+
<syntaxhighlight lang=pascal>procedure Recurse;
 
begin
 
begin
 
   while (True) do
 
   while (True) do
Line 308: Line 308:
 
end;</syntaxhighlight>
 
end;</syntaxhighlight>
  
−
I created also a stack overflow (another type of buffer overflow), that caused the computer to need more memory resources to continue executing the code.
+
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.
  
−
Any system resource that is available to the program can be abused by not returning it back to the system when the program "does not need it anymore". The keeping of system resources like memory, or sockets remove from other programs the ability to perform some of their actions. That way most programs will stop their execution and report an error, and some will hang and keep on looking for the system resources.  
+
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.
  
−
Please note that some of the abuse of system resources exists because of a bug in the programming, like waiting for a 150k buffer, while the actual buffer is only 2 bytes, and when the program is still looking for the 150k buffer a new request for a 150k buffer is made etc.. until the system is not able to answer any of the requests anymore (this is a known type of attack).
+
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).
  
−
A good workaround for this bug is to limit how many non full buffers can be allocated at one time. If the buffer is not full after a timeout, it should be free.  
+
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.
−
However, this solution will also cause a Denial of Service, because the communication will stop anyway at some point, or a slow connection can cause data loss.
+
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==
 
==Injection==
−
There are many ways to inject some type of code into our programs. As we saw at the above example:
+
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.
  
−
User Input:
+
Entrée de l'utilisateur :
−
   Please enter your name: a' OR 1=1
+
   SVP, veuillez entrer votre nom : a' OR 1=1
  
 
Inside the code:
 
Inside the code:
−
<syntaxhighlight>...  
+
<syntaxhighlight lang=pascal>...  
−
write('Please enter your name: ');  
+
write(' SVP, veuillez entrer votre nom : ');  
 
readln(sName);  
 
readln(sName);  
 
Query1.SQL.Add('SELECT Password FROM tblUsers WHERE Name='#32 + sName + #32);  
 
Query1.SQL.Add('SELECT Password FROM tblUsers WHERE Name='#32 + sName + #32);  
 
...</syntaxhighlight>
 
...</syntaxhighlight>
  
−
The injection occurred when we do not filter our code (sanitize is the more professional word :)): this means checking that we receive only the exact type of input that we are looking for, and nothing else.
+
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.
  
−
For example, we could check if ''sName'' has spaces. If so, do not continue checking for the rest of the variable.
+
Par exemple, nous pourrions contrôler si ''sName'' contient des espaces. Si c'est ainsi, ne pas contrôler le reste de la variable.
−
This helps if the username is only allowed to be one word consisting of letters, maybe the tick sign (') and maybe even underscore (_) and then it's over. If we enter a number, this should be illegal (unless we wish to use "hacker like language" (leetspeak), or allow the use of numbers.
 
  
−
There are many ways to sanitize your data. The less effective one (but often used) is the following:
+
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 ===
 
=== Désinfection inefficace ===
−
<syntaxhighlight>function ValidVar (const S: AnsiString; AllowChars: TCharset): Boolean;
+
<syntaxhighlight lang=pascal>function ValidVar (const S: AnsiString; AllowChars: TCharset): Boolean;
 
var
 
var
 
   i: Word;
 
   i: Word;
Line 352: Line 353:
 
end;</syntaxhighlight>
 
end;</syntaxhighlight>
  
−
The function return true if we have a valid structure of content given by the ''AllowChars'' in the ''S'' variable.
+
La fonction retourne true si nous avons un contenu correspondant à celui spécifié par ''AllowChars'' dans la variable ''S''.
−
Please note that this function is only a proof of concept and may need more work in order to be fully used.
+
Veuillez noter que cette fonction est seulement une preuve du concept et demande plus de travail pour être pleinement utilisable.
  
−
Another way to do the same is to use regular expression as the following (this is a Proof of concept only in the Perl language. FPC does not have a fully supported regular expression engine that allows to modify strings):
+
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;
 
  $sName =~ s/[^a-z0-9\_\']//gi;
  
−
The regular expression removes any non valid chars from the string and returns to us the purged string.
+
L'expression régulière retire tous les caractères invalides de la chaîne et retourne la chaîne purgée.
−
Please note that as far as I know, this regular expression will work also in ereg engines, but with minimal adjustments (''g'' flag instructs Perl to replace all the matching patterns found. ''i'' is for ''case insensitivity'').
+
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).
  
−
Now when we know that our input is valid, we need to see what is the use of the variable content. If the variable content is going into a database, or a cgi script, or anything else that has its own syntax, we must escape the content according to the non-allowed or control characters of the relevant language (e.g. SQL for databases).
+
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).
  
−
There are many ways to escape this type of content. Let's assume for now that this content is going into a query of a database. Now first of all we must make sure that our escaping will not increase our data size above the length limits of our database fields. Because if they will, then we can change from an injection to a data loss/denial of server/buffer overflow problems (a respected database usually will truncate the data and sometimes not in a good location).  
+
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.
  
−
Usually the only escaping we need to do for using a string in a database is to escape only the ticks (') char (although some databases may have problems with more chars then ticks). So all we should do is to represent ticks in a way that will not effect the database engine, like backslash tick (\') or double every single tick to two ticks (<nowiki>''</nowiki>), or maybe even use another char that will be replace the ticks in the query and replace again when we will show it to the user.
+
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 (<nowiki>''</nowiki>), 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 ===
 
=== Restriction des entrées avec les paramètres de requêtes SQL ===
−
Obligatory [http://xkcd.com/327/ visual illustration].
 
  
−
After we made sure that we respect the limits, we can continue in our attempts. To escape the code we can use several approaches. A less debugging friendly way, but a sure way of correct escaping is to use the parameters technique:
+
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 !)
  
−
<syntaxhighlight>Query1.SQL.Add('SELECT Password FROM tblUsers WHERE Name=?');
+
<syntaxhighlight lang=pascal>Query1.SQL.Add('SELECT Password FROM tblUsers WHERE Name=?');
 
Query1.Parameters.Add(sName);
 
Query1.Parameters.Add(sName);
 
if (Query1.Execute) then
 
if (Query1.Execute) then
 
...</syntaxhighlight>
 
...</syntaxhighlight>
  
−
This technique allows the database engine to escape the parameter in a way that we could use the content without any problems of illegal characters. Also, some databases have increased performance for repeated calls to this code as it can prepare an internal statement with parameters for this.
+
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.
−
The down side is that we can never debug the outcome of the query. That is, we can not see how the content of ''sName'' embedded in the SQL statement, and we can never see if our query was correct because of that.
+
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.
  
−
However, once you have tested the query without parameters, adding the parameters is quite easy, so in practice, this problem is not as big as it seems.
+
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 ==
 
== Code efficace ==
Line 409: Line 408:
 
* http://www.securiteam.com/securityreviews/5UP010A6AA.html  
 
* http://www.securiteam.com/securityreviews/5UP010A6AA.html  
 
* http://www.securiteam.com/securityreviews/5GP0E2K7FO.html
 
* http://www.securiteam.com/securityreviews/5GP0E2K7FO.html
−
<br/>
 

Latest revision as of 13:38, 26 February 2020

│ 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 :

Déni de service:

Injection SQL :

Retrieved from "http://wiki.freepascal.org/index.php?title=Secure_programming/fr&oldid=133217"