analyse et synthèse : CCWAPSS, OWASP Guide : a constructive critic

FRTable des Matières

ENTable of Contents

  1. Purpose
  2. CCWAPSS
  3. Official "OWASP Guide 2.0"
  4. Personal Advice
  5. Conclusion

1. Purpose top next section

FR

Le problème :
A la recherche d'un moyen de mesurer le niveau de sécurité d'un site ou serveur mutualisé, je suis tombé sur le document "CCWAPSS 1.1" (Nov. 2007) de Frédéric Charpentier, sur le site de sa société (xmcopartners.com), et j'y ai vu qu'il référençait le guide OWASP 3.0 ; à ma connaissance, le Guide actuel est toujours le 2.0 . J'ai donc mené ma petite enquête et il semble :

EN

The Problem:
While searching for a way to measure the security level of a website or mutualized server, I fell on this document "CCWAPSS 1.1" (Nov. 2007) from Frédéric Charpentier, on his company's website (xmcopartners.com), and I saw that he was referencing the OWASP Guide 3.0 ; to my humble knowledge, the current Guide is still the 2.0 . I subsequently led my little research and it seems:

FR

J'ai donc décidé d'en refaire une copie en format standardisé interopérable ODF, surtout qu'il existe depuis le 4 juillet 2007 un plugin pour MS Office ™ pour le format standard ODF (norme ISO 26300:2006).

EN

I thus decided to make an interoperable copy of it in Standardized ODF, especially given there is since 4th of July 2007 a plugin for MS Office ™ for the Standard ODF Format (Standard ISO 26300:2006).

FR

Si j'ai bien lu la licence de la FSF, j'ai donc généré une "copie transparente" sans modifications. J'ai envoyé le 4 janvier 2010 ce document ODT à l'éditeur du Guide, libre à lui d'en faire ce qu'il voudra. Vous pouvez le télécharger ici (PDF 1252 Ko).

EN

If I read well enough the FSF License, I thus generated a "transparent copy" without modifications. I sent this ODT document on the 4th of January 2010 to the Guide's Editor, free to him to use it or not. You may download it here (PDF 1252 KB).

FR

Pour établir cette nouvelle forme du document 2.0.1 sans rien y changer (sauf quelques typos évidentes), j'ai dû parcourir tout le document de la première à la dernière page. J'ai donc noté plusieurs points criticables.

EN

To build this new shape of the 2.0.1 document without making any changes (except some trivial typos), I had to parse all the document from the first to the last page. I thus noted down many criticable points.

2. CCWAPSS top previous next section

FR

Une fois établi que la référence au "Guide OWASP 3.0" est fautive et désigne en fait le "Guide OWASP 2.0.1 Blackhat++", la méthode, la formule, le score de CCWAPSS n'appellent pas de remarques particulières. Le système semble intéressant.

Il prévoit de calculer une note sur des critères communs, en affectant du modificateur 0 les critères satisfaisant aux "bonnes pratiques" d'OWASP, du modificateur de +1 les critères évalués comme "excellents" (ie, excédant les recommendations de bonnes pratiques d'OWASP) et des modificateurs négatifs (selon le niveau de risque associé) pour les critères qui "nécessitent amélioration". Cela ressemble à ce qui se fait dans les rapports d'audits classiques.

EN

Once established that the "OWASP Guide 3.0" reference is buggy, the CCWAPSS method doesn't pose problems. It aims at assessing a score on common criteria in a way similar to audit reports (modifier to more-than-nominal criteria etc)

FR

Le problème surgit dans la partie "2.3 Common criteria" qui définit ces "critères communs". On peut y lire en effet que les critères sont en fait des références à des sections complètes du Guide Owasp, qui sont elles-mêmes composées d'un nombre variable de points évoqués. Le document CCWAPSS ne permet donc pas de travailler directement ; il nécessite d'analyser aussi le Guide OWASP pour détailler les "critères communs".

De plus, il référence des sections numérotées du "Guide OWASP" alors que, justement, le problème majeur du Guide 2.0.1 Blackhat++ est que ses sections ne sont pas numérotées et ses pages non marquées comme appartenant à une section plutôt qu'à une autre (ce qui a motivé en partie ma transformation du document). Néanmoins, il est possible de débrouiller la situation en numérotant les sections en supposant que 12=Authentication (voir note 1 ).

EN

The problem appears in "2.3 COmmon criteria", where you'll read that CCWAPSS simply references complete sections of the OWASP Guide, themselves composed of various points. Thus it can't be used directly : you'll have to analyze the OWASP Guide to detail the "common criteria".
Moreover, CCWAPSS references numbered sections of the OWASP Guide while the later is not numbered and its pages not marked as belonging to a given section (one of the reasons why I transformed the document).

FR

Voici la liste des critères communs :

  1. Authentication (Guide section 12)
  2. Authorization (Guide section 13)
  3. User's Input Sanitization (Guide sections 21 Buffer Overflows, 15 Data Validation, 16 Interpreter Injection)
  4. Error Handling and Information Leakage (Guide section 18 Error Handling et 24 Configuration)
  5. Passwords/PIN Complexity (Guide section 12 de nouveau, 24 Configuration de nouveau)
  6. User's Data Confidentiality (Guide section 8 Handling eCommerce Payments, 12 Authentication de nouveau)
  7. Session mechanism (Guide section 14 Session Management, 23 Cryptography)
  8. Patch management (Guide section 27 Maintenance)
  9. Administration interface (Guide section 22 Administrative Interfaces)
  10. Communication security (Guide section 23 Cryptographye de nouveau)
  11. Third-Party services exposure (Guide section 24 Configuration de nouveau, 26 Deployment, 19 File System)

Comme on le voit,

En l'état, pour utiliser CCWAPSS un ensemble de critères détaillés spécifiques à chaque système analysé devra être construit (selon la plate-forme, selon le niveau de sécurité requis, selon le langage utilisé, selon le framework utilisé...)

(1) La numérotation n'est d'ailleurs pas complètement cohérente avec le Guide 2.0.1 en PDF ni avec ma version en ODF, car des sections "fantômes" ont été numérotées par l'auteur de CCWAPSS, comme la n° 5 "Security Architecture and Design" qui n'est en fait qu'une page de garde annonçant les sections suivantes.

EN

As you may see,

In current state, to use CCWAPSS a set of detailed criteria specific to each audited system must be built (depending on the used platform, security level required, language used, framework used...)

3. Official "OWASP Guide 2.0" top previous next section

FR

En fait, le Guide 2.0.1 contient des références manquantes ("see 0"), des redites, des erreurs, des typos, des copié-collé... C'est très étonnant pour un document qui a soi-disant été revu plusieurs fois et amendé. Je suis sans doute plus habitué qu'eux à établir de longues spécifications contractuelles cohérentes ;-)

EN

In fact, the OWASP 2.0.1 Guide contains missing references ("see 0"), repetitions, errors, typos, and copy-pastes... This is quite surprising for a document supposedly reviewed many times and amended. I'm probably more accustomed than them to write lengthy and coherent contractual specifications ;-)

FR

dans "Authentication", le code PHP page 118 censément illustratif des "multiple key lookups" est en fait une copié-collé de celui sur l'HTTP_REFERRER de la page suivante.
page 121 le "how to determine if you are vulnerable" (aux "default accounts") contient les deux dernières lignes de "how to protect yourself". Ce n'est pas la seule fois que la section "comment savoir si vous êtes vulnérable" contient en fait des recommendations...

Enfin, les sections "Cryptography", "Maintenance" et "Denial of Service" sont à mon humble avis complètement bidon.
De plus, le Guide se permet de donner des indications de style de codage sans aucun rapport avec la performance ni la sécurité (placement des accolades, indentation, casse des identifiants...) au risque de re-déclencher une guerre de clochers ;-)

EN

In "Authentication", the PHP code page 118 supposed to illustrate "multiple key lookups" is in fact a copy-paste of the one about HTTP_REFERER on the next page. Page 121 the "how to determine if you are vulnerable" contains the last two lines of the "how toprotect yourself". This is not the only occurence of "how to determine if you are vulnerable" sections contain in fact recommendations...
And last, the sections "Cryptography", "Maintenance" and "Denial of Service" are completely phoney IMHO.
Moreover, the Guide pretends to give coding style recommendations without any relationship to performance nor security (bracket location, indentation, identifiers case...) with the risk of triggering a new coding style war ;-)

FR

Concernant PHP, les "PHP Guidelines" sont plus ou moins bidon et contiennent des erreurs grossières. Elles devraient être complètement ré-écrites en conservant en point de mire que l'objectif est de construire des applications sûres, pas de pratiquer un style d'indentation ou un autre.
Par exemple, dès le début il est dit que le "PHP code is embedded in HTML" ; cette manière de faire, similaire au bon vieil ASP, n'est absolument pas la pratique de tout le monde. Dans mon cas, par exemple, le PHP n'est pas inclus dans le HTML, mais génère le HTML. Le point de vue développé remonte à PHP/FI version 2.0 et date quelque peu... ( Novembre 1997 pour être précis)

EN

About PHP, the "PHP Guidelines" are more or less phoney and contain gross mistakes. They should be completely rewritten. For instance, at the start it is said that "PHP code is embedded in HTML" ; this way of doing, similar to good ol' ASP, is absolutely not everyone's practice. In my case, for instance, PHP is not embedded in HTML, but generates the HTML. The point of view used dates back to PHP/FI version 2.0 and dates a little bit... (November 1997 to be precise)

FR

Quelques erreurs grossières relevées pour PHP :

EN

Below are some of the gross mistakes I found about PHP :

FR EN

5. Personal Advice top previous next section

FR

La section "Canonicalization" (avec une faute dans le titre et ipso facto dans la table des matières...) n'apporte aucun élément nouveau et devrait être mise à jour, surtout face à la nouvelle norme "ISO/IEC 13250-4:2009 Technologies de l'information -- Plans relatifs à des sujets -- Partie 4: Canonicalisation".

FR

Dans la section introductive, on pourrait aussi dire de PHP que "Applications targeting [J2EE] theoretically can run with few (if any) changes between any of the major vendors and on many platforms from Linux, AIX, MacOS X, or Windows. In practice, some tweaking is required, but complete re-writes are not required.", mais les auteurs préfèrent apparemment Java et ASP.Net à PHP. Les taux de performance du monde réel ne sont pas ceux qu'ils mentionnent. De plus, je ne suis pas certain que se comparer à C++ soit une excellente idée ;-)

EN

In the introductive section : it could also be said of PHP that "Applications targeting [J2EE] theoretically can run with few (if any) changes between any of the major vendors and on many platforms from Linux, AIX, MacOS X, or Windows. In practice, some tweaking is required, but complete re-writes are not required.", but the authors apparently prefer Java, J2EE or ASP.Net to PHP. The performance benchmarks done in the real world do not give out the same results as they do (ASP.Net vs PHP, vs Java, vs JSP). Moreover, I strongly doubt benchmarking against C++ is a good idea, C++ being slow compared to other compiled languages ;-)

FR

La promotion du seul modèle MVC, particulièrement inefficace et pataud, me paraît injustifiée.

EN

There is a huge promotion on the MVC model, which I find unjustified, if not indelicate.

FR

Pas un mot sur le fait que choisir PHP sur un serveur Apache permet non seulement la compatibilité entre plateformes mais aussi la meilleure sécurité, alors que choisir ASP.Net mène directement à Microsoft IIS, le pire serveur en termes de sécurité. (oui, je sais qu'on peut faire tourner de l'ASP.Net sur Apache avec Mono, mais c'est un pré-requis officiel d'ASP.Net que d'utiliser IIS). Voir aussi securityfocus.com

EN

Not a single word on the fact that choosing PHP on an Apache webserver brings not only cross-platform compatibility but also the best security level, while choosing ASP.Net leads directly to Microsoft IIS, the worst server in terms of security. (yes, I know you can run ASP.Net on Apache with Mono, but it's an official MS requirement to use IIS for ASP.Net). See also securityfocus.com

FR

Pas un mot non plus sur le fait que PHP interprété est plus rapide qu'ASP.Net pseudo-compilé !

EN

Not a single word neither on the fact that interpreted PHP is faster that pseudo-compiled ASP.Net !

FR

La section PHP est complètement à revoir. Tous les exemples de code PHP sont à revoir. Toutes les vulnérabilités PHP sont à revoir.

EN

The PHP section is completely to be rewritten. All code examples are wrong. All PHP vulnerabilities are outdated.

FR

Au sujet de la norme ISO 17799 mentionnée page 27, elle s'appelle ISO/CEI 27002 depuis juillet 2007 et recouvre un "Code de bonnes pratiques pour la gestion de la sécurité d'information" et elle ne date pas des "mid-90s" mais de décembre 2000 ; la norme britannique BS 7799-1:1999 "- Information security management. Code of practice for information security management" évolue de celle de 1995 qui elle-même remplace DISC PD 0003:1993 ; il est faux de dire que le standard australien AS 4444 est une source de l'ISO, puisque l'AS 4444 découle du BS 7799-1 qui sert de base à l'ISO et qui s'était déjà répandu en Europe avant d'arriver en Australie et en Nouvelle-Zélande. A noter que l'autre norme BS 7799-2 est devenue l'ISO 27001. Voir aussi ici sur le site des usagers des ISO 27001 et 27002.

EN

About the ISO 17799 mentioned page 27, its name is ISO/CEI 27002 since July 2007 and it doesn't date back of the "mid 90s" but of December 2000 ; the British Standard BS 7799-1:1999 derives from the 1995 version, itself superceding DISC PD 003:1993 ; it is wrong to say that AS 4444 comes from BS 7799-1 and became ISO , because AS 4444 comes from BS 7799-1 which is a basis for ISO and which was already spread out in Europe before coming to Australia and New-Zealand. It is to be noted that the other Standard BS 7799-2 became ISO 27001. See also here on the ISO 27001 and 27002 Users site.

FR

page 46 "Australian Standard / New Zealand Standard AS/NZS 4360, first issued in 1999, is the world’s first formal standard for documenting and managing risk" : la norme ISO 10006 : 1998 couvre déjà l'évaluation des risques au sein de la gestion de projet et n'est pas plus générique que l'AS 4360. De plus, il me semble que la bonne vieille NF EN 1140:1994-12-01 traite des risques...

EN

page 46 "Australian Standard / New Zealand Standard AS/NZS 4360, first issued in 1999, is the world’s first formal standard for documenting and managing risk" : sttandard ISO 10006 : 1998 already covers risk assessment inside project management and is not more generic than AS 4360. Moreover, it seems to me that good ol' Standard NF EN 1140:1994-12-01 covers risk management...

FR

page 72, section "Web Services" : tous les services web ne sont pas "XML-Based" et n'utilisent pas WSDL ;-)
page 95, aucune mention des fonctions SOAP de PHP 5 (13/07/2004) ni des librairies NuSOAP et PEAR SOAP pour PHP. Toute la section est orientée Java, avec un peu de Dot.Net pour faire joli.

EN

page 72, section "Web Services" : all web services are not "XML-Based" and all do not use WSDL ;-)
page 95, no mention of the SOAP functions of de PHP 5 (13/07/2004) nor of the NuSOAP and PEAR SOAP libraries for PHP. All the section is biased toward Java, with some sprinkles of Dot.Net for decoration.

FR

Page 104 dans "Authentication", la section sur "integrated authentication" fait la promotion du modèle Microsoft à base Kerberos, en la décrivant comme très sûre, alors qu'il suffit d'aller ici voir les security advisories pour s'assurer que ce n'est pas le cas, et depuis 2002 encore.
La dernière faille découverte au moment où j'écris est Kerberos KDC Cross-Realm Referral Denial of Service Vulnerability
La promotion de la confirmation par SMS plutôt que par mél est risible, aucune n'est plus sûre que l'autre et toutes deux transitent par divers serveurs...
La phrase sur SAML page 112 devrait être changée suite à la sortie de projets SAML pour PHP, Lightbulb un sous-projet d'OpenSSO ou encore simpleSAMLphp, tous deux sortis en 2007.

EN

Page 104 in "Authentication", the section about "integrated authentication" promotes the Microsoft model, on a Kerberos base, describing it as very secure, as it only requires to look here to see the security advisories to understand it's not the case, and since 2002.
The last vulnerability found while I write this is Kerberos KDC Cross-Realm Referral Denial of Service Vulnerability
Promoting the SMS confirmation use in stead of email confirmation is laughable, neither method is more sure than the other and both transit through various servers...
The sentence on SAML page 112 should be changed following the issueing of PHP project for SAML, Lightbulb a subproject of OpenSSO or even simpleSAMLphp, both released in 2007.

FR

dans la section "Authentication", citer page 119 "browser remembers passwords" comme une vulnérablité est un peu fort de café. C'est l'utilisateur qui a voulu que le navigateur mémorise ses mots de passe ! De plus promouvoir l'attribut propriétaire (IE5+) AUTOCOMPLETE va à l'encontre des standards et de l'Open Source.
Lire page 122 que le SSN (Social Security Number" est "US only" alors que la SS (Sécurité Sociale) a été inventée en Europe (France, 9 avril 1898 et 4 octobre 1945, Allemagne 1883, USA 1935) est assez goûteux ;-) Le NIR n'est après tout que le "numéro de Français" ou numéro Carmille, du nom de son inventeur en 1940 (le SSN américain semble avoir été émis dès novembre 1936, avec des moyens assez coercitifs).
page 135 l'usage d'un CAPTCHA est décrit comme une vulnérabilité, alors que les problèmes ne sont que d'ordre d'accessibilité...

EN

In the section "Authentication", citing page 119 "browser remembers passwords" as a vulnerability is a bit exagerated. It's the user which chose to tell the browser to remember that password ! Moreover, promoting proprietary attribute (IE5+) AUTOCOMPLETE is against all standards and against Open Source.
Reading page 122 that the SSN (Social Security Number) is "US only" while SS (Sécurité Sociale) was invented in Europe (France, 9 April 1898 and 4 October 1945, Germany 1883, USA 1935) is quite tasty ;-) The NIR is only, after all, the "numéro de Français" or numéro Carmille, from the name of its inventor in 1940 (the american SSN seems to have been emitted starting November 1936, with quite coercitive ways).
page 135 the use of a CAPTCHA is described as a vulnerability, while problems are only accessibility problems for visually impaired people...

FR

La longueur limitée des mots de passe pourrait aussi être citée, non comme une source de faille de sécurité, mais comme une source de sécurité. En effet, lorsqu'il n'y a que 8 caractères offerts à la saisie (par exemple), il est très difficile d'y faire tenir une "SQL Injection"... et alors le simple addslashes() permet de "sanitizer" le "user input" (pour parler comme eux ;-)

EN

The limited length of passwords could also be mentioned, not a source for vulnerability, but as a source for security. Indeed, when there are only 8 characters allowed for user input, it sems quite difficult to use the input field for an "SQL Injection"... and then the simple addslashes() call is enough to sanitize input.

FR

dans "Authorization" page 141 (la section n'est pas numérotée!), il est dit qu'utiliser un contrôle d'autorisation ad hoc est mal et qu'il faut utiliser ceux du framework ASP.Net ou Java (c'est bien ce qui est écrit). C'est amusant dans la mesure où des failles de sécurité importantes sont attachées aux fichiers web.config, bien pires qu'avec un simple httpd.conf et un php.ini...
Comme je le disais, le document OWASP est biaisé vers Java et ASP.Net ; pour preuve, la seule référence de "further reading" est pour ASP.Net...

EN

in "Authorization" page 141 (section is not numbered!), it is said that using an ad hoc authorization control is evil and that you should use the framework 's builtin features, the framework being of course ASP.Net or Java (it's written). This is funny as critical security flaws are attached to web.config files, a lot worse than with a simple couple of httpd.conf and php.ini files...
As I said, the OWASP Guide is biased toward Java and ASP.Net ; as a proof, the only "further reading" reference is for ASP.Net...

FR

dans la section "session management", page 147, je m'attendais à trouver la trace de PHP dont c'est un point fort. Point du tout ;-) Le "framework PHP" cité en Introduction n'est même plus mentionné ici. Le mécanisme décrit va directement à l'encontre des recommendations de la section précédente au sujet de la vulnérabilité "Client-side authorization tokens" :

EN

in the section "session management", page 147, I was expecting to find the trace of PHP because it's one of his strongest features. Not at all ;-) The "PHP framework" mentioned in Introduction is not even mentioned here. The described mechanism is directly against recommendations made in the previous section about the "Client-side authorization tokens" vulnerability:

Web servers are extended by application frameworks, such as J2EE or ASP.NET, implementing a state management scheme tying individual user's requests into a "session" by tying a cryptographically unique random value stored in a cookie (or elsewhere within client submitted data)


versus

Check your application: • Does not set any client-side authentication or authorization tokens in headers, cookies, hidden form fields, or in URL arguments. • Does not trust any client-side authentication or authorization tokens (often in old code)
FR

"exposed session variables" : aucune mention qu'un programme PHP peut ranger ses sessions ou fichiers ailleurs que dans /tmp ou %windir%\temp simplement en changeant php.ini OU en positionnant à la volée une autre valeur avec ini_set() ou la fonction session_save_path() qui existe depuis 2000... (dans php.ini : upload_tmp_dir pour les upload, session.save_path pour les sessions)
Au sujet d'ASP.Net dont la section fait la promotion, aucune mention de ce que ses variables de session se retrouvent dans App_LocalResources avec des fichiers de ressources dans ./bin, qui "provide no protection for session data" lui aussi ( n'est pas plus sûr que /tmp ou %windir%\temp )
Page 160 dans la phrase "Tie the session to a particular browser by using a hash of the server-side IP address" il manque le mot "instance" avant le brouteur ;-))

EN

"exposed session variables" : not a single mention that a PHP program can store its sessions and files somewhere else than in /tmp or %windir%\temp siply by changing php.ini OR by setting on the fly an other value with ini_set() or the function session_save_path() which exists since 2000... (in php.ini : upload_tmp_dir for uploads, session.save_path for sessions)
This section promoting ASP.Net, no mention is made of the fact that his session variables are stored in App_LocalResources with resource files in ./bin, which "provide no protection for session data" neither ( it's not mose secure than using /tmp or %windir%\temp )
Page 160 in the sentence "Tie the session to a particular browser [instance] by using a hash of the server-side IP address" there is the word "instance" lacking ;-))

FR

dans la section "data validation", quasiment tout est rédigé avec uniquement Java en tête, et parfois un peu d'ASP.Net (c'est encore une fois la seule lecture proposée dans "further reading" ;-). A croire qu'il est inutile d'aller plus loin avec PHP ;-)

EN

in the section "data validation", almost everything is written with exclusively Java in mind, with some ASP.Net (again, it's the only reading proposed in "further reading" ;-). Should I understand that it's pointless to examine "data validation" with PHP ? ;-)

FR

la section "interpreter injection" (page 173) indique que "The browser has several in-built renderers, including: HTML, [...], XUL (Firefox and Mozilla)" : je ne savais pas que XUL, langage de description d'interfaces utilisateur, était un "renderer" (moteur de rendu des pages Web) ;-))
Page 174 "most GET requests need to be less than 2 or 4 KB in size" est inexact. D'après la RFC 2068 :

EN

the section "interpreter injection" (page 173) states that "The browser has several in-built renderers, including: HTML, [...], XUL (Firefox and Mozilla)" : I didn't know that XUL, a user interface description XML-based language, was a "renderer" ;-))
Page 174 "most GET requests need to be less than 2 or 4 KB in size" is wrong. According to RFC 2068:

Servers should be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths.
FR

De même, la norme SGML indique qu'une URL est un attribut texte qui ne peut dépasser 1024 caractères.
Ce sont les navigateurs et serveurs ouaibe qui ont des limitations différentes selon l'implémentation :
Opera supports ~4050 characters, IE 4.0+ supports exactly 2083 characters avec une limite de 2048 dans le chemin, Netscape 3 -> 4.78 support up to 8192 characters before causing errors on shut-down, and Netscape 6 supports ~2000 before causing errors on start-up. Firefox 1.5 accepte plus de 100 000 caractères même si l'adresse ne s'affiche plus dans la barre d'adresses après 65536. Safari accepte au moins 80000. Opéra 9 plus de 90000.
La limite raisonnable pour une bonne interopérabilité est 2000 caractères.
Toute la section est très décevante et n'apporte rien de plus que la lecture de l'article de Klein.
Page 183 "Code Injection" indique que "ASP.NET does not contain any functions to include injected code, but can do it through the use of CodeProvider classes along with reflection". C'est sans doute pour cela que Microsoft a rédigé deux entrées de sa MSDN KB au sujet de la prévention des injections de code dans ASP.Net... Sans compter sur l'injection SQL en aveugle dès lors que l'application ASP.Net a accès à XP_CMDSHELL...
Bizarrement, alors que la section adopte un ton péremptoire au sujet de PHP ("toutes les applications utilisant eval() courent un risque", ce qui est trivialement faux) elle se permet de citer un lien d'"injection XML dans PHP" (alors qu'il s'agit d'une vieille défaillance d'un module PEAR XML-RPC) tout en ne citant aucun des très nombreux liens d'injection de code ou de SQL en Java ni dans n'importe quelle application Windows (IE7...), y compris Dot.Net .
Citer system() et passthru() de PHP est très bien, mais citer aussi StartProcess(), java.lang.Runtime.exec(), System.Diagnostics.Process.Start() est plus honnête.

EN

As well, the SGML standard states that an URL is a text attribute which can not exceed 1024 characters.
It's the browsers and web servers which have differing limitations:
Opera supports ~4050 characters, IE 4.0+ supports exactly 2083 characters with a limit of 2048 in the path, Netscape 3 -> 4.78 support up to 8192 characters before causing errors on shut-down, and Netscape 6 supports ~2000 before causing errors on start-up. Firefox 1.5 accepts more than 100 000 characters even if the address doesn't display after 65536. Safari accepts at least 80000. Opera 9 more than 90000.
The reasonable limit to ensure interoperability is 2000 characters.
All the section is very disappointing and doesn't bring anything more than the reading of Klein's article.
Page 183 "Code Injection" states that "ASP.NET does not contain any functions to include injected code, but can do it through the use of CodeProvider classes along with reflection". It's probably the reason why Microsoft issued two MSDN KB entries about preventing code injections in ASP.Net... Not even mentioning the Blind SQL Injection when the ASP.Net application has access to XP_CMDSHELL...
Strangely, while the section adopts a peremptory tone about PHP ("all applications using eval() are at risk", which is trivially false) it dares to cite one link towards "XML injection in PHP" (while it is an old vulnerability in the third-party module PEAR XML-RPC) while citing not a single one of the very numerous links towards Code or SQL Injections in Java or in any Windows application (such as IE7...), including Dot.Net .
Citing system() and passthru() of PHP is very nice, citing also StartProcess(), java.lang.Runtime.exec(), System.Diagnostics.Process.Start() is even better and more honest.

FR

la section "Canonicalization" (avec la faute dans le titre ;-), page 189 se permet de déclarer en gros que "PHP: Set in php.ini, ISO 8859-1. NB: Many PHP functions make (invalid) assumptions as to character set and may not work properly when changed to another character set" : c'est imprécis et donc invérifiable (une analyse plus précise est ici) et fait l'impasse sur les extensions de PHP 4 (1999) appelées iconv et mb_string (multi-byte strings).

EN

The "Canonicalization" section (with the typo in title ;-), page 189 dares to pretend that "PHP: Set in php.ini, ISO 8859-1. NB: Many PHP functions make (invalid) assumptions as to character set and may not work properly when changed to another character set" : this is imprecise and thus unverifyable (a more thorough analysis is in here) and - of course - completely unmentions PHP 4 (1999) extensions named iconv and mb_string (multi-byte strings)...

FR

La section "File system", outre qu'elle n'est pas très intéressante, se permet page 211 de citer sans plus de procès... une "security advisory" de... "MySQL world readable log files". Interloqué, j'ai suivi le lien. Il s'agit d'une erreur du fournisseur brésilien de la distribution linux "Conectiva Linux 6.0" de 2002 et qui n'a touché que son produit. ça concerne qui ? Quelle mauvaise foi... Sans trop se fouler, on peut trouver des exemples de défauts de ce type chez tout le monde :

EN

The section "File system" is not only not very interesting, but also dares page 211 to cite without any more precaution... a "security advisory" of... "MySQL world readable log files". A bit surprised, I followed the link. It was a configuration error of the Brasilian provider of the linux distro "Conectiva Linux 6.0" of 2002 and which concerned only its product. Who does this concern ? What an unfaithful behaviour from the OWASP Guide writers! Without searching for too long, anybody can find numerous examples of such defects in all products, from all providers and vendors:

FR

Quitte à mettre une liste, autant ne pas mettre qu'un seul élément visant MySql, qui est très sûr en ce qui concerne la problématique des fichiers "world readable".

EN

Hey, OWASP 2.0.1 Guide writers! If you really want to put on a list, you'd better not put only one example, involving MySql, because MySql is very secure when it comes to file system access and the "world readable files" problem. Stay fair.

FR

texte Section "Buffer Overflow", page 212 : mêmes remarques
Il est de plus dit que J2EE et ASP.Net échappent aux "buffer overflows" :

EN

"Buffer Overflows" section, page 212 : same remarks...
Moreover, it is said that J2EE and ASP.Net completely avoid buffer overflows:

  J2EE – as long as native methods or system calls are not invoked
  .NET – as long as /unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)
  PHP – as long as external programs and vulnerable PHP extensions written in C or C++
are not called
FR


C'est amusant quand on lit :

EN

This is "funny", because you may read:

FR

Ceci dit, je reconnais qu'il est très difficile d'exploiter un buffer overflow en J2EE. ASP.Net a des tonnes de buffer overflows référencés (il suffit d'aller sur google) et PHP en a eu aussi dans le passé, mais elles sont patchées sous 48 heures (un exemple ici).
En faisant des statistiques sur Secunia.com :

EN

This said, I recognize that it is difficult to exploit a buffer overflow in J2EE. ASP.Net has tons of buffer overflows referenced (just visit Google) and PHP had some too in the past, mais they were patched under 48 hours (an exemple here).
If you do statistics from Secunia.com you get this:

outilvulnérabilités "buffer overflow"commentaire
PHP20 alertes (13 sans les extensions tierces), dont 4 en 2006, 9 en 2007, 1 en 2008 et 1 nouvelle en 2009
20 alerts (13 without third party extensions), with 4 new in 2006, 9 new in 2007, 1 new in 2008 and 1 new in 2009. This tool is secured and stable.
outil fiabilisé (Open Source)
Java24 alertes, dont 1 en 2006, 4 en 2007, 6 en 2008 et 8 nouvelles en 2009outil non fiabilisé (Open Source)
Dot.Net9 alertes, dont 1 en 2006, 1 en 2007, 2 en 2008 et 3 nouvelles en 2009outil non fiabilisé (Microsoft)

NB Microsoft lui-même est à l'origine de plus de 225 security advisories de "buffer overflows" sur Secunia.com, c'est donc bien une spécialité de la maison. (j'ai cessé de compter après 225 ;-)

NB : buffer overflows are an house-made specialty (mark-of-fabric) of Microsoft, it accounts for more than 225 security advisories on the subject on secunia.com (I stopped counting after 225 ;-)

FR

J'ai trouvé particulièrement goûteux, étant un programmeur à sensibilité Pascal, de lire en plusieurs endroits que pour échapper aux attaques par "buffer overflow" et consorts il fallait "Use programming languages other than C or C++" ;-)
C'est à tel point que la section "How to determine if you are vulnerable" devrait même être systématiquement rédigée comme ceci :

EN

I found particularly tasty, being a programmer with a Pascal background, to read in numerous places that to avoid buffer overflow attacks you should "Use programming languages other than C or C++" ;-)
It's even at the point that section "How to determine if you are vulnerable" should be written this way:

If your program:
  - was made in C or C++
  - ...
FR

De même, la recommendation "Use range checking if your language or framework supports it" n'a pas de sens pour un programmeur Pascal ayant utilisé Turbo-Pascal ou Delphi/Kylix : "range checking" (avec ses copines "index checking", "I/O Error Handling", "Stack Checking" et "Overflow checking") est une obligation ; elle ne doit être désactivée qu'après avoir testé l'application, et seulement pour gagner et quelques picaillons en vitesse et taille d'exécutable sur les PC limités à 128, 320, 512 ou 640 Ko de RAM (un sujet rarement abordé de nos jours avec des multi-Giga de RAM). Vous pouvez lire un article récent ici sur le blog de David Intersimone ; attention il y est dit que dans les "compiler options for Delphi 2009 [...] default compiler options for Range checking at run-time is still set to false and I/O checking is still set to True".

EN

Also, the recommendation "Use range checking if your language or framework supports it" as no sense for a Pascal programmer having used Turbo-Pascal or Delphi/Kylix : "range checking" (with its sisters "index checking", "I/O Error Handling", "Stack Checking" and "Overflow checking") is mandatory ; it should be deactivated only after having tested the application, and only to gain some % in speed and executable size on memory-limited PC to 128, 320, 512 or 640 KB RAM (a subject rarely to the point toway, with multi-GBs of RAM being the norm). You may read a recent article here on the blog of David Intersimone ; be warned, it is said that in "compiler options for Delphi 2009 [...] default compiler options for Range checking at run-time is still set to false and I/O checking is still set to True".

FR

La section suivante, "Administrative Interfaces" (page 220) est écrite avec le "syndrome SOX" qui voudrait séparer les fonctions d'administration des fonctions d'usage normal de l'application. S'agissant de mes propres sites web, je n'ai jamais vu de problème à ce sujet. Certains utilisateurs ont des droits d'administration, un (moi) a des droits plus étendus, et un autre (admin) est réellement séparé des autres, mais plus pour des besoins de "logging propre" que pour des raisons de sécurité. Si le système était attaqué, les comptes "administrateurs" seraient de toute manière visés en premier. A la limite, autant ne pas mettre d'administrateur pour ne pas attirer les attaques et donner à des utilisateurs (inconnus de l'attaquant) les droits d'administration ;-)
Dans "further reading" le seul lien fourni semblait devoir couper court à toute discussion au sujet de "pourquoi les comptes administrateur et utilisateurs devraient être séparés". Je l'ai suivi. En fait de discussion, un petit texte vous dit qu'il y avait une faille de type register_globals=On sur le serveur et qu'en passant deux paramètres en GET à admin.php de PHPNuke on pouvait effacer un utilisateur et même le "God Admin"... Quelle horreur, vais-je m'en remettre? ;-))
A mon humble avis, tout avait été dit dans les sections "Authorization" et "Authentication" ;-)

EN

The next section, "Administrative Interfaces" (page 220) is described with the "SOX syndrom" which wants to separate the application's administrative functions from normal useage functions. Speaking of my own websites, I never encountered this problem. Some users have administrative rights, one (me) has extended privileges, and an other (admin) is rerally separated from the others, but this is more to answer to needs of "clean logging" than for security reasons. If the system was attacked, "administor" accounts would be targetted first anyway. Pushing the reasoning to the limit, you'd better not set any administrator account to not attire attackers' attention, and rather give to some normal users (more difficult to find out) the administrative rights. ;-)
In "further reading" the ony provided link seemed to be the definitive answer on the topic of "why administrative accounts should be separated from normal users accounts". I followed it. In fact, it's simply a small text telling you there was a vulnerability of the register_globals=On type on the webserver and that passing two parameters in GET to admin.php of PHPNuke you could remove a user and even the "God Admin"... Horror! Will I survive ? ;-))
IMHO, all had been said in the sections "Authorization" and "Authentication" ;-)

FR

la section "Cryptography" (page 223) ne fait que présenter les concepts et l'état de l'art en 2005.
Néanmoins, page 232 on peut lire "Windows & .NET: On Microsoft platforms including .NET, it is recommended to use the inbuilt CryptGenRandom function" avec un lien vers MSDN (Microsoft itself). Hélas! Cela fait bien longtemps que cette recommendation est à jeter d'urgence à la poubelle !

EN

the section "Cryptography" (page 223) only presents the concepts and state-of-the-art of 2005.
Nevertheless, page 232 you may read that "Windows & .NET: On Microsoft platforms including .NET, it is recommended to use the inbuilt CryptGenRandom function" with a link to MSDN (Microsoft itself). Halas! It's been a long time since this recommendation is to be trashed right to the garbage basket!

FR

Une autre lecture intéressante est l'article de Schneier (auteur très cité dans les "further reading") au sujet de la backdoor NSA dans Dual_EC_DRBG qui se présentait dans le document NIST 800-90 comme le nouveau standard des générateurs de nombres aléatoires (il suffit d'analyser 32 octets d'une session TLS pour connaître les valeurs de sortie de l'algorithme).
Heureusement, lorsque Microsoft a implémenté cette "norme" NIST 800-90 (qui contient Dual_EC_DRBG) pour le Windows Vista with Service Pack 1 (SP1), ils ont choisi d'implémenter l'AES counter mode (AES-CTR) qui est le "block cipher" de NIST 800-90 ; NIST 800-90 définit un générateur sur des hachages (hash), un sur HMAC, un sur le chiffrage par blocs (block cipher) et l'infâme sur les courbes elliptiques ( Dual_EC_DRBG ).
Voir la RFC3686. Si quelqu'un veut utiliser CryptGenRandom(), je lui conseille de ne pas remplir le pbBuffer avec Dual_EC_DRBG ;-))

EN

An other interesting reading is Schneier's (author very frequently cited in OWASP's "further reading") article about the NSA backdoor in Dual_EC_DRBG which was proposed in NIST 800-90 document as the new standard in random numbers generators (it's enough to analyze 32 bytes of a TLS session to know the algorithm's future output values).
Thanks God, when Microsoft implemented this "standard" NIST 800-90 (which contains Dual_EC_DRBG) for the Windows Vista with Service Pack 1 (SP1), they chose the AES counter mode (AES-CTR) which is the "block cipher" of NIST 800-90 ; NIST 800-90 defines a hash based genetor, a HMAC generator, a block cipher generator and the infamous elliptic curves based generator ( Dual_EC_DRBG ).
See RFC3686. If someone still wants to use CryptGenRandom(), I strongly advise him not to fill in the pbBuffer with Dual_EC_DRBG ;-))

FR

les sections "Configuration" (page 236) et "Maintenance" appellent quelques commentaires :

EN

sections "Configuration" (page 236) and "Maintenance" attire some comments:

FR

La section "Denial of service attacks" (page 245) est vide de contenu utile mais elle a le mérite d'indiquer que les application "modernes" MVC consomment beaucoup (trop) de ressources et de lignes de code ;-)

EN

section "Denial of service attacks" (page 245) is empty of any useful contents but has the merit of stating that "modern" MVC applications consume far too much resources and code lines ;-)

FR

...et le document officiel OWASP 2.0.1 se termine page 248 ;-)

EN

...and the official OWASP 2.0.1 document ends at page 248 ;-)

FR

Dans la section "Ajax" ajoutée en 2006, il y a par exemple la partie 1.7 State Management, 1.11 SOAP, 1.12 XML RPC, 1.13 DOM Injection Attacks etc qui sont vides de tout descriptif de vulnérabilité... depuis 2006.

Les problèmes d'accessibilité (WAI etc) sont cités !!!?! Quel rapport avec la sécurité des applications ?

EN

In the "Ajax" section added in 2006, there are parts numbered 1.7 State Management, 1.11 SOAP, 1.12 XML RPC, 1.13 DOM Injection Attacks etc which are void of any vulnerability description... since 2006.
Accessibility (WAI etc) is listed as an issue (!!!?!) What does it have to do with Application Security ?

FR

Dans la section "Deployment" ajoutée en 2006, il y a par exemple la partie 1.5 Secure Delivery of Code qui mentionne dans "How to protect yourself" : "Secure". Très utile ;-)
Les sections 1.6 Code Signing et suivantes sont vides. Seule la section 1.15 Easter Eggs a été développée... et contient d'ailleurs une phrase non terminée dans "comment détecter le problème".

EN

In the section "Deployment" added in 2006, there is for instance part 1.5 "Secure Delivery of Code" which mentions in "How to protect yourself" : "Secure". Very useful ;-)
Sections 1.6 "Code Signing" and following are simply empty. Only the 1.15 "Easter Eggs" section was developped... and contains an unterminated sentence in "how to detect if you are vulnerable".

FR

Le résultat de mon travail de nettoyage/numérotation/formatage/correction est une version 2.0.2 soumise à l'éditeur, et que j'offre au téléchargement ici (PDF 1778 Ko).

EN

The result of my work (cleaning/numbering/formatting/fixing typos) is a version 2.0.2 sent to the Editor, and that I offer for download here (PDF 1778 KB).

FR

De plus je pense, au moment où j'écris, qu'il serait bon de tenir compte de la liste NSA/SANS/CWE/Mitre.org appelée "2009 CWE/SANS Top 25 Most Dangerous Programming Errors" (établie fin 2008, publiée fin 2009 ;-) pour mettre à jour le "Guide OWASP".

NB Je me réserve le choix de procéder à des modifications de certaines sections, tant le niveau d'icelles est faible (Canonicalization, File system, Interpreter Injection) ; en particulier, le Guide 2.0.1 a visiblement été écrit par des personnes pratiquant exclusivement ASP.Net et Java, et quand il traite de PHP c'est avec beaucoup de légèreté. Une refonte en profondeur est nécessaire concernant PHP.

EN

Moreover, I think, while writing this, that it should be fine to take into account the NSA/SANS/CWE/Mitre.org list called "2009 CWE/SANS Top 25 Most Dangerous Programming Errors" (established end of 2008, published end of 2009 ;-) to update the "OWASP Guide".

NB I reserve myself the right to modify some sections, as their quality level is so low (Canonicalization, File system, Interpreter Injection) ; in particular, the 2.0.1 Guide was visibly written by people practicing exclusively ASP.Net and Java, and when it comes to PHP it's very wrong generally. A complete and deep rework is necessary concerning PHP.

Un Guide Révisé est disponible pour la revue entre pairs : Owasp2.1.0.pdf (2403 Ko, Anglais)
A Revised Guide is available now for peer-to-peer review: Owasp2.1.0.pdf (2403 KB, English)

9. Conclusion top previous section

FR

Dans l'ensemble, le Guide OWASP 2.0.1 est assez bon, mais il sent la peinture fraîche malgré son grand âge. Il est aussi plein d'anglo-saxonismes et semble avoir été rédigé uniquement par des développeurs Java australiens ;-) Cela pose problème, par exemple quand des dispositions légales locales sont érigées en règles ou que des contre-vérités sont émises au sujet de PHP.
Il y a du boulot pour rendre ce document vraiment international et lui donner une qualité normative.

J'ai mené un tel travail pendant les vacances de Noël 2009 et en voici le résultat : un Guide Révisé, ouvert à la revue par les pairs, et disponible ici (Owasp2.1.0.pdf, 2403 Ko)

Salutations,

EN

As a whole, the OWASP 2.0.1 Guide is not a bad document, but it smells a bit fresh paint despite its grand âge. It also is full of anglo-saxonnisms and seems to have been written almost exclusively by Australian Java developers ;-) This may pose problem when local legal dispositions are cited as rules or when counter-truths are said about PHP.
A lot of work seems necessary to make that document truly international and of standard-level. For the moment, it's in the state of a good RFC draft submitted for comments.

I finally conducted such a rewritting work during the Christmas 2009 holidays and here's the result : a Revised Guide, open to peer-to-peer review and available in here (Owasp2.1.0.pdf, 2403 KB)

Best regards,

Vincent Graux (VGR) for Edaìn Works and European Experts Exchange and Experts Round Table  back to list of articles
Last update 2020-10-17 13:22:23