• (nodebb)

    Frist?

  • balazs (unregistered)

    410 Gone

  • Quite (unregistered)

    So TRWTF is not having the gumption to make himself a decent cup of coffee? What a loser.

  • LCrawford (unregistered)

    I was waiting for them to find out after all that work that DNS had been changed to point to an empty web site.

  • Bert (unregistered)

    TRWTF is trusting Javascript on the server. There, I said it!

  • (nodebb)

    We haven't been breached? And he answered "No."? That is the real WTF. The answer is "Yes!" but unintentionally, which makes it even worse. Security of the site was compromised just not by a malicious user, but in a much more scary fashion, by a simple mistake by a normal user. Breeches are not an intentional hack by a malicious entity, they are compromises to the integrity of the site for any reason.

  • Exploding Kitten (unregistered)

    So let me get this straight. We have a mailbox that blows up the entire house when someone puts in a wrongly sized envelope, and you want us to fix the mailbox and move on instead of searching for the hidden explosives?

  • Dave (unregistered)

    Why would you 'fix' the site if no-one's bothering to attack it? The bosses aren't wrong, it's not a good use of resources given that it's apparently not business-critical if the site goes down for an hour or two before being restored from backup.

  • Kashim (unregistered) in reply to Dave

    It depends on what kind of data is on the site. If it isn't anything sensitive, then security might not be that big a deal. If they can recover quickly the once in a blue moon that someone decides that they want to take the site down just for fun, then that might be good enough. However, since the site is something being used by "insurance agents" as Remy said in the article, then the data is likely sensitive and should be fixed, preferably BEFORE there is a break in.

    In Spartan terms: Don't wait until the enemy is at your walls to train your troops.

  • Dave (unregistered) in reply to Kashim

    It does indeed depend on the data that might be exposed. Which seems to be nil, given that everyone in the insurance industry is well-aware of the costs of an information security breach.

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    Now I want to see what happens when someone uploads a file that has spaces in its name.

    "Foo / Bar survey"

  • Sole Purpose Of Visit (unregistered)

    I don't even want to ask, but ... backups?

    Then again, I shudder to think how those would have been implemented.

  • Miles Archer (unregistered)

    Back in the desktop software era , when we had an installer and a stack of floppy disks, we had essentially the same bug. But instead of a web server being wiped, it was the users' computer. Luckily for the company (but not for him), one of the technical sales people triggered it and erased his hard disk. Boy was he pissed off.

  • DrPepper (unregistered)

    By far the best WTF in a long time. Here is a collection of mistakes that, when done individually, would cause no harm; but when combined together, leads to disaster. In most disasters, its not a single failure; but rather a cascade of failures that leads to a disaster.'

    If the code had properly returned from the error condition, no problem -- just inform the user and bail. If the file format checking code was written correctly, no problem -- inform the user and bail. If the directory deletion code had more robust parameter checking -- no problem; inform the user and bail.

    Particularly egregious is the guy who wrote the deletion code. Failure to sanity-check the path before performing deletions is just criminal. (And why delete anyway? disk space is cheap; just create a new directory and dump the files in there; leave it up to a human to archive/delete old data!)

  • Troy (unregistered)

    The web server must have been running as root, which is a terrible security decision! If the web server had only had permission in the minimal number of directories as should be the case, then this could have been avoided even with the cascade of errors.

  • (nodebb) in reply to Troy

    More likely it was just running as 'www', but that was the owner of the web content - so was allowed to delete all the content, leaving an empty site. (The article doesn't seem to suggest the whole OS was gone, as a true rm -rf / would have done, after all.)

    I'm reminded of the time, about 10 years ago, a colleague decided to set his new workstation up by applying my scripted Windows deployment image. That would have been fine, had he not transferred his old hard drive over as well ... so, of course, it got formatted and filled up with a fresh copy of Windows + apps. Whoops. (Yes, he had backups of everything important, but still, a nasty accident.)

  • jgh (unregistered)

    Back in DOS autoexc.bat days.... DEL /r %TEMP%

    Eh? What do you mean TEMP=C:\DOS ???

  • CrazyEyes (unregistered) in reply to KattMan

    Actually, I think a sturdy pair of breeches might have prevented this from happening, whether intentionally worn or not. Sorry, I had to.

  • Dave (unregistered) in reply to DrPepper

    "(And why delete anyway? disk space is cheap; just create a new directory and dump the files in there; leave it up to a human to archive/delete old data!)"

    I hate you more than I have words for. In ten years' time some intern will spend their summer checking that there's nothing actually important on a disk full of your rubbish, because no-one will believe anyone stored all that data for no reason, when it's really only there because the 'human to archive' stopped happening after the first few months.

  • Decius (unregistered)

    Bug: A bad upload can have negative side effects like server deletion or data compromise. Solution: All possible uploads must not have side effects like server deletion or data compromise. Implementation: Proper security.

  • Josh (unregistered) in reply to Decius

    It's not even "proper security". It's making sure the deletion agent can't delete anything it's not supposed to. You need to double-check all deletion code to verify that it is deleting the correct stuff. You also need to break out of a function / loop if the given case is invalid.

  • Josh (unregistered) in reply to Decius

    It's not even "proper security". It's making sure the deletion agent can't delete anything it's not supposed to. You need to double-check all deletion code to verify that it is deleting the correct stuff. You also need to break out of a function / loop if the given case is invalid.

  • (nodebb) in reply to jgh

    The one graphical DOS web browser I've used once did delete %TEMP% on exit, because no one ever sets it to C:\DOS, right. This was fixed in the release after this feature was introduced.

  • PHP: PHP Human Programmer (unregistered)

    As a bad programmer with 12 years of experience programming in PHP I fail to see what is wrong with this solution...

  • PHP: PHP Human Programmer (unregistered)

    oops, I commented on the wrong article. Like I said, I'm a bad programmer, attention to detail is not one of my skills...

  • Patrick (unregistered)

    Why was the user the web server/application is running as able to delete the contents of the site? Major configuration screw-up right there.

  • Yazeran (unregistered) in reply to Patrick

    Yep. Couldn't agree more. Apache (or whoever user the web server runs as) should NEVER have write permissions to the document root or any of the document folders within. If it has, MAJOR security bug as it will then be vulnerable to any number of code injection attacks as well as XSS etc if the site can write content to it's own source

    It is bad enough when the server can access a database and display content from that (that can be hard enough to guard against user supplied content, just ask all the sites which has fallen victim to XSS attacks over the years), but write access to what should be static pages or CGI-scripts???? WTF indeed.

  • Paul (unregistered)

    Unfortunately, he has a mono-neuronal boss.

    Just quit the effing job and go work for a human being, not a Euglena Viridis.

  • gnp (unregistered) in reply to Patrick

    Since it was able to create the content, and erasing it was part of its standard operation, I fail to see why so many people is surprised it had permission.

    Someone even mentioned the root user. At no point the article mentions the deletion of system files, only "the site" was empty.

    Any CMS has the ability to delete all the content... It's part of the content management part (the rest is just system).

  • Dan C (unregistered)

    TRWTF is always management.

  • Solomon Ucko (google)

    At least they can now rewrite the code...

Leave a comment on “Where in the World Is Our Website?”

Log In or post as a guest

Replying to comment #476694:

« Return to Article