The author points out that these were monitoring logs (and the screenshot looks very much like an Elastic cluster).

Thus this could be a missing or misconfigured log filter for PII.

Looks like they had tasks to run their services like "wordpress --user alice --password 123 --host alice.cloudclusters.com ..." and they systematically logged all the commands with all arguments/settings/variables.

Way too verbose logging. Should never have logged that.

The logging database (elasticsearch) was exposed to the internet without authentication. Free credentials for all.

> Way too verbose logging. Should never have logged that.

It's interesting to observe the contrast between this and "We're a SaaS startup and we log every.single. RPC request across all services forever including performance data".

You can log all HTTP requests and it is standard practice to do so at the load balancer level (haproxy and co have very configurable logging).

However you MUST NOT logs cookies or headers or content, because these can contain private information.

Last but not least, developers should never pass tokens/passwords in the request path because it will be systematically logged and leaked /api/token/abcdec. That should go into a header or the body.

Single-used tokens are fine to be passed in the path right? Like email verification /token/{token}

For email verification it's less scary if that was really all you wanted.

If you believe you're verifying that the email went to your user, this isn't enough. Lots of systems parse URLs out of emails and follow them, you probably want to look for a a pre-existing session cookie, or insist the user log in from the verification page and confirm this is what they wanted.

Otherwise you've merely got two unrelated facts:

1. Some user of your system (maybe happy_pancake) says [email protected] is their email address

2. Mail to [email protected] is received by a machine or person which reads web pages.

It would be foolish to conclude from these facts that happy_pancake is actually [email protected] or that [email protected] wants to use your service.

Defense in depth says No, not Ok.

For example: Accidentally open to the internet log server(as above). Attacker sends password reset request. Attacker checks log to steal token. Attacker now has stolen account until owner can't log in and does reset, or perhaps semi-permanently if attacker steals all tokens for said account and invalidates them before owner can use them.

They are a fully managed service for these services, so I'm assuming they store their own set of credentials separately to maintain access.

That's what I'm guessing too. Magento and WordPress both store only the hashed passwords in the database; however, a screenshot from the article shows that the hosting company had stored plain-text passwords for an admin user, which were likely generated automatically, and stored in a separate (and publicly accessible) database.

My hosting provider (to remain nameless) also offers a global login bypass for WP and it gives me the willies.

There are a few hosting billing system -> account creation products that will generate the login information at purchase time so they can be presented to the user in plain text before being sent over to the provisioned server. It could be being logged accidentally at that point.

What would be a proper way to handle it?

Implement a proxy authentication scheme for the hosted services (WP, etc). Now an admin working for the hosting provider can log in using a password checked against a hash stored in their hosting system. No plaintext passwords stored.

> the hosting provider can log in using a password checked

Hmm, but where is this password stored? This sounds like exactly what they were doing!

They have access to the DB users. You can craft a new user & password-hash pair and insert it into the DB to create your own Wordpress user to manage on their behalf, or the lazy way is to just update the user’s password hash with your own. Then when you fix the issue, revert it. Worked for me years ago, not sure if something fundamental changed

Logging of credentials supplied for 1-Click installs comes to mind.