WordPress.org

Ready to get started?Download WordPress

Forums

nginx Compatibility
[resolved] path disclosure not solved (Version 0.2.5) (8 posts)

  1. andrea c.
    Member
    Posted 2 years ago #

    Hi,

    I just did a fast scan with websecurify on my blog and "Path Disclosure" results still active as a weakness.

    I am looking for a different solution than solely relying on this plugin but it is just to let you know.

    cheers.

    http://wordpress.org/extend/plugins/nginx-compatibility/

  2. Vladimir Kolesnikov
    Member
    Plugin Author

    Posted 2 years ago #

    Hi Andrea,

    Did you get that error for /wp-content/plugins/nginx-compatibility/nginx-compatibility.php or for some other path?

    Thank you,
    Vladimir

  3. andrea c.
    Member
    Posted 2 years ago #

    Hi Vladimir,

    websecurify tells that there's a flaw but doesn't really tells nothing more.

    I am about to delve deeper this issue tonight or tomorrow. I am no expert when it comes to security assessment. Today it was a quiet day at the office and I tried few tools to test my server. That's all.

    If you tell me how to test that directly I can try and answer you.

    Otherwise you can try websecurify scan your server/wp/plugin and see.

    http://www.websecurify.com/

    cheers

  4. Vladimir Kolesnikov
    Member
    Plugin Author

    Posted 2 years ago #

    Ah, I see then. You see, WordPress itself is vulnerable to path disclosure vulnerabilities and then only thing you can do is not to show errors on the screen, e.g. by addinig

    display_errors = Off

    to your php.ini.

    To test if the plugin itself is vulnerable, you should try opening any PHP file in the plugin directory.

    For example, if you open example.com/wp-content/plugins/nginx-compatibility/nginx-compatibility.php and it says something like "Fatal error: blah-blah-blah in /path/to/your/wordpress" then nginx-compatibility is vulnerable to this attack.

    To prove that WordPress by default is vulnerable: if you open, say, http://www.lifestylemoneymanagement.com.au/wp-settings.php (random site), you will see smth like this:

    Warning: require(ABSPATHwp-includes/load.php) [function.require]: failed to open stream: No such file or directory in /home/lifestyl/public_html/wp-settings.php on line 21

    The reason for that is that WordPress does not check whether all necessary constants have been defined/required files have been included. Sad but true.

  5. andrea c.
    Member
    Posted 2 years ago #

    Hi Vladimir,

    I see. That is both good and sad news.

    Good because I see nothing when I load wp-settings.php or anything in the plugins.
    Bad because of this flaw in WP.

    Good because I see nothing even if I set display_errors = on
    Bad because my nginx try_files it seems not to be working.

    In fact I should be redirected to /index.php when calling something like wp-settings.php (if I understood my try_files set up well enough).

    Thank You for support and I apologize for saying it was not working.

    ps: I guess that other "* disclosures" are to be considered WP's fault?

  6. Vladimir Kolesnikov
    Member
    Plugin Author

    Posted 2 years ago #

    In fact I should be redirected to /index.php when calling something like wp-settings.php

    If wp-settings.php exists, you won't be redirected to index.php.

    I guess you use smth like:

    try_files $uri $uri/ /index.php

    In this case nginx first looks for file matching the request URI, if it fails, it tries to find a directory matching the requesr URI and if that fails as well, it will fall back to index.php.

    I guess that other "* disclosures" are to be considered WP's fault?

    Path disclosures? Yes and no. Yes, WordPress is affected to this, but a lot of the 3rd party WP themes and plugins are affected as well.

  7. andrea c.
    Member
    Posted 2 years ago #

    Yes that's my try_files config , so I didn't understand it fully.

    These are the other disclosures that websecurify (chrome plugin since osx version costs a lot of money) finds:

    1st: Banner Disclosure; (who cares...)
    2nd: Path Disclosure; (we are talking about it)
    3rd: User Disclosure; (this scares me)
    4th: not really a disclosure and last "issue" is: Cross-site Request Forgery

    I am not really happy about them, but on the good side: it found "only" 4 issues. (1 issue is already one too many issues for my taste, but hey... considering I am not expert... ;))

    Anyway I am going off-topic.

    Thanks for your kind support.

    ps: beside that I would like to test malicious file upload/download/execution but I don't know how to do that for now. Trying the suits for starter and understanding of how it works. I'll see what I can learn and get safer.

  8. andrea c.
    Member
    Posted 2 years ago #

    OMFG.

    Now that I understood this...... I can say that it was a fake and that I doubt the goodness of websecurify chrome plugin. Here the two disclosure errors:

    Path Disclosure
    Various system paths were disclosed within the application client source code or other files. This information could be used by attackers to make an educated guess about the application environment and any inherited weaknesses that may come with it.

    solution: It is recommended to re-examine the system path disclosures and remove their reference from the application's source code.

    path: /home/kemu ...
    request: GET http://cga.cx/tag/code-2/ HTTP/1.1

    =========

    User Disclosure

    Various usernames were disclosed within the application client source code or other files. This information could be used by attackers to attack the login mechanism on the application and supporting infrastructure.

    solution: It is recommended to re-examine the username disclosures and remove their reference from the application's source code.

    user: home/kemu ...
    request: GET http://cga.cx/tag/code-2/ HTTP/1.1

    =======

    Now. I understand that those paths are really something standard on Linux... but these two are clearly two frikking false positives.

    Navigate to that URL: http://cga.cx/tag/code-2/ , select this article http://cga.cx/2011/07/11/kvmms/ and see the two "disclosures" in the "kemu" links.

    d'oh!!!

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic