[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