Message-ID: <007f01ca41a3$9e53d7d0$dafb8770$@org.uk>
Date: Wed, 30 Sep 2009 10:57:08 +0300
From: "Glafkos Charalambous" <info@...osec.org.uk>
To: "'majinboo'" <majinbou@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Full Path Disclosure in most wordpress'
	plugins [?]

Hello,

 

Most of the people are using shared hosting environment and not all of them
are about security  and/or having their own (dedicated) server. You have to
see it from the whole prospective and that this is not always an option.

I don't remember this post was about secure environments or how to have a
secure website rather than the issue of wordpress plugins and how people are
affected (using shared hosting or not)

 

Btw what  part of most of the times  didn't make sense in the previous post?


 

Glafkos

 

 

From: majinboo [mailto:majinbou@...il.com] 
Sent: Wednesday, September 30, 2009 9:35 AM
To: Glafkos Charalambous
Cc: Peter Bruderer; full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] 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/

Powered by blists - more mailing lists