• TNT (unregistered) in reply to Jim
    Jim:
    You protect against SQL injection by using parameterized queries NOT by trying to devise some "filter" mechanism to catch hackers.
    Eeerr... You protect against SQL injection by making sure that what you pass are only expected characters. The query shouldn't even be attempted if you're expecting a number and whatever was passed as a parameter not a number. Or if you're expecting a md5 and whatever what sent was not "^[a-fA-F0-9]{32}$". And if you're passing a string escaping the quote character and the SQL special characters for the 'LIKE' queries. It's that simple.
  • rottengeek (unregistered)

    even if they do have some kind of security methodology behind this inane error message we now know their table names. ( WTF? why not just have a table named "money"?) THat's like leaving the sa password blank.
    Only an idiot would put a message like that up - which leads me to think: 1. it's not true or 2. they have no idea how SQL injection works and if they have taken additional precautions, they are probably pretty easy to hack.

    I can tell you that federal restrictions are pretty tight. I can also say that it's entirely possilbe this is true.

  • Whatever (unregistered)

    Actually IDG were using the same principle to secure some of their websites. Except they wouldn't tell you what words they blocked, instead they would just say your input contained an illegal character.

    Amazing how much effort they put into hiding their vulnurabilities, and how little effort they put into fixing them.

  • Josh (unregistered)

    If your bank (or any site) requires your password or security phrase to match certain criteria (ESPECIALLY max length!), you can bet money they're storing it in plaintext.

    Or else they should be writing 6-figure corporate apps.

  • Crusoe (unregistered) in reply to Noamsml

    You don't do it by escaping either. That's not guaranteed to work either. What if you miss a keyword because the SQL dialect under the hood has different ones?

    You use bindvars. No more problems. The SQL engine takes of binding up the variables properly, and you don't have to do any work. Also, queries created using this method can be cached, and run fast.

    If your database doesn't support a bindvar style of variable substitution, you really SHOULD NOT use for any critical application.

  • Crusoe (unregistered)

    And I can't believe STILL GET THIS WRONG! Escaping, sanitizing, are frought with danger. The bindvar style, which nearly all databases support throws errors as appropriate if you try and pass in values that don't match the expected types. No need to scrub, or futz with escaping strings. The DB will tell you that "HSJD" doesn't work for a column expecting a number.

  • justin (unregistered) in reply to Pap
    Pap:
    ...Both E*Trade and Chase don't even allow ANY special characters in your password.

    "Error: Your password is too secure, use default password instead? LOL"

    one of my banks won't let me enter a password longer than six characters...

Leave a comment on “Securing Secure Security”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article