dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] Security improvement and new library


From: charles.fr
Subject: Re: [Dolibarr-dev] Security improvement and new library
Date: Fri, 19 Sep 2014 16:47:54 +0200

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 : address@hidden [mailto:address@hidden 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 <address@hidden
> 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
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
> >
> 
> 
> 
> --
> Laurent Destailleur (alias Eldy)


_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




reply via email to

[Prev in Thread] Current Thread [Next in Thread]