• (cs) in reply to Paul Neumann
    Paul Neumann:
    Sea Sharp:
    Perl is its own paradigm. More than that, it's its own philosophical system. I can definitely say that I can't understand some Perl I've seen.
    Perl is not it's own paradigm. It is in the same family of languages as BrainF*ck, Taxi, and Piet. Someone just forgot to tell the Perl users it was a joke.

    From a usability standpoint, it is nearly to the level of LOLCODE.

    Yes Akismet, I just learned to [ab]use url tags. No Akismet, this is not spam.

    I know you're trolling, but this is actually funny enough to feature.

  • Some Damn Yank (unregistered) in reply to Tom
    Tom:
    If one considers JCL An language, and not some horrible misguided practical joke taken to extremes.
    I knew JCL once, but I was clever enough to never put it on my resume. It was actually fun knowing something most of my co-workers would never understand, and the power of being able to write my own code (as opposed to using the canned JCL the mysterious gnomes in the Computer Room fed us) was cool. Not quite awesome, but cool.

    You won't see JCL here, as there's no room for a WTF. It either runs or it doesn't.

  • (cs) in reply to FragFrog
    FragFrog:
    C-Octothorpe:
    I have an honest question about you questioning the original question: what gave you the idea that everybody here has a programming or technical background?
    I'm going out on a limb here, but the fact that this was posted in the CodeSOD catagory might be a hint? You know, Code Snippet of the Day? Might be directed at people who (know) code? Far fetched, I know...
    You're proving my case for me: a shitty, 'holier than thou' attitude prevents any kind of learning for people who may just be interested in programming or like participating in the comments section.
    FragFrog:
    Really though, complaining that an article in CodeSOD is not understandable for non-coders is a bit like going to a star-trek forum and asking who this Picard fellow is.
    I'm not complaining that it's not understandable for non-coders. What I am saying is that if someone is asking a question because maybe the WTF is not completely obvious to them, only to be met with ridicule stiffles learning and sours the environment (this is true in real life or a comments thread).
    FragFrog:
    Anyone with basic programming skills should know that blacklisting is not a reliable method to prevent SQL injection, and this code is a prime example of why we have so many SQL injection hacks.
    This just smacks of ignorance... So because someone has years of experience building device drivers, operating system kernels or software for radiotherapy machines should know all about web-related attack vectors?

    Also, your attitude is a prime reason why the developer who wrote this likely didn't ask anybody if there was a better way to protect against SQLi.

  • Tasty (unregistered) in reply to Rick
    Rick:
    Kyles:
    When someone says, on here, that they aren't familiar with <language> and would like someone who is to explain, what are they actually saying? I guess I'm asking coming from the position that there aren't many languages (at least within a familiar paradigm) that can just *be read* by anyone who understands programming. I have done maybe 250 lines of PHP in my life and I can grok what's going on here pretty completely.

    Unless that language is perl.

    Or APL.

    Or MUMPS.

  • Sea Sharp, Waves Hurt (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    I have an honest question about you questioning the original question: what gave you the idea that everybody here has a programming or technical background?
    Well, I don't think what I wrote implied that. From the OP, "for the non-PHP, non-SQL people among us" -- I admit that I took that to imply that while the OP was "non-PHP, non-SQL", s/he was not a layperson in terms of coding. If s/he was, I'd assume that it would've been phrased as "non-coder". If that was the case, it would make total sense to ask.
    C-Octothorpe:
    Um... When someone asks you to pass the sugar, what do you think they're asking?
    Point taken on that. It was a stupid question as phrased. What I was hoping to ask was something more along the lines of, "What is the root issue/cause implied by the need to ask the question?"
    C-Octothorpe:
    Sea Sharp:
    I guess I'm asking coming from the position that I can't think beyond myself and am trying to sound smart while doing so.
    FTFY
    Well, to be fair, I'm trying to get the people here to help me think beyond myself and understand what the issue/cause is. While I can't say that it's true that I can't think beyond myself, I often want to have the out-think happen collaboratively.
    C-Octothorpe:
    Sea Sharp:
    I have done maybe 250 lines of PHP in my life and I can grok what's going on here pretty completely.
    Congrats, that's 250 lines of PHP more than I and a huge majority of people have ever done. What makes you think that some anecdotal observation isolated to yourself only applies to the whole?
    You're taking that line out of the context of the intention of the whole post. I'm using that as ruler. If I have only written that much PHP ... the point is not that I have actually ever written PHP. The implication of that statement is that having only ever written that much, I would ostensibly be unfamiliar enough with it that I'm using my general programming syntax/grammar knowledge to understand it. I'm not using my muscle-memory familiarity with PHP. My ability to do the former contrasted with the request I originally quoted was the cause for my post in the first place.

    --

    So... The real question I have, which was reasonably called out as not clear, is: what would prevent a person who is familiar from coding within a particular paradigm from understanding (at least generally -- nuance withstanding, obviously) a piece of code from the same paradigm in a language with which they are not specifically familiar?

    CAPTCHA: paratus "Mea argumentum non paratus."

  • Jerry (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    your attitude is a prime reason why the developer who wrote this likely didn't ask anybody if there was a better way to protect against SQLi.
    //prevent sql injection
    So you're defending a "developer" who wrote this and knew enough to arrive at the magic words "SQL Injection" but had never heard of Wikipedia?

    http://en.wikipedia.org/wiki/SQL_Injection

  • (cs) in reply to Sea Sharp, Waves Hurt
    Sea Sharp:
    So... The real question I have, which was reasonably called out as not clear, is: what would prevent a person who is familiar from coding within a particular paradigm from understanding (at least generally -- nuance withstanding, obviously) a piece of code from the same paradigm in a language with which they are not specifically familiar?
    Gotcha... Realistically, they probably didn't want to appear to know absoultely nothing about programming for fear of ridicule. They probably though that saying "hey, I don't know PHP; whats the WTF" sounds better than "I've never really programmed before. What's the WTF?".
  • PoPSiCLe (unregistered) in reply to Tasty
    Tasty:
    Rick:
    Kyles:
    When someone says, on here, that they aren't familiar with <language> and would like someone who is to explain, what are they actually saying? I guess I'm asking coming from the position that there aren't many languages (at least within a familiar paradigm) that can just *be read* by anyone who understands programming. I have done maybe 250 lines of PHP in my life and I can grok what's going on here pretty completely.

    Unless that language is perl.

    Or APL.

    Or MUMPS.

    Or Haskell... I'll just leave out the link, and direct anyone who wants to hurt themselves so badly to Google...

  • (cs) in reply to Jerry
    Jerry:
    C-Octothorpe:
    your attitude is a prime reason why the developer who wrote this likely didn't ask anybody if there was a better way to protect against SQLi.
    //prevent sql injection
    So you're defending a "developer" who wrote this and knew enough to arrive at the magic words "SQL Injection" but had never heard of Wikipedia?

    http://en.wikipedia.org/wiki/SQL_Injection

    Saying "herp derp, why didn't they check wikipedia" is oversimplifying the problem to the point of being laughable. It could have been anything, really. Maybe he saw all the "senior" devs and coworkers do this so why question it. Or maybe the code was written long before SQL injection was as popular among the developer community as it is today.

    Lack of knowledge is always the root cause which can happen because lack of training, best practice like code reviews or using code analysis tools, etc.

    I'm not defending him, I'm just against that attitude which is a reason (not the only reason) why some developers do shit like this.

  • (cs) in reply to RichP
    RichP:
    Clever MUGgles, they don't know how to use the magic of mysql_real_escape_string, so they have to resort to ingenious workarounds.
    Aye, only we pure bloods are capable of proper programing. MUGgles are an insult on our order and should all be killed.
  • Sea Sharp, Waves Hurt (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    Gotcha... Realistically, they probably didn't want to appear to know absoultely nothing about programming for fear of ridicule. They probably though that saying "hey, I don't know PHP; whats the WTF" sounds better than "I've never really programmed before. What's the WTF?".
    So, what you're saying is that the motivation might have been to avoid getting responses flavored like mine? :)

    CATPCHA: erat "QED"

  • (cs) in reply to PoPSiCLe
    PoPSiCLe:
    Tasty:
    Rick:
    Kyles:
    When someone says, on here, that they aren't familiar with <language> and would like someone who is to explain, what are they actually saying? I guess I'm asking coming from the position that there aren't many languages (at least within a familiar paradigm) that can just *be read* by anyone who understands programming. I have done maybe 250 lines of PHP in my life and I can grok what's going on here pretty completely.

    Unless that language is perl.

    Or APL.

    Or MUMPS.

    Or Haskell... I'll just leave out the link, and direct anyone who wants to hurt themselves so badly to Google...

    Or Forth.

    But I do have an interesting anecdote about Haskell:

    some guy on #haskell:
    I was TA for a C++ programming course aimed at 1st year physics once. Some girl asked for help "i wrote pseudo-code but I cannot translate it to C++". Her pseudo-code was valid haskell. I cried.
  • Some Damn Yank (unregistered) in reply to Jerry
    Jerry:
    Use prepared statements.

    Or get hacked.

    Those are your choices.

    FIFY

  • big picture thinker (unregistered) in reply to Tim
    Tim:
    you don't even need to use prepared statements; you can just write a function called QuoteStringForDatabase and use this instead of putting quote characters round the value
    Actually, you really do need to use prepared statements.

    Sanitizing inputs is so '00s. Lets learn new things.

  • Jay (unregistered) in reply to Sea Sharp, Waves Hurt
    Sea Sharp:
    PedanticCurmudgeon:
    My guess is that they're saying that they're not familiar with <language> and would like to keep it that way.
    I guess I can think of a few I'd put on that list.
    Kyles:
    Unless that language is perl.
    Perl is its own paradigm. More than that, it's its own philosophical system. I can definitely say that I can't understand some Perl I've seen.

    I can definitely say that I can't understand some Javascript that I've written myself.

  • Jay (unregistered) in reply to big picture thinker
    big picture thinker:
    Tim:
    you don't even need to use prepared statements; you can just write a function called QuoteStringForDatabase and use this instead of putting quote characters round the value
    Actually, you really do need to use prepared statements.

    Sanitizing inputs is so '00s. Lets learn new things.

    Let's assume that Tim's QuoteStringForDatabase properly escapes single quotes, and all other magic characters that the db engine recognizes, if any.

    Under what circumstances would this function not work but prepared statements would?

  • Jay (unregistered)

    If user names and passwords are not allowed to have embedded spaces, as the first test is apparently enforcing, then all the tests for "or" with a space before or after are redundant. If names and passwords are allowed to have an embedded space and the first test isn't supposed to be there, then the "or" tests would prohibit, say, someone named "george orwell" from using his own name, but most names would pass. This would be rather mysterious to the poor user. It asks for his name, he types it in, and the system replies "SQL INJECTION ATTACK DETECTED! GO AWAY, BOBBY TABLES!"

  • Ninja (unregistered) in reply to Jay
    Jay:
    If user names and passwords are not allowed to have embedded spaces, as the first test is apparently enforcing, then all the tests for "or" with a space before or after are redundant. If names and passwords are allowed to have an embedded space and the first test isn't supposed to be there, then the "or" tests would prohibit, say, someone named "george orwell" from using his own name, but most names would pass. This would be rather mysterious to the poor user. It asks for his name, he types it in, and the system replies "SQL INJECTION ATTACK DETECTED! GO AWAY, BOBBY TABLES!"

    Exactly why it's a wtf! It prevents what should be acceptable behavior, while not solving the root problem.

    As for your previous question, input cleansing is not a completely reliable method and there are ways that people can still bypass those methods.

    The flipside of your question is what is the harm in having prepared statements? There is not much harm in having your database components being aware of the architecture of the database they are connecting to, and if you need to replace the database system then you may likely have to replace your database component with it anyway. It's still a perfectly valid and modular solution, and much less pain than trying to construct the query (in my opinion) anyway.

    I think I may have the best CAPTCHA of the day:

    Mara: Japanese slang for pen0r.

  • Ben Jammin (unregistered) in reply to Jay
    Jay:
    Sea Sharp:
    PedanticCurmudgeon:
    My guess is that they're saying that they're not familiar with <language> and would like to keep it that way.
    I guess I can think of a few I'd put on that list.
    Kyles:
    Unless that language is perl.
    Perl is its own paradigm. More than that, it's its own philosophical system. I can definitely say that I can't understand some Perl I've seen.

    I can definitely say that I can't understand some Javascript that I've written myself.

    Einstein:
    We can't solve problems by using the same kind of thinking we used when we created them.
  • Jerry (unregistered) in reply to big picture thinker
    big picture thinker:
    Tim:
    you don't even need to use prepared statements; you can just write a function called QuoteStringForDatabase and use this instead of putting quote characters round the value
    Actually, you really do need to use prepared statements.

    Sanitizing inputs is so '00s. Lets learn new things.

    Well, to be pedantic (and that's what this site is all about, right?) we knew that "sanitizing" bad was insufficient as far back as the previous millineum (i.e. 1999 and prior).

  • Jerry (unregistered) in reply to Jay
    Jay:
    big picture thinker:
    Tim:
    you don't even need to use prepared statements; you can just write a function called QuoteStringForDatabase and use this instead of putting quote characters round the value
    Actually, you really do need to use prepared statements.

    Sanitizing inputs is so '00s. Lets learn new things.

    Let's assume that Tim's QuoteStringForDatabase properly escapes single quotes, and all other magic characters that the db engine recognizes, if any.

    Under what circumstances would this function not work but prepared statements would?

    1. White lists FTW. List what you know is good. Reject the rest. 2. Black lists WTF. Don't do that. 3. Even if you know all other magic characters that the db engine recognizes (and you don't) the list will change tomorrow. So just stop arguing and do The Right Thing. Please.
  • GuruBOb (unregistered) in reply to Roben

    Yep, prepared statements and parameter binding all the way...

  • wcw (unregistered) in reply to GuruBOb

    Is that the same as a parameterized query? I think that's what I did in my homebrew craptacular web 'site'. Hey, it works, and it's never suffered an injection yet.

  • Sea Sharp, Waves Hurt (unregistered) in reply to wcw
    wcw:
    Is that the same as a parameterized query? I think that's what I did in my homebrew craptacular web 'site'. Hey, it works, and it's never suffered an injection yet.

    More or less. (Maybe I should type more above the link?)

    http://php.net/manual/en/pdo.prepared-statements.php

    (Hello, Akismet! My CAPTCHA was verto.) (Hi again, verto sounds like green in Franglish.) (What more do you want from me?)

  • Jerry (unregistered) in reply to wcw
    wcw:
    Is that the same as a parameterized query? I think that's what I did in my homebrew craptacular web 'site'. Hey, it works, and it's never suffered an injection yet.
    How do you know?

    Or do you mean "it's never suffered an injection yet that was so serious it made the evening news and the hackers gloated all over twitter and stuff and I had to pay out $9 million to the victims of all the compromised records plus nobody trusts me any more."

  • Sole Purpose of Visit (unregistered) in reply to Jay
    Jay:
    Sea Sharp:
    PedanticCurmudgeon:
    My guess is that they're saying that they're not familiar with <language> and would like to keep it that way.
    I guess I can think of a few I'd put on that list.
    Kyles:
    Unless that language is perl.
    Perl is its own paradigm. More than that, it's its own philosophical system. I can definitely say that I can't understand some Perl I've seen.

    I can definitely say that I can't understand some Javascript that I've written myself.

    Punks!

    I can definitely say that I can't understand the Javascript written out by a Perl program I wrote myself, and I can't understand the Perl either. What's more, I'm fairly certain the Perl program was supposed to emit Haskell in the first place...

  • Norman Diamond (unregistered) in reply to Some Damn Yank
    Some Damn Yank:
    You won't see JCL here, as there's no room for a WTF. It either runs or it doesn't.
    Oops. Consider someone who wanted to list the members of SYS1.LINKLIB and forgot to specify DISP=SHR.
  • Norman Diamond (unregistered)

    Every problem child, faced with self, says: "I know what to do. I'll use regular expressions!"

    Then problem children have twins.

  • (cs) in reply to caper
    caper:
    Why would you not use a prepared statement ? Where are these people coming from who don't yet know about prepared statements ?

    This is a humor site. It has jokes.

  • olddog (unregistered)
    // The first WTF is the use of double-quotes ...
    // so lets use single quotes so php doesn't evaluate the post vars
    
    $u = trim(stripslashes($_POST['username']));
    $p = trim(stripslashes($_POST['password']));
    $e = trim(stripslashes($_POST['email']));
    
    // filter padded spaces and escaped chars .. that's easy enough
    if(strlen($u.$p.$e) != strlen($_POST['username'].$_POST['password'].$_POST['email'])
    {
      bail(); // some bailout function that exits gracefully
    }
    //at this point we really don't care if the user name is something like "Egor or Orig";
    
    // if the mugusers table isn't too large...deny injection by reverse comparison
    $rsrc = mysql_query('SELECT * FROM mugusers WHERE mugusers.active = 1');
    $okay = FALSE;
    while($row = mysql_fetch_object($rsrc))
    {
      if(($row->username) && $row->username == $u)
      {  if(($row->password) && $row->password == md5($p)// assuming md5 encryption
        {  if(($row->email) && $row->email == $e)
          {  
            $okay = TRUE; break;
          }
        }
      }
    }
    if(!$okay)
    { 
      bail(); 
    }
    
    //---- it's okay from this point
    
  • FragFrog (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    Also, your attitude is a prime reason why the developer who wrote this likely didn't ask anybody if there was a better way to protect against SQLi.
    Really? My apologies if I sounded overly condescending, but is it really too much to ask that a developer knows at least the basics of his trade?

    I know for a fact that in some countries, you cannot sign off on an building drawing before you have at least several years experience as a junior engineer. A doctor usually spends years looking over the shoulder of a more experienced physician. Even if you want to drive a forklift, you need to have a certification before you are allowed anywhere near that thing. For almost any profession you care to name, a long track of apprenticeship and learning is considered normal. But when it comes to websites, apparently the attitude is "well, he should just be able to figure it out on his own and everyone should be kind and gentle when a mistake is made".

    Maybe I do have a 'shitty, holier than thou' attitude. But if so, only because I too made this mistake, many years ago. I learned from that, but not before thousands of users lost their data. I know first hand how dangerous it can be to work on something without understanding the fundamentals. Which is why, in my opinion, anyone working as a (web)developer should also pass some form of exam, demonstrating at least a basic understanding of things like input validation.

    And input validation is not just limited to webdevelopment. I daresay it is even more important when working on system kernels, and it is downright essential for that man working on radiotherapy machines: just imagine a user is able to enter the intensity of radiation. The program expects a dot decimal separator, but the user enters a comma. The program ignores the comma and 5,10J becomes 510J and the patient is fried. So you blacklist? Great, any input containing a comma is rejected. Now a physician who used a different machine enters 5:10J, it is again interpreted as 510J and the patient is once again fried. You keep adding different characters to the blacklist, and people keep getting fried because the input is in some different format (someone used a different character encoding, or wrote in chinese, etc). If you really thing that proper input validation is limited to webdevelopment, I fear you are the ignorant one here.

    Bottomline: some principals are so fundamental that there is simply no excuse for not learning them. Sometimes that means listening to the experienced guys to tell you how it works and what to do; no, nobody likes admitting ignorance, but a bruised ego heals much easier than ten million leaked credit-cards.

  • Hulbert (unregistered) in reply to Mario Vilas

    I read that last line as being sarcastic. Im giving the author the benefit of the doubt, I'm sure they realised there are built in PHP functions for escaping SQL strings.

    Captcha: Tristique - sadly, sorrowfully (like the feeling you get after rewriting a library function)

  • fred (unregistered) in reply to Jay
    Jay:
    Sea Sharp:
    PedanticCurmudgeon:
    My guess is that they're saying that they're not familiar with <language> and would like to keep it that way.
    I guess I can think of a few I'd put on that list.
    Kyles:
    Unless that language is perl.
    Perl is its own paradigm. More than that, it's its own philosophical system. I can definitely say that I can't understand some Perl I've seen.

    I can definitely say that I can't understand some Javascript that I've written myself.

    I have to 2nd that. Javascript code has the magical ability to confuse even its writer, with comments in place (nested callbacks, anyone?)

    On another note, that code just seems like the norm here, after surfing TDWTF for awhile.

  • gizmore (unregistered)

    ' OR strpos LIKE 0 anyone? :)

  • Jimmy (unregistered) in reply to FragFrog
    FragFrog:
    C-Octothorpe:
    I have an honest question about you questioning the original question: what gave you the idea that everybody here has a programming or technical background?
    I'm going out on a limb here, but the fact that this was posted in the CodeSOD catagory might be a hint? You know, Code Snippet of the Day? Might be directed at people who (know) code? Far fetched, I know..

    Really though, complaining that an article in CodeSOD is not understandable for non-coders is a bit like going to a star-trek forum and asking who this Picard fellow is. Anyone with basic programming skills should know that blacklisting is not a reliable method to prevent SQL injection, and this code is a prime example of why we have so many SQL injection hacks.

    My turn to go out on a limb (this tree is getting mighty top-heavy)...

    A lot of the people who visit this site are WebDevelopers, not Programmers. They may think they are capable of reading hte codeSOD articles but need some explaining.

  • mig (unregistered) in reply to Jay
    Jay:
    If user names and passwords are not allowed to have embedded spaces, as the first test is apparently enforcing, then all the tests for "or" with a space before or after are redundant. If names and passwords are allowed to have an embedded space and the first test isn't supposed to be there, then the "or" tests would prohibit, say, someone named "george orwell" from using his own name, but most names would pass. This would be rather mysterious to the poor user. It asks for his name, he types it in, and the system replies "SQL INJECTION ATTACK DETECTED! GO AWAY, BOBBY TABLES!"
    if you're consistent, wgo cares?

    George Orwell is stored as GeorgeOrwell (with the space removed) and this is what is subsequently checked.....

  • gatesy (unregistered) in reply to Jerry
    Jerry:
    wcw:
    Is that the same as a parameterized query? I think that's what I did in my homebrew craptacular web 'site'. Hey, it works, and it's never suffered an injection yet.
    How do you know?

    Or do you mean "it's never suffered an injection yet that was so serious it made the evening news and the hackers gloated all over twitter and stuff and I had to pay out $9 million to the victims of all the compromised records plus nobody trusts me any more."

    Uhm...noone visiting your site makes it nice and secure....?

  • olddog (unregistered)

    The problem with old programers who think they know more than web-developers is usually evident on their first web site effort. The old programers are the ones scrambling to to find a teenager who understands Javascript and CSS.

  • (cs)

    You had me at the first code block. I guess idiots speak every language.

  • Nebs (unregistered) in reply to Jerry
    Jerry:

    Seriously, prepared statements are so easy, and everyone keeps trying to remind you that they are the right way to do it, so why would anybody say "yeah but why can't I keep trying to build a better black-list filter?"

    Use prepared statements.

    Or stop programming.

    Those are your choices.

    I can't believe so many people are advocating the use of stored procedures. What is it with you guys? If you're using them to validate your input, then you've got some serious issues. Perhaps they might be appropriate if you've never heard of frameworks, and blindly assume that you will never have to maintain your website after it's been built, but really they are far more pain than they are worth.

    I've been dealing with a PHP project that uses stored procedures (hundreds and hundreds of them) for the last two years, which has proven to me that the concept is completely flawed for PHP programming. Not only do you have many issues with repeating yourself ad-nauseum (which means that if you try to modify any part of the database you have to modify loads of stored procedures, you invariably miss one which breaks the client site when it goes live) but if you write the stored procedure to the website as the wrong user then you won't be able to dump the database later on as a different user.

    In order of how problematic different approaches are, I would rate the types as follows:

    1. (very bad) Handwritten SQL inside PHP
    2. (bad) Handwritten SQL with mysql-real-escape-string()
    3. (bad) Handwritten SQL inside stored procedures
    4. (excellent) Automatically generated SQL made by a framework

    As an indication, I can write a simple CRUD admin system for a database table in around 60 minutes if using stored procedures, and 1 minute if using my framework of choice. Also the framework one is more secure, and quicker to update later on.

    Seriously, do yourself a favour and check out some different frameworks. I use CakePHP but there are loads of other ones out there. They will take your programming up a couple of levels, in way less time than you might think.

  • (cs) in reply to FragFrog
    FragFrog:
    C-Octothorpe:
    Also, your attitude is a prime reason why the developer who wrote this likely didn't ask anybody if there was a better way to protect against SQLi.
    Really? My apologies if I sounded overly condescending, but is it really too much to ask that a developer knows at least the basics of his trade?

    I know for a fact that in some countries, you cannot sign off on an building drawing before you have at least several years experience as a junior engineer. A doctor usually spends years looking over the shoulder of a more experienced physician. Even if you want to drive a forklift, you need to have a certification before you are allowed anywhere near that thing. For almost any profession you care to name, a long track of apprenticeship and learning is considered normal. But when it comes to websites, apparently the attitude is "well, he should just be able to figure it out on his own and everyone should be kind and gentle when a mistake is made".

    Maybe I do have a 'shitty, holier than thou' attitude. But if so, only because I too made this mistake, many years ago. I learned from that, but not before thousands of users lost their data. I know first hand how dangerous it can be to work on something without understanding the fundamentals. Which is why, in my opinion, anyone working as a (web)developer should also pass some form of exam, demonstrating at least a basic understanding of things like input validation.

    And input validation is not just limited to webdevelopment. I daresay it is even more important when working on system kernels, and it is downright essential for that man working on radiotherapy machines: just imagine a user is able to enter the intensity of radiation. The program expects a dot decimal separator, but the user enters a comma. The program ignores the comma and 5,10J becomes 510J and the patient is fried. So you blacklist? Great, any input containing a comma is rejected. Now a physician who used a different machine enters 5:10J, it is again interpreted as 510J and the patient is once again fried. You keep adding different characters to the blacklist, and people keep getting fried because the input is in some different format (someone used a different character encoding, or wrote in chinese, etc). If you really thing that proper input validation is limited to webdevelopment, I fear you are the ignorant one here.

    Bottomline: some principals are so fundamental that there is simply no excuse for not learning them. Sometimes that means listening to the experienced guys to tell you how it works and what to do; no, nobody likes admitting ignorance, but a bruised ego heals much easier than ten million leaked credit-cards.

    Just because you need undergrad-level instruction doesn't mean we all do. Competence means circumspection and a shitload of reading. Don't fuck up the field by regulating it all to hell.

  • (cs) in reply to olddog
    olddog:
    The problem with old programers who think they know more than web-developers is usually evident on their first web site effort. The old programers are the ones scrambling to to find a teenager who understands Javascript and CSS.
    Spoken like a web "developer"; I've never met one that can multithread.
  • (cs) in reply to hoodaticus
    hoodaticus:
    FragFrog:
    tl;dr

    Bottomline: some principals are so fundamental that there is simply no excuse for not learning them. Sometimes that means listening to the experienced guys to tell you how it works and what to do; no, nobody likes admitting ignorance, but a bruised ego heals much easier than ten million leaked credit-cards.

    Just because you need undergrad-level instruction doesn't mean we all do. Competence means circumspection and a shitload of reading. Don't fuck up the field by regulating it all to hell.
    News for you bubba, the field is already fucked up.

  • (cs) in reply to Nebs
    Nebs:
    Jerry:

    Seriously, prepared statements are so easy, and everyone keeps trying to remind you that they are the right way to do it, so why would anybody say "yeah but why can't I keep trying to build a better black-list filter?"

    Use prepared statements.

    Or stop programming.

    Those are your choices.

    I can't believe so many people are advocating the use of stored procedures. What is it with you guys? If you're using them to validate your input, then you've got some serious issues. Perhaps they might be appropriate if you've never heard of frameworks, and blindly assume that you will never have to maintain your website after it's been built, but really they are far more pain than they are worth.

    I've been dealing with a PHP project that uses stored procedures (hundreds and hundreds of them) for the last two years, which has proven to me that the concept is completely flawed for PHP programming. Not only do you have many issues with repeating yourself ad-nauseum (which means that if you try to modify any part of the database you have to modify loads of stored procedures, you invariably miss one which breaks the client site when it goes live) but if you write the stored procedure to the website as the wrong user then you won't be able to dump the database later on as a different user.

    In order of how problematic different approaches are, I would rate the types as follows:

    1. (very bad) Handwritten SQL inside PHP
    2. (bad) Handwritten SQL with mysql-real-escape-string()
    3. (bad) Handwritten SQL inside stored procedures
    4. (excellent) Automatically generated SQL made by a framework

    As an indication, I can write a simple CRUD admin system for a database table in around 60 minutes if using stored procedures, and 1 minute if using my framework of choice. Also the framework one is more secure, and quicker to update later on.

    Seriously, do yourself a favour and check out some different frameworks. I use CakePHP but there are loads of other ones out there. They will take your programming up a couple of levels, in way less time than you might think.

    Stupid cunting troll who needs his nuts kicked out of his gob. If you come anywhere near any of the programs I'm responsible for I'll fucking kill you, you fucking shithead.

  • Nappy (unregistered)

    Beware of the clan!!! http://obrienclan.com/

  • Mikey (unregistered)

    Real WTF is that you're building a DB query using string concatenation in the first place. Why can't a username be "OR'"? You should be using stored procedures and parameter passing, not concatenating strings. -- I really hope you're validating against HTMLi/JSi as well... I'd guess you are not from the code snippet.

  • Mikey (unregistered) in reply to Matt Westwood

    It's not about using sprocs to validate your input -- it's about them not being vulnerable to SQLi in the first place.

  • Stev (unregistered)

    I have a good grounding in C-like languages, such as C++ and Java and I know a bit of other languages (lua, BASIC, etc.) but I stay the hell away from anything remotely webby, like PHP and even anything beyond simple HTML because it's not something I'm particularly interested in - so for me, this WTF wasn't completely obvious, although from the context I had an idea as to what the WTFer was trying to do and didn't - I just didn't know why.

    I'm thankful to the people who have explained it, I've learned a little something and if 5 or 10 years down the line I happen to be asked to "take a look at" some PHP, there's a chance this little nugget will pop up and I'll have a vague idea where to look, rather than just going "hurrr, dunno anything about PHP". There is absolutely no shame in asking questions about something you don't understand, especially when the site in question revolves around the people who don't understand it in the first place.

    It's for the same reason that quip about regex went over so many people's heads - if you just don't know PHP, you're sure as hell not going to know best practices in PHP.

  • milleniumbug (unregistered) in reply to Nebs

    Really? YOU have issues - PREPARED STATEMENTS are not STORED PROCEDURES. Prepared statements are completely different.

    PHP Data Object Google it.

  • (cs)

    ...actually, every time i see something like this, i wonder if i'm doing it wrong, or just people don't get how simple it can be... i run every user input through htmlspecialchars($blah, ENT_QUOTES), and i NEVER got any SQL injection by using this (i tried to attack one of my sites using this by all SQLI methods i know of, none worked).

Leave a comment on “SQL MUGging”

Log In or post as a guest

Replying to comment #:

« Return to Article