Web security through threats of violence

The Daily WTF just ran a story about a company that sells listings in one of those highly questionable "business directories", and has a Web site with hilariously poor security.

(Hint: If you want to "password protect" a Web page, don't put the hard-coded username and password in the source code of the login page. Oh, and don't put the URL of the otherwise wide-open "protected" page in plaintext in the source either, or people - by which I mean, "bright eight-year-olds, or unusually well-trained monkeys" - may just copy and paste that URL to their browser's address bar.)

So far, so unremarkable.

But you need go no further than the Featured Comments below the story to find the start of a good old-fashioned Internet flameout by the owners of the site.

How dare you "hack" our site, this directory is our livelihood and we forbid you to say you think it's overpriced, we know where you live you druggie bitches, et cetera.

If you like this sort of thing, then this is the sort of thing you will like.

4 Responses to “Web security through threats of violence”

  1. magetoo Says:

    Oh, so that's what happened. I just saw there were 5 pages of comments, thought "oh, flamewar" and skipped over them.

    There's 11 pages right now (500+ comments) so this'll keep me entertained for a while.

  2. cb Says:

    Don't bother, magetoo. It's page after page of people repeating each other. I guess nobody who posts reads past the second page.

  3. adrian Says:

    After doing a PHP course, I put together a basic homepage using the stuff I learned, which included putting the mySQL name and password in the PHP source for each page. Now my understanding is that PHP is always processed on the server before being sent out, so people can't just steal my source files and hack my shit.
    Is this true or am I just as bad as the guys above?

  4. Max Says:

    Normally, that's true - the viewer of the webpage won't see the PHP part. However, if there's just the right kind of server error (spontaneous or not so much), the viewer might end up looking at the unprocessed PHP... ;) If you're just serving pages, a read-only user account might be OK. If you have logins, perhaps use the hardcoded one only to check the actual encrypted ones, then use session ID's for the rest of the pages.

Leave a Reply