• SELECT frist FROM comments; (unregistered)

    .

  • Federico B (unregistered)

    Seems easy: "You're letting the client access our full database. Sign here." No need to go sour for a choice by who pays you.

  • gleemonk (unregistered)

    I don't really see the problem here. Of course you want some form of auth which might be missing, the article doesn't say. But after that, what's the big deal? If he requested SQL access, would you deny it because it "allows SQL injection"? It's his DB for WTF sake.

    Also if you can't keep this box from talking to the other boxes in your datacenter, why are you running a datacenter?

  • Andreas (google)

    So where's the problem in giving the script its own user with which to access the DB?

  • Chris Paterson (google)

    Why are they viewing it as a binary yes or no to the whole shebang? Surely there's room for discussion and negotiation along the lines of "we'll host this if you take out the offending code"? The customer can likely work assume l around the loss of this functionality.

    Addendum 2016-08-18 08:12: *delete "assume I"

  • Derp (unregistered)

    TRWTF is why there are so many stories these days that are considered WTFs when they're pretty standard things.

  • solitario (nodebb)

    I understand that you don't want to give unlimited SQL access to a shared database, but I could see lot's of opportunities for mitigation here:

    • dedicated account with only limited privileges
    • on a dedicated database
    • on dedicated hardware
    • with a fresh install of the software
    • in dedicated private network
    • only accessible through a VPN
    • that can only be accessed from the client's office

    Of course this will lead to some higher setup and maintenance costs, but hey, those are billable hours and this setup pretty much isolates this thing from everything else, so it will most likely become one of those expensive machines the client can't do without, and has no way of ever replacing with something else. Sounds like pretty good business to me.

  • Griwes (unregistered)

    I've been saying this for years: having users/clients/whatever else you call them is the worst thing that can happen to anyone in this poor industry.

  • Ext3h (unregistered)

    The real WTF would be why the database user even has permissions which could possibly lead to accessing confidential data? Views and permissions exist just for such scenarios, to provide "arbitrary", native access to the database, without actually providing full access.

  • PWolff (nodebb) in reply to Derp

    I think that is because this site is not darwinawards.com where "too common" is a disqualification criterion.

  • Foo AKA Fooo (unregistered) in reply to Griwes

    Not at all! The question is what you do with them. solitario got it just right:

    Give them their own DB, or access to your DB with very limited access, firewall their internet connection, etc. If you don't know how to do this, you shouldn't be in this business. Heck, I could do all this rather easily, and web hosting etc. is not really my main line of work.

    Let them screw themselves, then help them get out of them mess -- either by implementing a proper solution once, or just fixing the symptoms repeatedly. Either way: Profit!

  • Mason Wheeler (unregistered)

    Karla is TRWTF here, for not pulling out the L word.

    Talk to the boss, and if that doesn't work, talk to Legal, and explain that knowingly putting a vulnerability in place that could expose their code to loss of client data would potentially open them up to some very serious liability. That'll cut through all the "the customer is always right" nonsense faster than anything.

  • another guest (unregistered)

    TRWTF is that the wikipedia logo on the thinkpad's screen is blurred out. But then again, even featureless white spheres need their personality rights respected.

  • Bananafish (nodebb) in reply to Derp
    TRWTF is why there are so many stories these days that are considered WTFs when they're pretty standard things.

    TRWTF is this and things like it have become the New Millenial Standard: If you don't understand how something works, branch a for, go off the rails, and just type whatever the fuck you want.

  • Bananafish (nodebb) in reply to PWolff
    I think that is because this site is not darwinawards.com where "too common" is a disqualification criterion.

    Probably why Wendy's been dry for awhile?

  • Alex (unregistered)

    Why didn't they just put the code in a virtual machine? If Amazon EC2 instances can run that code without exposing other machines, surely Karla's company can figure it out. Worst case scenario, Dave could just proxy to an EC2 instance.

  • Appalled (unregistered)

    I don't get it. connection=Vertica.connect({<redacted>}. Presumably the connection string will log the client in to a specific Instance as a specific user with a specific password. Assuming the DBA's do their job right, that user won't be able to do anything in any instance but their own. Limit them further as desired, no alters, no master, no msdb, no grants, no logins, whatever. Pin him down so the only thing he can do is view/change to his own data in his own table in his own instance and then who gives a s..t if his software allows hackers to destroy his data. It's his to do with as he wishes. What am I missing? Does that json stuff allow injections to the Connection string as well?

  • Ron Fox (google)

    "There is always an inherit tension between our area of expertise, ..."

    That looks very OO I think the word you wanted was "inherent"

    Having said that, there are admittedly rare cases when there are people that have both a deep domain knowledge and are quite good programmers.

  • RichP (unregistered)

    Hmm, was this a dodgy Chinese site that sold hair straightener? If so, I know what eventually happened to it. Some Anonymous Coward over on El Reg nuked it.

  • MatsSvensson (unregistered)

    So if i understand correctly, that code might make the server run 10 times the speed of light, which in turn would allow it to exist in all locations of the database simultaneously, which would make hacks happen?

    Well we just cant have that!

    Lower it to the bottom of the ocean, just to be safe!

  • Developer Dude (unregistered)

    It is good to confirm that I am not the only technical person, hired for my technical knowledge and experience, whose bosses ignore, when it comes to technical issues. But what the hell do I know?? After all, they only hired me to give them that technical expertise - what they do with it is up to them. sigh

  • Barf 4Eva (unregistered)

    For some reason, when I saw the title of this article, I thought it was going to be about dependency injection... :|

  • Jeremy Hannon (google)

    I have seen much worse scenarios in production. Take that, attach it to a database running in production, and give the account that executes the query SA access to the server... oh, and add in that the software on the internet side was what provided the server name and database name where the query gets executed.

    Addendum 2016-08-18 20:58: NOTE: For the record, this was many years ago and not at my current employer.

  • cheong (nodebb) in reply to solitario

    Except when there is something wrong in HIS database, THEY will fine your company for the outtime, and they may demand collection for damage that will cost YOUR job.

    Yup. If this is to be hosted, even when you decide to put it in isolated environment, written consent to give up any right for the client to sue should be mandatory here.

  • löchlein deluxe (unregistered)

    Well, I've seen the reverse, too: a system that parsed inbound SQL queries and matched them against user privilege. Of course, that would have worked so much better if it recognized an indented SELECT as a SELECT and not a "something else, deny with r/o privileges". Of course, the original programmer is long gone and it's the fault of the underlying service provider (i.e. us) now.

  • Nuisant Nausela (unregistered)

    trwtf is of course creating an app that will allow you to execute SQL when there probably already is a better management tool available for that specific DB.

  • Bert (unregistered) in reply to Bananafish

    "Millenials" are 36 years old this year. What is the point you are trying to make?

  • anonsystemseng (unregistered) in reply to Bananafish

    You act like "way more programmers than you'd think write awful code" was at some point not true.

    I spend quite a lot of time porting code that would've been written in the 80s. Trust me. You're imagining it only because there are a lot more programmers these days.

  • Guntank (unregistered) in reply to gleemonk

    Liability. If the client's DB gets SQL Injected and it's discovered that the developers knew beforehand of the vulnerability, a) who will the client still throw under a bus anyway and b) who ends up getting sued?

  • Nobody (unregistered) in reply to Mason Wheeler

    "...talk to Legal, and explain that knowingly putting a vulnerability in place that could expose their code to loss of client data would potentially open them up to some very serious liability. That'll cut through all the "the customer is always right" nonsense faster than anything."

    Haha, I bet it would!!! That said, the guy's boss might be incensed that he went to legal instead of accepting his verdict without question.

Leave a comment on “Injection By Design”

Log In or post as a guest

Replying to comment #:

« Return to Article