Secure programming/fr

From Lazarus wiki
Jump to navigationJump to search

│ 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 allons l'admettre 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 ? 

* * * *  A FINIR  * * *

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 ?

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.

Dénis de service

Denial of Service (DoS) is one of the hardest types of attacks to prevent. The reasons are:

  • 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.
  • Every system resource can be a possible denial of service, like opening sockets, reading files or allocating memory.
  • Removal of files like a kernel module can cause a big problem. I don't get this line --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.
  • 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. --BigChimp 19:32, 24 July 2011 (CEST) --BigChimp 19:32, 24 July 2011 (CEST).
  • Almost any type of exploit can result in a denial of 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..

In the above denial of service example: 

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

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.

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.

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).

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. 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.

Injection

There are many ways to inject some type of code into our programs. As we saw at the above example:

User Input: 

 Please enter your name: a' OR 1=1

Inside the code: 

... 
write('Please enter your name: '); 
readln(sName); 
Query1.SQL.Add('SELECT Password FROM tblUsers WHERE Name='#32 + sName + #32); 
...

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.

For example, we could check if sName has spaces. If so, do not continue checking for the rest of the 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:

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;

The function return true if we have a valid structure of content given by the AllowChars in the S variable. Please note that this function is only a proof of concept and may need more work in order to be fully used.

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

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

The regular expression removes any non valid chars from the string and returns to us the purged string. 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).

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).

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).

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 (''), 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.

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

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

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

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. 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.

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.

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=107585"