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&gt; Date: 2013/4/23 Subject: Re: Dotclear vulnerabilities To: Alexandre <alex(a)pirine.fr&gt; ** *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). 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. 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&gt; *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