Live data from Hacker News

How we discovered a database leak in one of the biggest Swiss hosting providers

security.infoteam.ch

51–60 of 68 posts

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#51

Earlier quoted context omitted.

Email validation regexes are so annoying. Everyone ought to just use .+@.+ as their validation regex and not be more strict than that. Beyond that just queue and try to deliver the email. Tell the user than an email should arrive shortly and that if it doesn’t they should check their spam folder and that they should check that they gave the correct email address. When you say this you repeat the email address that th…

Sorry, but .+@.+ isn't going to cut it if you want to confidently accept deliverable email addresses. Regex valid, but not email valid: codetrotter@example code@trotter@example.com code trotter@example.com codetrotter@example..com codetrotter@example.com. .codetrotter@example.com My company runs a website that has elderly people signing up for newsletters. The client is paranoid about not getting every last drop of p…

If you want to "confidently accept deliverable email addresses" the only solution is to send a test message out with a link that the recipient has to visit to validate that the email address exists. Otherwise what about regex and email valid addresses that still don't exist?

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#52
post #22

Security Guardian is not a he/him. It may be a translation issue ... or maybe you've achieved human-level AI and it's become self-aware? In any case, I find it interesting that your first response is that the tool might have a bug ... and the link also on HN at this moment is about the Apollo 13 mission control engineers thinking their telemetry might be at fault. This is an excellent first response and it's importan…

Ships are not she/her and yet we use that kind of language with them all the time. Silly thing to quibble about.

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#54

Earlier quoted context omitted.

Sorry, but .+@.+ isn't going to cut it if you want to confidently accept deliverable email addresses. Regex valid, but not email valid: codetrotter@example code@trotter@example.com code trotter@example.com codetrotter@example..com codetrotter@example.com. .codetrotter@example.com My company runs a website that has elderly people signing up for newsletters. The client is paranoid about not getting every last drop of p…

There is a other email that the regexp lets pass and that’s still not valid: codetrotter@example.com It conforms to the expectated format and could be a valid email, but it’s actually not because no such user exists. An email might also exist, but not accept mail from you. The given email address might exist, by could belong to another user. There’s a million things that can go wrong and you’ll have a very hard time…

Good points. Why do regex tests at all if emails could fail in any number of ways?

If you're going to test for at least 3 characters with a @ in the middle, you probably should implement some other simple rules to have a snowball's chance on the internet:

only one @

no spaces

has TLD (guarantee at least one period after @, and something else after, no consecutive periods)

can't begin or end with a period

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#55

For the longest time a "clean" MySQL install would set up an no-password superuser for presumably dev convenience. I don't know if they changed that (it's been a while since I last installed MySQL) but if not, this could simply be a security hole by design, with the maintainers simply not paying attention to their install script flags.

I thought it was no password, but only available via localhost?

All that requires to be exploited "on" localhost is some PHP script interpreting unsanitized user uploads (uploading a php script that has an image file extension's a pretty famous example) on any of a thousand customer sites. You don't want that MySQL user to exist, ever =/

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#56

Earlier quoted context omitted.

Email validation regexes are so annoying. Everyone ought to just use .+@.+ as their validation regex and not be more strict than that. Beyond that just queue and try to deliver the email. Tell the user than an email should arrive shortly and that if it doesn’t they should check their spam folder and that they should check that they gave the correct email address. When you say this you repeat the email address that th…

Sorry, but .+@.+ isn't going to cut it if you want to confidently accept deliverable email addresses. Regex valid, but not email valid: codetrotter@example code@trotter@example.com code trotter@example.com codetrotter@example..com codetrotter@example.com. .codetrotter@example.com My company runs a website that has elderly people signing up for newsletters. The client is paranoid about not getting every last drop of p…

It appears you're missing the main point of the parent post.

You cannot validate an email address.

You can make a basic excruciatingly simple test for proper form. And should probably limit your checks to that.

For all else, attempt to use the email address provided for validation within your onboarding loop with a sufficiently unique verification URL or code. If that succeeds, the address is ... still not absolutely certainly valid, as it may have gone to a third party who proceeded to verify it. But at least it delivered to somebody.

See: https://hackernoon.com/the-100-correct-way-to-validate-email...

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#57

Earlier quoted context omitted.

There is a other email that the regexp lets pass and that’s still not valid: codetrotter@example.com It conforms to the expectated format and could be a valid email, but it’s actually not because no such user exists. An email might also exist, but not accept mail from you. The given email address might exist, by could belong to another user. There’s a million things that can go wrong and you’ll have a very hard time…

Good points. Why do regex tests at all if emails could fail in any number of ways? If you're going to test for at least 3 characters with a @ in the middle, you probably should implement some other simple rules to have a snowball's chance on the internet: only one @ no spaces has TLD (guarantee at least one period after @, and something else after, no consecutive periods) can't begin or end with a period

A (very simple) regex text might exclude some randomly-entered garbage or inadvertantly invalid address. Even then, the scope and reliability of such tests is minuscule.

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#58
post #44

Earlier quoted context omitted.

codetrotter@example is a valid email

I should have been more specific: an email address that is routable over the internet. Where's the TLD on that?

What section of what standard says a TLD can't have an email server on it? Is AAA not allowed to host an email server on `aaa`[1], and have the email `sales@aaa`?

[1]: And "aaa" is a valid TLD; see the full list: https://www.iana.org/domains/root/db ; now, perhaps it is required to at least have a second level domain, but that's what I'm asking: is an MX record invalid on a TLD?

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#59
post #22

Security Guardian is not a he/him. It may be a translation issue ... or maybe you've achieved human-level AI and it's become self-aware? In any case, I find it interesting that your first response is that the tool might have a bug ... and the link also on HN at this moment is about the Apollo 13 mission control engineers thinking their telemetry might be at fault. This is an excellent first response and it's importan…

Given the number of failures I've seen as a direct result of security and/or availability systems, the instinct to first question your own readings is a valid one. It's a good check particularly to make sure that your tests are valid, and that you aren't going off half-cocked with an alert (alarm fatigue is a Real Thing, and attention is a scarce resource).

I've also seen, in general, far more false alerts than real ones. (Yes, Nagios, I am in fact looking at you.)

The gender-casing is a quirk of the article, and would reflect at least three of the languages official within Switzerland (German, French, and Italian are all gendered languages, I'm fairly certain Romanche is as well). It's fair to note that, though perhaps not quite to the extent you did.

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#60

> "Hopefully, we had ‘only’ read access and could not write or delete anything" Sounds a lot like feigned ignorance about the nature of the root user. Not entirely sure if it would help them in a court of law. They should probably anonymized the whole thing better to be completely on the safe side (not a lawyer though).

That reads more like an attempt to make a light-hearted quip suggesting the exposure was limited. Say, more like: "OK, so we could directly access the database, but surely nobody would provide a full read/write administrative account publicly accessible and passwordless.... Oh."

Given a few other hints at English not being the first tongue (or possibly even the fourth, CH having four official co-equal languages) of the writer(s) in question, that could just be awkwardness from a non-native speaker. Their English is vastly superior to my German, French, Italian, or Romanche.

Post reply on HN