full-disclosure - Re: Full Path Disclosure in most wordpress' plugins [?]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fb170c9e0909292335t4834d35byad15e2a85197384e@mail.gmail.com>
Date: Wed, 30 Sep 2009 08:35:29 +0200
From: majinboo <majinbou@...il.com>
To: Glafkos Charalambous <info@...osec.org.uk>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Full Path Disclosure in most wordpress'
	plugins [?]

Hello,

shared hosting environnement is not an option if you want to have a secure
website.

majinboo

2009/9/29 Glafkos Charalambous <info@...osec.org.uk>

> Hello,
>
> Yes at some point you are right but this is not an option most of the
> times,
> especially when you are on a shared hosting environment.
>
> So either the developers need to secure their plugins or we do it ourselves
> as this is still an issue for everybody using Wordpress Plugins.
>
> Glafkos
>
> -----Original Message-----
> From: full-disclosure-bounces@...ts.grok.org.uk
> [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Peter
> Bruderer
> Sent: Tuesday, September 29, 2009 9:33 PM
> To: full-disclosure@...ts.grok.org.uk
> Subject: Re: [Full-disclosure] Full Path Disclosure in most wordpress'
> plugins [?]
>
> The proposed fix is definitely something that helps. But to me it
> looks like most people do not care anymore about server settings. As
> soon as it is kind of working, it is pushed to the Internet.
>
> Why not avoid these problems completely and follow the recommendations
> in php.ini?
>
> ; Print out errors (as a part of the output).  For production web sites,
> ; you're strongly encouraged to turn this feature off, and use error
> logging
> ; instead (see below).  Keeping display_errors enabled on a production
> web site
> ; may reveal security information to end users, such as file paths on
> your Web
> ; server, your database schema or other information.
> ;
> ; possible values for display_errors:
> ;
> ; Off        - Do not display any errors
> ; stderr     - Display errors to STDERR (affects only CGI/CLI binaries!)
> ; stdout (On) - Display errors to STDOUT
> ;
> display_errors = Off
>
> ; Even when display_errors is on, errors that occur during PHP's startup
> ; sequence are not displayed.  It's strongly recommended to keep
> ; display_startup_errors off, except for when debugging.
> display_startup_errors = Off
>
> ; Log errors into a log file (server-specific log, stderr, or
> error_log (below))
> ; As stated above, you're strongly advised to use error logging in
> place of
> ; error displaying on production web sites.
> log_errors = On
>
>
> Now the error message is in the logfile and nothing is displayed in
> the browser.
>
>
> Peter Bruderer
> --
>   Bruderer Research GmbH
>   CH-8200 Schaffhausen
>
>
>
>
>
> On 29.09.2009, at 18:31, Loaden wrote:
>
> > Hey
> >
> > at first excuse my bad english. Thats a nice fix. But you need to
> > change
> > the code for other plugins or files. This code works for all files
> > which
> > should not be loaded directly:
> >
> > if (basename($_SERVER['SCRIPT_NAME']) == basename(__FILE__))
> >       exit('Please do not load this page directly');
> >
> > If your webhoster don't have a configuration panel you can try to
> > disable errors with this in your index.php:
> >
> > ini_set('display_errors', 0);
> >
> > I'am no sure if it works if save mode is activated. Try it or look at
> > the PHP manual.
> >
> > Regards
> >
> > Loaden
> >
> > On Mo, 2009-09-28 at 23:37 +0300, Glafkos Charalambous wrote:
> >> Hello,
> >>
> >>
> >>
> >> That definitely can be fixed easily with two lines of code but is
> >> still something that should have been prevented at earlier stages of
> >> "plugin" development
> >>
> >>
> >>
> >> "if (!empty($_SERVER['SCRIPT_FILENAME']) && 'akismet.php' ==
> >> basename($_SERVER['SCRIPT_FILENAME']))
> >>
> >> die ('Please do not load this page directly');"
> >>
> >>
> >>
> >> From the server side you can set PHP "warning" and "errors" OFF
> >> either
> >> through php.ini or PHP page itself but sometimes that's not an option
> >>
> >>
> >>
> >> Regards,
> >>
> >> Glafkos Charalambous
> >
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/