• STATISTIQUES
  • Il y a eu un total de 0 membres et 18857 visiteurs sur le site dans les dernières 24h pour un total de 18 857 personnes!
    Membres: 2 466
    Discussions: 3 572
    Messages: 32 818
    Tutoriels: 77
    Téléchargements: 38
    Sites dans l'annuaire: 58


  • ANNUAIRE
  • [FR] PHP France
    Pour tout savoir sur le PHP, en français. Vous trouverez des tutoriels, des exemples, des astuces, toute la do...
    Hacking
    [EN] This is legal
    Basic: 10, Realistic: 5, Programming: 1, Bonus: 11, SQL: 2, Encryption: 6, Application: 4, User Contributed: 3
    Challenges
    [FR] Secuser
    Actualité de la sécurité informatique, fiches virus et hoax, alertes par email, antivirus gratui...
    Hacking
    [EN] Defcon
    Lancé en 1992 par Dark Tangent, DEFCON est la plus ancienne et la plus grande conférence underground de...
    Hacking
    [FR] NewbieContest
    Nous vous proposons une série de challenges regroupant plusieurs domaines allant de l'exploitation de fail...
    Hacking
    [FR] µContest
    µContest est un site de challenges de programmation, c'est à dire qu'il propose des épreu...
    Hacking
    [EN] Framework Metasploit
    Le Framework Metasploit est un logiciel gratuit, open source de tests de pénétration développ&ea...
    Vulnérabilités

  • DONATION
  • Si vous avez trouvé ce site internet utile, nous vous invitons à nous faire un don du montant de votre choix via Paypal. Ce don servira à financer notre hébergement.

    MERCI!




Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
[Sécurité] Secure Coding - Eviter les TOCTTOU
13-08-2014, 14h22
Message : #1
b0fh Hors ligne
Membre actif
*



Messages : 210
Sujets : 17
Points: 309
Inscription : Jul 2012
[Sécurité] Secure Coding - Eviter les TOCTTOU
Hello,

Aujourd'hui, un petit rappel sur les vulnérabilités de type TOCTTOU (Time-of-Check-to-Time-of-Use), et comment les éviter.

Une vulnérabilité TOCCTOU se présente lorsqu'on vérifie une condition (time-of-check) avant d'exécuter une action (time-of-use), de manière non-atomique, c'est-à-dire que l'état du système (donc le résultat de la condition) risque de changer entre ces deux opérations.

Le risque existe donc quand on manipule des structures de données partagées entre plusieurs threads, ou qu'on utilise de l'IPC (fichiers, pipes) en présence de process hostiles.

Dans ce cas, la mantra a appliquer est: "mieux vaut demander pardon que permission", i.e. exécuter l'action et traiter l'erreur si elle se produit, plutôt que d'essayer de l'empêcher à l'avance..

Dans un post récent, j'ai vu passer quelque chose du genre:

Code PYTHON :

if blah in some_collection:
    do_something_with(some_collection[blah])
else:
    some_other_thing()
 


Prenez l'habitude de faire plutôt:

Code PYTHON :

try:
  do_something_with(some_collection[blah])
except KeyError:
  some_other_thing()
 


ou, si vous ne désirez pas intercepter une KeyError lancée ailleurs dans do_something_with():

Code PYTHON :

try:
  b = some_collection[blah]
except KeyError:
  some_ither_thing()
  return

do_something_with(b)
 


En utilisant systématiquement les exceptions et les retours d'erreurs plutôt que les vérifications d'avance, vous éviterez ces vulnérabilités. Si l'API ne le permet pas, c'est que l'API n'est pas adaptée a la programmation concurrente et qu'il faut la changer !

Quand ce n'est pas possible, il faut essayer de rentre l'ensemble des opérations atomique, en utilisant par exemple un verrou.
+1 (8) -1 (0) Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)
N-PN
Accueil | Challenges | Tutoriels | Téléchargements | Forum | Retourner en haut