|
|||||||
| Actualités L'actualité des sociétés du secteur informatique |
|
|
Publicité | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
Outils de la discussion |
|
|
#1 |
|
Expert Confirmé Sénior
![]() ![]() Inscription : juillet 2009 Messages : 1 553 ![]() |
Le Top 25 des erreurs de programmation les plus dangereuses, d'après SANS et MITRE
L'institut SANS, spécialisé dans la sécurité informatique des ordinateurs et des réseaux, accompagné de la corporation MITRE qui se définit comme une organisation non lucrative d'utilité nationale, agissant pour l'intérêt des citoyens américains dans la protection des ressources informatiques du pays ; vient de publier son Top 25 des erreurs de programmation les plus dangereuses de l'année. Cette liste a été établie avec le concours des deux groupes, mais aussi grâce à la collaboration d'experts en sécurité informatique de toutes nationalités, et de diverses firmes. Ce top répertorie les erreurs de programmation les plus critiques et les plus courantes qui peuvent rendre un programme vulnérable. Elles sont généralement faciles à repèrer et à exploiter. Voici ce Top 25, les codes associés aux erreurs correspondent à leurs identifiants dans la base de données CWE de la MITRE (qui recence leur virulence, leur nature, leur fonctionnement, etc.) : Programming Error Category: Insecure Interaction Between Components [1] CWE-79: Failure to Preserve Web Page Structure ('Cross-site Scripting') [2] CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection') [4] CWE-352: Cross-Site Request Forgery (CSRF) [8] CWE-434: Unrestricted Upload of File with Dangerous Type [9] CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection') [17] CWE-209: Information Exposure Through an Error Message [23] CWE-601: URL Redirection to Untrusted Site ('Open Redirect') [25] CWE-362: Race Condition Programming Error Category: Risky Resource Management [3] CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') [7] CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [14] CWE-98: Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion') [12] CWE-805: Buffer Access with Incorrect Length Value [13] CWE-754: Improper Check for Unusual or Exceptional Conditions [15] CWE-129: Improper Validation of Array Index [16] CWE-190: Integer Overflow or Wraparound [18] CWE-131: Incorrect Calculation of Buffer Size [20] CWE-494: Download of Code Without Integrity Check [21] CWE-770: Allocation of Resources Without Limits or Throttling Programming Error Category: Porous Defenses [5] CWE-285: Improper Access Control (Authorization) [6] CWE-807: Reliance on Untrusted Inputs in a Security Decision [10] CWE-311: Missing Encryption of Sensitive Data [11] CWE-798: Use of Hard-coded Credentials [19] CWE-306: Missing Authentication for Critical Function [22] CWE-732: Incorrect Permission Assignment for Critical Resource [24] CWE-327: Use of a Broken or Risky Cryptographic Algorithm Certaines de ses erreurs vous sont-elles familières ? Les avez-vous déjà vues ou commises ? Comment se protèger contre ces dangers ? Dans ce Top, quelle erreur vous parait la plus fréquente ? Laquelle vous parait la plus critique et dangereuse ?Source : Le Top 25 publié par SANS (avec détails et explications en anglais) |
|
|
00
|
|
|
#2 | |||
|
Membre Expert
![]() Inscription : janvier 2007 Messages : 1 452 ![]() |
Citation:
Citation:
http://cwe.mitre.org/data/definitions/362.html Citation:
a plus |
|||
|
|
00
|
|
|
#3 |
|
Invité régulier
![]() Bastien Inscription : septembre 2008 Messages : 39 ![]() |
Session was already closed.
Lol |
|
|
00
|
|
|
#4 |
|
Nouveau Membre du Club
![]() Inscription : février 2007 Messages : 103 ![]() |
Bonjour tout le monde,
Je suis développeur Java j2ee, Est 'il possible de suivre des formations en France sur ce type de sujet ? Y a t il en France ou en Europe des organismes qui dispensent ce genre de formation ? Merci pour vos réponses . |
|
|
00
|
|
|
#5 |
|
Membre Expert
![]() ![]() |
J'ai un peu la même question en tête. Parce que pour nombre des ces failles, je connais a peine le nom, et encore moins la façon de les éviter. Je pense que tous les sites que je fais sont bourrés de failles, mais je n'en ai strictement aucune idée...
|
|
|
00
|
|
|
#6 |
|
Membre Expert
![]() ![]() Ingénieur développement logiciels Inscription : juillet 2002 Messages : 1 180 ![]() |
Je trouve personnellement que l'erreur de programmation la plus sérieuse reste tout bêtement les requêtes SQL DELETE avec des oublis au niveau de la clause WHERE. Voir oubli complet du WHERE. C'est radical et ne laisse pas de traces
__________________
Attention le .NET sur PDA peut causer des chutes de cheveux |
|
|
00
|
|
|
#7 |
|
Membre du Club
![]() Inscription : février 2008 Messages : 37 ![]() |
Le SQL injection (Ah la bonne programmation à la VB6)
Ne pas contrôler les upload (Le serveur est à plat, sais pas pourquoi , m.. un virus)Donner des infos aux hackers grâce aux exceptions levées par le serveur Web (pages d'erreurs standard, ne pas trapper les exceptions du serveur lui même, ...). Les dépassements de buffers et compagnies, c'est du classique, normalement maitrisés par n'importe quel développeur ( j'ai rempli la mémoire).
|
|
|
00
|
|
|
#8 | |
|
Membre Expert
![]() ![]() |
Citation:
Je me souviens pas avoir eu besoin d'utiliser ca depuis 4-5 ans ni en java ni en PHP... Et ca ne rappelle rien du tout des techniques pour empêcher les explosion de buffer. Est ce que ca ne serait pas une bonne idée sur développez de faire(ou de mettre un lien si ca existe déjà) une page avec ce genre d'erreur commune et de donner une explication simple ainsi qu'un exemple de bonne pratique a mettre en oeuvre pour toutes ces failles ? |
|
|
|
00
|
|
|
#9 |
|
Membre Expert
![]() Inscription : juillet 2006 Messages : 1 396 ![]() |
Permet moi d'être inquiet pour tes clients.
|
|
|
00
|
|
|
#10 |
|
Membre habitué
![]() Inscription : août 2005 Messages : 269 ![]() |
Hmmm.
Je n'ai jamais rencontré une de ces erreurs depuis des années que je programme!! d'où avez vous sorti tout cela? |
|
|
00
|
|
|
#11 | |
|
Membre habitué
![]() Inscription : décembre 2009 Messages : 123 ![]() |
Citation:
|
|
|
|
00
|
|
|
#12 |
|
Membre Expert
![]() Inscription : janvier 2007 Messages : 1 452 ![]() |
@pmithandir, pour java je ne sais pas, mais pour php tu as des cours de sécurisation disponible dans DVP.
@deadalnix +1 @IDontLikeYou, Je t'aimes bien bisou ; ) Intéressant, tu as quelques mots clefs en tête pour faire des recherches sur le net ? |
|
|
00
|
|
|
#13 |
|
Invité de passage
![]() Inscription : août 2009 Messages : 3 ![]() |
La plupart des applications contiennent des dizaines d'erreur, on estime à
une erreur pour 1500 lignes de code. Cependant la plupart des erreurs n'ont aucunes conséquences soit parce qu'elles sont masquées par le reste, soit parce qu'elle n'ont lieu qu'une fois tous les 10 ans, soit parce qu'elle ne touche pas la sécurité. Même un programme ultra vérifié contient des bugs. ( ex l'explosion d'ariane 5). Connaitre et éviter les erreurs les plus courantes du sondage semble pourtant très important car la plupart touche la sécurité !! |
|
|
00
|
|
|
#14 |
|
Membre Expert
![]() damien Inscription : mars 2005 Messages : 1 680 ![]() |
Ariane 5 c'est surtout une erreur de conception avec le choix d'un mauvais langage.
__________________
dam's |
|
|
00
|
|
|
#15 |
|
Membre Expert
![]() ![]() |
Les sites sur lequels je travaille sont tous des sites fermés type intranet, SAAS.
Et le dernier soucis était la securité en général. Après, je ne sais pas, mais si ca se trouve je fait déjà en sorte de ne pas faire la plupart des erreurs par habitudes ou parce que le framework ne me le permet pas... Les injections SQL par exemple je crois que ca en fait parti. |
|
|
00
|
|
|
#16 |
|
Membre Expert
![]() Inscription : janvier 2007 Messages : 1 452 ![]() |
C'est pour cela qu'on aime bien les fw : D
@dams78 tu peux préciser un peu c'est intéressant. |
|
|
00
|
|
|
#17 |
|
Membre Expert
![]() Inscription : juillet 2006 Messages : 1 396 ![]() |
Excuse moi, mais c'est juste crétin. Toute personne renseignée sur la sécurité te confirmera cela : une part importante des attaques viens de l'intérieur.
|
|
|
00
|
|
|
#18 |
|
Membre actif
![]() Inscription : septembre 2004 Messages : 492 ![]() |
|
|
|
00
|
|
|
#19 | |
|
Membre Expert
![]() ![]() |
Citation:
Enfin, il n'en demeure pas moins que je trouve que l'on manque d'endroit ou l'on centralise toutes les informations de manières visible pour assurer des bonnes pratiques. Comment gérer des documents uploadés sur un serveur, le répertoire est il accessible aux utilisateurs ou non, etc... Comment éviter certaines injection de variable dans une page avec l'url... Les applications PHP que j'ai vu étaient en général basée sur des trucs qui faisait que c'était presque impossible de limiter les accès d'un mec qui connaissait le code. Avec des non sens comme, ajouter debug=1 dans l'url pour passer en mode debug... sans autre forme de procès... Bref, on est loin quand on est a ce niveau la de se poser la question d'un injection SQL... Surtout que... dans nombre d'applications ou les données ne sont pas critiques pour le client(par critique j'entends importance capitale pour le dev de l'entreprise ou pour des obligations de confidentialité légale) ils ne sont pas du tout prêt a mettre de l'argent dans la sécurité. C'est par définition le truc invisible qui coute cher et qui n'est jamais infaillible. Bref, aucune raison de payer pour cela... |
|
|
|
00
|
|
|
#20 |
|
Membre Expert
![]() Inscription : juillet 2006 Messages : 1 396 ![]() |
La sécurité, ça coute cher ?
Sans doute, mais il est clair, que c'est économique sur le moyen/long terme. Imagine qu'un salarié mal intentionné supprime tous les données de l'entreprise ? Essaye de chiffre cela, ça va te donner une idée. La question de la dépense sécuritaire est simple : est-ce que c > p*r ? Ou c est le coût de la mise ne place de la sécurité, p la probabilité que la menace devienne effective et r le coût qu'engendre la réalisation de la menace. Si l'assertion ci dessus est vraie, alors il faut payer pour la sécurité. Et quand on se rend compte des valeurs de r dans certains cas, on sait pourquoi on paye. Il existe pas mal d'infos sur les failles classiques type sql injection. Mais la sécurité, ça se pense dans son ensemble (par exemple, c'est bien joli d"utiliser un algo de cryptage super béton avec un clef très longue, mais si le pass est marqué avec un post-it collé sur l'écran . . .). La sécurité est un domaine dans lequel j'ai des compétences (attention, pas en cryptanalyse, qui est un domaine associé mais différent. je ne appesantis pas la dessus car ce n'est pas le but du topic). Quand je vois le temps passé à acquérir mes compétences (ça va taper super large, car elles vont de notions psychologiques, à l'algorithmique, l'informatique bas niveau, le réseau, des bases mathématiques solides, etc . . .) et le temps que je passe régulièrement à les mettre à jour, ou bien je suis particulièrement inefficace, ou bien une simple page, ça permet d'éviter les pièges classiques, mais ça ne suffit largement pas. |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com