andrea c.

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 https://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 https://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: https://cga.cx/tag/code-2/ , select this article https://cga.cx/2011/07/11/kvmms/ and see the two “disclosures” in the “kemu” links.

d’oh!!!

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.

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?

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.

https://www.websecurify.com/

cheers

same problem here since last update. it was working fine until previous version.

nextgen loads the main album and galleries but won’t switch between gallery pages nor won’t show effects or trnasitions, just plain link to files.

check youself here: https://cga.cx/gallery/pictures/die-lichter-von-berlin/