• (cs)

    It's not often I really want to do a headdesk moment. But this... this made me want to do that. Repeatedly.

    -- Seejay

  • JOHN (unregistered)

    So the WTF is that they protect against SQL injection?

    ...

  • (cs) in reply to JOHN
    JOHN:
    So the WTF is that they protect against SQL injection?

    ...

    You missed the point there.

    You don't protect against SQL injection by telling people "Don't insert SQL into the text boxes!"

    -- Seejay

  • Foo (unregistered) in reply to JOHN

    No, the WTF is that they seem to protect themselves from SQL injection by looking for a few key phrases instead of a more robust method.

  • SomeCoder (unregistered)

    Oh dear god. I'm glad I don't use them.

    No, the WTF isn't that they protect against SQL injection. It's that they really don't.

    If they really did protect against it, you could enter whatever you wanted to for your password phrase. Since they specifically try and watch out for SQL phrases rather than using parameterized queries... ugh..

    If you don't understand why that's bad, I can't help you.

  • (cs) in reply to JOHN
    JOHN:
    So the WTF is that they protect against SQL injection?

    ...

    They didn't protect against injection really. The way to protect against that is let the user add whatever he wants, then properly encode it so it is seen as a simple string before getting passed to SQL. You do not protect from injection by making sure your users never enter injection strings. If you do this, you run the risk of missing something and letting one in.

  • (cs)

    You guys are such pessimists, always worrying about the bad stuff that people could do. What about the GOOD stuff we can do, like adding $110,000,000,000 to our accounts?

    [shamelessplug] That being said, I have an ING Direct account and I can give out referral links that give you $25 when you open an ING Direct account!! Just send me a private message here. [/shamelessplug]

    NB: I just logged in and I can't even recreate this error message.

  • (cs) in reply to SomeCoder
    SomeCoder:
    No, the WTF isn't that they protect against SQL injection. It's that they really don't.

    They really don't protect and they basically tell you how to do it.

    I learned about SQL injection a few years back when working as a web programmer. I hadn't thought of it until my boss showed it to me. If I'd seen an error message like this though, I would have figured it out very fast and started poking at sites with it just to see what happened.

    Those that know about SQL injection and are willing to try it aren't going to be dissuaded by a note that says "please don't do this". Those that don't know about it just got a very quick lesson on it with this error message.

    -- Seejay

  • AdT (unregistered)

    They should have told their users that entering such things is a criminal activity. Then, no one would do it, not even the anonymous criminal hacker from Russia who's been offered $BIG_BUCKS to compromise your system and who you'll never manage to drag to a US court.

    You just have to love security by legislation.

  • random (unregistered) in reply to Pap
    Pap:
    You guys are such pessimists, always worrying about the bad stuff that people could do. What about the GOOD stuff we can do, like adding $110,000,000,000 to our accounts?

    [shamelessplug] That being said, I have an ING Direct account and I can give out referral links that give you $25 when you open an ING Direct account!! Just send me a private message here. [/shamelessplug]

    Welcome to the club.

    NB: I just logged in and I can't even recreate this error message.

  • (cs)

    I'm calling shenanigans.

  • (cs) in reply to Pap

    Who?

  • Noamsml (unregistered) in reply to JOHN

    "So the WTF is that they protect against SQL injection? "

    No, the WTF is that they do it by blacklisting rather than by escaping characters.

  • shenanigans (unregistered) in reply to Pap
    Pap:
    I'm calling shenanigans.
    You rang?
  • AdT (unregistered) in reply to Noamsml
    Noamsml:
    "So the WTF is that they protect against SQL injection? "

    No, the WTF is that they do it by blacklisting rather than by escaping characters.

    You mean "rather than by using stored procedures or parameterized queries".

    Captcha is black on dark grey (WTF?), but I can still read it.

  • (cs)

    Eminem. w3rd!

  • Jay G (unregistered)

    Original submitter here. Seems my original message got slightly mis-edited. I use two banks: Hudson Valley Federal Credit Union and ING. ING was the first to have that security feature, HVFCU added it shortly thereafter and they are the ones that gave me that popup.

    ed. note: article fixed

  • (cs)

    I say "SO?".

    Everyone here is jumping to huge conclusions about ING's actual security functionality based on a single message.

    Lot's of speculation based on a whole lotta nothing.

    Sure it's an odd message, but it says NOTHING about their underlying architecture methods. This could simply be an unfortunate message, concocted by the suits, who read an article on injection, and ignored the techies affirmations of "but we built our SQL so that it is safe from injection", to which the suits said "do these tests anyway!"

  • (cs) in reply to Jay G
    Jay G:
    Original submitter here. Seems my original message got slightly mis-edited. I use two banks: Hudson Valley Federal Credit Union and ING. ING was the first to have that security feature, HVFCU added it shortly thereafter and they are the ones that gave me that popup.

    Oh nice. So TDWTF does a WTF that makes them liable for a lawsuit by misrepresenting ING security practices as unsafe. BRILLANT!!!

  • (cs)

    Ah, I guess it's OK to use "CREATE USER" then (or whatever it is).

  • grover (unregistered)

    another aspect of the wtf is that they just gave out table names, which would aid anyone profiling the website or app or trying to do an injection attack.

  • grover (unregistered) in reply to grover
    grover:
    another aspect of the wtf is that they just gave out table names, which would aid anyone profiling the website or app or trying to do an injection attack.
    ahh scratch that. I had in my mind the additional text below was part of the screenshot.
  • (cs)

    I wonder -- if you disable Javascript, is their "SQL injection prevention" disabled too?

  • notbloodylikely (unregistered) in reply to The MAZZTer

    ALTER USER <username/> IDENTIFIED BY <password of your choice/>

  • (cs)

    They appear to be protected from SQL injection (although there's no way of telling to what extent based on that error message). They also appear to have accomplished this the worst way possible.

  • (cs) in reply to notbloodylikely
    notbloodylikely:
    ALTER USER <username/> IDENTIFIED BY <password of your choice/>

    Error: user does not have access to modify this parameter.

  • clicali (unregistered) in reply to unklegwar
    unklegwar:
    I say "SO?".

    (...) This could simply be an unfortunate message, concocted by the suits, who read an article on injection, and ignored the techies affirmations of "but we built our SQL so that it is safe from injection", to which the suits said "do these tests anyway!"

    Yes. Of course. Or maybe this WTF never really happened. Or maybe the message looks like english but really is just an advertisement in another strange language. Or maybe... you're the one that coded that?...

  • Clacko (unregistered)

    It's called Defense in Depth. They could use 100 different ways of preventing against SQL injection.

    You all only see one and assume that it's the only way they're preventing SQL injection.

  • (cs)

    Congratulations to Jay G. He is a true 'hacker' at heart. My passphrase is 'Deposit $1,000,000 in account 4568-3465-2794 ASAP"

  • (cs) in reply to Clacko
    Clacko:
    It's called Defense in Depth. They could use 100 different ways of preventing against SQL injection.

    You all only see one and assume that it's the only way they're preventing SQL injection.

    No, it's called needlessly exposing the details of your system to end users who don't understand or care -- if you're lucky.

    This is like having a dialog box come up telling the user to re-enter their text in all lowercase so that there won't be any comparison issues due to case differences.

    Which is to say, utterly stupid.

  • Harrow (unregistered)

    All right, but just what security phrase was Jay G. trying to enter, anyway?

    -Harrow.

  • Jim (unregistered) in reply to Clacko

    You protect against SQL injection by using parameterized queries NOT by trying to devise some "filter" mechanism to catch hackers.

  • null reference (unregistered)

    points for the Eminem reference

  • snoofle (unregistered) in reply to Jay G
    Jay G:
    Original submitter here. Seems my original message got slightly mis-edited. I use two banks: Hudson Valley Federal Credit Union and ING. ING was the first to have that security feature, HVFCU added it shortly thereafter and they are the ones that gave me that popup.
    I too, use ING, but they don't let you type anything into the "image" field - it's just a gif/jpeg/whatever. They also have the usual answer this, that, whatever (canned) questions, although I can honestly say I've never attempted to use "Delete xxx" as my secret answer.

    <rant>I appreciate that they're trying to make things more secure, but they keep moving the letters around on the number-pad, so you can't even get used to the clicking pattern - a f'g pain in the arse </rant>

  • (cs) in reply to zip
    zip:
    No, it's called needlessly exposing the details of your system to end users who don't understand or care -- if you're lucky.

    Not really. Let's say you always enter 'delete from' as your hint. You aren't a programmer and have no idea what SQL is. It's something you came up with randomly. Their system rejects it, BUT it has to tell you that it was rejected. It doesn't expose any details. It's only exposing the fact that they use SQL (duh). To novices it only exposes that certain phrases are not allowed, although you have no idea why.

    The WTF is that the system shouldn't have to reject these terms to begin with.

  • (cs) in reply to AdT
    AdT:
    Noamsml:
    No, the WTF is that they do it by blacklisting rather than by escaping characters.

    You mean "rather than by using stored procedures or parameterized queries".

    And what do you think do hapen to your queries when you use stored procedures and parameterized queries?

    Of course, reimplementing quotation is an entirely new WTF on itself.

  • AdT (unregistered) in reply to Mcoder
    Mcoder:
    And what do you think do hapen to your queries when you use stored procedures and parameterized queries?

    Immunity to SQL injection?

    And, thanks, I know there are brillant ways to make even stored procs or prepared parameterized queries susceptible to SQL injection, by using EXEC. But it's much harder to fuck this up than forgetting to quote that darned user input using mysql_real_escape_string_fer_shure_i_am_not_kidding_lol.

  • (cs) in reply to seejay
    seejay:
    JOHN:
    So the WTF is that they protect against SQL injection?

    ...

    You missed the point there.

    You don't protect against SQL injection by telling people "Don't insert SQL into the text boxes!"

    -- Seejay

    At least its better than nothing (which is probably much more common these days).

  • J. Pierpont (unregistered)

    At my bank, we use bind variables. However, we also send out goons to thrash wise guys who probe us with their reminder phrases.

  • Jim (unregistered) in reply to AdT
    AdT:
    Mcoder:
    And what do you think do hapen to your queries when you use stored procedures and parameterized queries?

    Immunity to SQL injection?

    And, thanks, I know there are brillant ways to make even stored procs or prepared parameterized queries susceptible to SQL injection, by using EXEC. But it's much harder to fuck this up than forgetting to quote that darned user input using mysql_real_escape_string_fer_shure_i_am_not_kidding_lol.

    Not all RDBMS have exec. I don't see how putting exec in a parameter is going to cause SQL injection. (unless you are doing something really stupid like execute the contents of this parameter as a SQL statement. (or appending the parameter to something and executing that as dynamic sql instead of a prepared statement.)

  • Andrew (unregistered)

    Bah, there's nothing wrong with this. Sure, keywords are a lousy method to prevent SQL injection, but we have no reason to believe they're the only method being used. The only design data being exposed here is that they're probably using an SQL database of some kind. Not exactly shocking news.

    And if you read the title of the article, it is clear that the "real WTF" is that a bank actually uses multiple layers of security. That's not a WTF at all.

  • Jay G (unregistered) in reply to Harrow
    Harrow:
    All right, but just what security phrase was Jay G. trying to enter, anyway?

    -Harrow.

    Funnily enough, my offense was trying to use a period, not a sql command. They just had a specific error message they gave out for any bad characters or words.

  • Jay G (unregistered) in reply to snoofle
    snoofle:
    Jay G:
    Original submitter here. Seems my original message got slightly mis-edited. I use two banks: Hudson Valley Federal Credit Union and ING. ING was the first to have that security feature, HVFCU added it shortly thereafter and they are the ones that gave me that popup.
    I too, use ING, but they don't let you type anything into the "image" field - it's just a gif/jpeg/whatever. They also have the usual answer this, that, whatever (canned) questions, although I can honestly say I've never attempted to use "Delete xxx" as my secret answer.

    <rant>I appreciate that they're trying to make things more secure, but they keep moving the letters around on the number-pad, so you can't even get used to the clicking pattern - a f'g pain in the arse </rant>

    I like the changing letters thing. The idea is that something that keylogs one login won't work the next time.

  • (cs)

    Sounds like some one hasn't heard of syntax trickery. Delete /* */from Users;

  • mh (unregistered) in reply to grover
    grover:
    grover:
    another aspect of the wtf is that they just gave out table names, which would aid anyone profiling the website or app or trying to do an injection attack.
    ahh scratch that. I had in my mind the additional text below was part of the screenshot.
    I'd be willing to put money on them using either the Northwind or Scott/Tiger tables...
  • Sigivald (unregistered)

    Seejay: Correct. You protect about SQL injection by escaping and/or parameterisation.

    However, it's not a WTF to detect possible attempts and give them a message which boils down to "Come off it, we're not that stupid."

    It's funny, not a WTF.

  • Eam (unregistered) in reply to Andrew
    Andrew:
    Sure, keywords are a lousy method to prevent SQL injection, but we have no reason to believe they're the only method being used.
    Yes we do: no one competent would do something this retarded. I'd say there's a very good chance that this is the only 'protection' they offer against SQL injection.
  • Daniel Pollock (unregistered)

    Was that an Eminem reference?

  • (cs) in reply to AdT
    AdT:
    mysql_real_escape_string_fer_shure_i_am_not_kidding_lol.

    ahahahahahaha

  • Franz Kafka (unregistered) in reply to Jay G
    Jay G:
    Original submitter here. Seems my original message got slightly mis-edited. I use two banks: Hudson Valley Federal Credit Union and ING. ING was the first to have that security feature, HVFCU added it shortly thereafter and they are the ones that gave me that popup.

    ed. note: article fixed

    How about that - I use ING and they don't have any real security - just a couple of passwords you have to enter.

Leave a comment on “Securing Secure Security”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article