Hello all - using standard feature is allways better than re-invent the wheel so if a library is performant and simply to integrate "let's go" : it will always be that much less to maintain - preserve the speed is not a main goal because pc performance always increase.
My 2 cents Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -----Message d'origine----- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de [Kreiz IT]Cédric GROSS Envoyé : vendredi 19 septembre 2014 16:24 À : 'Posts about Dolibarr ERP & CRM development and coding' Objet : Re: [Dolibarr-dev] Security improvement and new library Hi Laurent, > > I agree we can't rely on user data. Very happy "earing" that :) > > There is already a light "HTMLpurifier" into dolibarr (it is not based > on external lib, but included into core code of Dolibarr, lighter than > HTMLpurifier but really really faster). I don't really understand why you're so strict on speed. There is so much stuff to do to improve speed. For example, why doing a server request when you just need to convert a display field into a write field like invoice date or others. This should be done on client, we do not need a server call for only displaying 1 input. But it's another discussion. My point of view is security is more important than speed (relatively speaking). > > However, i am not sure we must rely on such tools. They filters string > we don't want to filter and forgot other. In general manner no BUT, for fields with ckeditor enable we need to allow and to print html as they are produced by ckeditor. Except some unwanted tag or arguments it's why we need HTML filtering. > It is better to rely on good practice that are escaping string > wherever we should escape string. In fact rule should be, we must escape everywhere except where we need to not escape. (Security principle: close a lot and just open where you need, not other way) > > This is escaping and sanitizing function we MUST use everywhere and is > the only full secure solution (the internal dolibarr purifier is only > to complete, but can't be reliable): > For js: dol_escape_js > For sql: $db->escape > For html: dol_escape_htmltag or dol_html_entities So dol_escape_htmltag or dol_html_entities (which is marked as deprecated for good reason) doesn’t fit the need to manage and display HTML tag as there are keyed (in product description for example: we need <strong> or <underline> but not <iframe>). HTMLPurifier seems to be widely recognize as the best filtering library. Cedric > > > 2014-09-15 16:26 GMT+02:00 [Kreiz IT]Cédric GROSS <c.gross@kreiz- > it.fr>: > > Hello there, > > > > > > > > I had a look on http://htmlpurifier.org. This library clean up var > > against wished HTML tag. > > > > I think including this library in Dolibarr could greatly improve > > security especially for fields where fckeditor used. > > > > > > > > What do you think ? > > > > > > > > Cedric > > > > > > > > > > _______________________________________________ > > Dolibarr-dev mailing list > > Dolibarr-dev@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > > > > > -- > Laurent Destailleur (alias Eldy) _______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev _______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
