WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#45773 closed defect (bug) (duplicate)

Full Path Disclosure if we access the file directly

Reported by: alishanvr Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Security Keywords:
Focuses: Cc:

Description

Hi,

Today I found that if we hit direct access to http://wp-example.com/wp-includes/functions.php then it discloses the full path. Because when we try to access this file directly then at that time ABSPATH and WPINC are not defined and the system sends the error.

I have fixed this issue in the patch. Please review.

Thank You,

Attachments (2)

45773.functions.php.diff (333 bytes) - added by alishanvr 3 years ago.
Condition statement is added that checks if direct accessing.
45773.functions.php.patch (333 bytes) - added by alishanvr 3 years ago.
Patch file -- Condition statement is added that checks if direct accessing.

Download all attachments as: .zip

Change History (7)

@alishanvr
3 years ago

Condition statement is added that checks if direct accessing.

@alishanvr
3 years ago

Patch file -- Condition statement is added that checks if direct accessing.

#1 in reply to: ↑ description @alishanvr
3 years ago

Here is the Error image.

https://prnt.sc/lztcry

Replying to alishanvr:

Hi,

Today I found that if we hit direct access to http://wp-example.com/wp-includes/functions.php then it discloses the full path. Because when we try to access this file directly then at that time ABSPATH and WPINC are not defined and the system sends the error.

I have fixed this issue in the patch. Please review.

Thank You,

#2 @joyously
3 years ago

You would need to patch a lot more files than just that one to get around this.

See https://wordpress.slack.com/archives/C60K3MP2Q/p1545190442268800

which is where, on Dec 18, I posted in #core-php:

I was looking at my security plugin log and there were attempts to find known theme files like twentyfifteen/404.php and twentyseventeen/footer.php that got a 404 on my site since it's in a subfolder. So I wondered why someone would look for that, and came to the conclusion that it will fatal and expose the server path to the folder. I'm not sure what use this is to a hacker, but with the WSOD protector code in place, would that make it better or worse for the hacker?

#3 follow-up: @swissspidy
3 years ago

  • Focuses performance coding-standards removed
  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Hi @alishanvr and welcome to WordPress Trac!

This has come up many times before, for example in #36177, #30806, and most recently in #44700.

Path disclosure is a server configuration problem. Never enable display_errors on a production site. See Security FAQ.

#4 in reply to: ↑ 3 @alishanvr
3 years ago

Hi,
I can do it to all the core files.
if needed.
I can understand that we have to turn off the errors on live env. But I think this should be implemented by WP by default. As there are several hostings.
and if we search on google dork we can found alot of websites.
in the end, people said that we are using WP thats why we are facing such problems.
Is this not good if WP also have some checkups to avoid these kind of errors.
If you assign this task to me. then I can implement same strategy on almost all the core files.

Replying to swissspidy:

Hi @alishanvr and welcome to WordPress Trac!

This has come up many times before, for example in #36177, #30806, and most recently in #44700.

Path disclosure is a server configuration problem. Never enable display_errors on a production site. See Security FAQ.

#5 @swissspidy
3 years ago

Instead of changing all PHP files this should be done in a central location. That‘s what #36177 aims for. Please have a look at that ticket.

Note: See TracTickets for help on using tickets.