• aaron (unregistered) in reply to Here I'll defeat it
    Here I'll defeat it:
    update financialrecords set amountinallbankaccounts = 1000000000000000;

    Msg 208, Level 16, State 1, Line 1 Invalid object name 'financialrecords'.

  • (cs) in reply to Marty
    Marty:
    Quirkafleeg:
    Johnno:
    Hows about making sure that certain punctuation characters aren't allowed in a name field. An Apostrophe or a hyphen are probably the only non-alphabetic characters required to display a name
    Spaces, accented letters, and some language-specific letters are required even if you're sticking with Latin alphabets, although I suspect that some Germans are well used to using ‘ss’ or ‘sz’ instead of ‘ß’…

    Might be nice to have but are certainly not required....(I know many people who have names with umlauts or other marks, who simply leave them off when creating forms). If required, you can always create an 'allowable character set' (which you can later extend if you need to because vast hordes of people want a certain character).

    Either way, my reading is that the OP was saying you can filter punctuation and non-alphabetic letters. Language specific letters and accented letters would still be letters, I would think, so I'm not quite sure the point you're making?

    Quirkafleeg:
    An unhappy pentester:
    Better yet, don't allow manky data that it's difficult to handle into your database in the first place. Telephone field? Why not only accept numeric characters and dashes?
    You'd want to allow a leading ‘+’ for reporting fax errors to somewhere in India.
    Both of you seem to have limited experience in making sure your application can handle international data.

    I always get annoyed when I have to figure out how to write something just so whatever form requires it, accepts it.

    Even things that first ask you what country you live in, and then go on asking you what state, even if you don't happen to be living in a federal state, and the only ones they allow you to pick are the USA states, and sometimes the Canadian ones.

    I find the safest way to handle things, is to store it as unicode. Even telephone numbers, if if those are relatively tame in my experience.

    It's not funny if you can't enter your own name properly, and you have to mangle it.

  • Marty (unregistered) in reply to RogerWilco
    RogerWilco:
    Marty:
    Quirkafleeg:
    Johnno:
    Hows about making sure that certain punctuation characters aren't allowed in a name field. An Apostrophe or a hyphen are probably the only non-alphabetic characters required to display a name
    Spaces, accented letters, and some language-specific letters are required even if you're sticking with Latin alphabets, although I suspect that some Germans are well used to using ‘ss’ or ‘sz’ instead of ‘ß’…

    Might be nice to have but are certainly not required....(I know many people who have names with umlauts or other marks, who simply leave them off when creating forms). If required, you can always create an 'allowable character set' (which you can later extend if you need to because vast hordes of people want a certain character).

    Either way, my reading is that the OP was saying you can filter punctuation and non-alphabetic letters. Language specific letters and accented letters would still be letters, I would think, so I'm not quite sure the point you're making?

    Quirkafleeg:
    An unhappy pentester:
    Better yet, don't allow manky data that it's difficult to handle into your database in the first place. Telephone field? Why not only accept numeric characters and dashes?
    You'd want to allow a leading ‘+’ for reporting fax errors to somewhere in India.
    Both of you seem to have limited experience in making sure your application can handle international data.

    I always get annoyed when I have to figure out how to write something just so whatever form requires it, accepts it.

    Even things that first ask you what country you live in, and then go on asking you what state, even if you don't happen to be living in a federal state, and the only ones they allow you to pick are the USA states, and sometimes the Canadian ones.

    I find the safest way to handle things, is to store it as unicode. Even telephone numbers, if if those are relatively tame in my experience.

    It's not funny if you can't enter your own name properly, and you have to mangle it.

    Other than the fact that you are clearly right.... Other than maybe my first line about I have never met anyone who has an issue dealing with systems that don't cater for accents, umlauts and similar punctuation, there is little in my post that has anything to do with internationalisation (and so I've taken it to heart that you accuse me of being inexperienced in such things).

    To have an allowable set of characters is (IMHO) reasonable, especially if it can be extended as required. You don't (unless you are incredibly stupid) have to sit there trying to work out how to do it (as you suggest). This isn't about selecting multiple options, it's about entering data via the keyboard.

    Further, it's a 'horses for courses' thing...Why would you allow '$' in a Name field? (In a currency field, it's another matter, perhaps).

    I don't suggest anywhere that international characters be avoided - if anything, I endorse the idea (or that was my intent).

    Anywho, it's late and I'm grumpy, so MAH!!

  • (cs) in reply to Marge
    Marge:
    frits:
    Homerclese:
    DeepThought:
    <snip> Of course, it's almost impossible to catch all known and future attack vectors using a technique such as the one demonstrated in the code as the variations could be endless (example: "language = javascript" would not be caught). It would be far better to use parametrized SQL statements, stored procedures, and/or to HTML encode the incoming data before persisting it in the DB thus making it safe to display in a browser.

    Thankfully, not altogether impossible. Simply post any code that you propose to use in the 'real world' on this site and the resident experts will gladly explain all the vulnerabilities.

    As an added bonus, they will also collaborate together to ensure that you have adhered to the most stringent programming principles and assess your value as a developer (if not human being)....

    There are far more sarcastic, trolliscious, and flat-out wrong answers here than any real solutions. But feel free to post any code at all--you will be mocked for your crappy code and/or your inability to see that is/is not bad.

    Indeed!!

    I think perhaps you missed the point....

    No.

  • oheso (unregistered)

    Yes, proper parameterization; No, home-grown solutions.

    The first bit of the code escapes characters without checking if they're already escaped. Doh!

  • (cs) in reply to sprained
    sprained:
    DeepThought:
    It would be far better to ... HTML encode the incoming data before persisting it in the DB thus making it safe to display in a browser.

    Please don't do that. Then when you have to send a plain-text email or export a CSV or let the user-re-edit the content or any of a number of other things you' end up with, for instance, """ peppered all over your text.

    well, you can still html decode the data, if you need to get them to "editable" form... i would even think of it as a logical step, doing it automatically after retrieving the data from DB (exept cases when you don't need it, offcouse)

  • Epoch (unregistered)

    I would kill if i saw this in our codebase

  • yr (unregistered)

    I doubt the uppercase version of &eacute is &EACUTE

  • Paul (unregistered) in reply to panzi
    panzi:
    Is there a standard conform SQL database? You always have to assume that your SQL code will be run on some crap DB so you should use prepared statements.

    I've hardly ever come across anything which will run on ANY DB..

    ODBC stuff maybe (but not guaranteed, unless it only does trivial things), but otherwise most times people require a specific database, or a specific set of databases. If you want to use stored procedures/triggers/custom functions/custom data types, then most DBs use non-standard stuff, so anything you write will only work on one DB.

    Even preparing statements works differently on different DBs. Some DBs don't support them at all (eg SQLite). The API might, but what do you think that is doing, other than converting ' to '' in parameters... The ones that do, handle them differently, eg some use '?' for parameters (which can't be reordered or reused), others use $1, $2 etc for parameters (which can be reordered and reused within the query) and so on.

    So, once you know the DB you are using, it's easy to quote parameters. If you have an abstraction layer in your code to handle multiple database engines, then it's trivial to add a suitable quoting function to that. It can be considerably harder to add prepared statement capabilities to a database abstraction layer.

    For instance, in our abstraction layer, we have a function which we pass a 'pseudo prepared statement' containing parameter types (similar to a printf string; similar to many database's built in 'prepare' statements) and parameters, which are all then converted and quoted accordingly. We don't use DB based prepared statements because, with all the semantic differences between the different databases we support, it is over complicated, when our system works just as well, and is safe from injection attacks, because the abstraction layer can do type checking and knows how to quote for our supported databases.

  • pflock (unregistered) in reply to Tim

    Stop being picky.

    CAPTCHA: odio. Do I really have such a bad breath?

  • fw (unregistered) in reply to Tim
    Tim:
    Paul:
    Won't the first bit protect against SQL injections? So, it is actually safe now?

    OK, the second bit (all the replaces) is dumb, but converting ' to '' is all that is required isn't it (even though it is being done in a lame way in this case)?

    Or am I missing something?

    You're missing something:

    ''; DROP TABLE users; --

    Source: http://unixwiz.net/techtips/sql-injection.html

    Also, captcha quoters: You're not funny. You're tedious. Tedious and boring.

    ooooh get her!

  • (cs) in reply to Grr
    Grr:
    If you don't limit DB access via Stored Procedures and Prepared Statements then you deserve all the pain you will get (and it's just a matter of when).

    Still, if you're a dumbass and persist in building your own queries, at least do something like this with your inputs...

    internal static string FQ(string WhichField) { if (WhichField != null) { WhichField = Regex.Replace(WhichField, @"[^\sa-z0-9]", "", RegexOptions.IgnoreCase | RegexOptions.SingleLine); } return WhichField; }

    Please, please, please, please, stop telling people that stored procedures do anything to prevent SQL injection.

  • Jeff K. (unregistered) in reply to SEMI-HYBRID code
    SEMI-HYBRID code:
    sprained:
    DeepThought:
    It would be far better to ... HTML encode the incoming data before persisting it in the DB thus making it safe to display in a browser.

    Please don't do that. Then when you have to send a plain-text email or export a CSV or let the user-re-edit the content or any of a number of other things you' end up with, for instance, """ peppered all over your text.

    well, you can still html decode the data, if you need to get them to "editable" form... i would even think of it as a logical step, doing it automatically after retrieving the data from DB (exept cases when you don't need it, offcouse)

    Yes, you can. You can also turn everything into Pig Latin before storing it in the database and turn it back when you need the actual verbiage, but this doesn't make sense, either. HTML-encoding the data should be specific to displaying the data in HTML, not storing the data in the database which has no concept of HTML.

  • SR (unregistered) in reply to yr
    yr:
    I doubt the uppercase version of é is &EACUTE

    In HTML It's É

  • SR (unregistered)

    Anyone suggesting anything other than a prepared statement should be asking people if they want fries with that

  • Anonymous Coward (unregistered) in reply to sprained

    I never ceased to be amazed by people who understood what an SQL injection was and that now think they know it all about security when they can spot a SQL-injection vulnerable piece of code.

  • DaveE (unregistered) in reply to DeepThought
    DeepThought:
    It would be far better to ... HTML encode the incoming data before persisting it in the DB thus making it safe to display in a browser.

    Please don't do that. HTML Encoding is formatting for a particular use. Please store the real data and format it when needed.

  • Quirkafleeg (unregistered) in reply to Anonymous Coward
    Anonymous Coward:
    I never ceased to be amazed by people who understood what an SQL injection was and that now think they know it all about security when they can spot a SQL-injection vulnerable piece of code.
    Me too. I've seen them, and I've seen overflows, use-after-free, and unchecked values in C code, and and and…

    I know all about security, me.

  • Quirkafleeg (unregistered) in reply to RogerWilco
    RogerWilco:
    It's not funny if you can't enter your own name properly, and you have to mangle it.
    My point exactly.

    I sometimes hit the same problem with email addresses and idiotic form validation allowing only ASCII alphanumerics and a few symbols.

    (Hmm. The next time that I encounter this, I'm going to determine whether the validation is Javascript-only and, if it is, use a convenient browser extension to rip out that validation…)

  • James (unregistered) in reply to Paul

    Would not replacing any "--" with "- -" do it? If a nefarious statement is inserted, and the sql following it is the remnants from what should have been the statement is not commented out, won't the compiler cause the entire statement to fail?

    I know that an app that wants the "--" as, say, part of a text field entry will never get that, but for typical "enter your name" etc. sites this would work, no? --Jim

  • Jay (unregistered) in reply to RogerWilco
    RogerWilco:
    Even things that first ask you what country you live in, and then go on asking you what state, even if you don't happen to be living in a federal state, and the only ones they allow you to pick are the USA states, and sometimes the Canadian ones.
    <pedantry> There are no "states" in Canada. Canada is divided into provinces. </pedantry> <pedantry level=2> There are only 48 states in the United States. Virginia and Kentucky are "commonwealths". The District of Columbia and Puerto Rico are also often included on a "States" dropdown, when they clearly are not states. </pedantry>
  • Jay (unregistered) in reply to Jeff K.
    Jeff K.:
    Yes, you can. You can also turn everything into Pig Latin before storing it in the database and turn it back when you need the actual verbiage, but this doesn't make sense, either. HTML-encoding the data should be specific to displaying the data in HTML, not storing the data in the database which has no concept of HTML.

    What a great idea! This will prevent SQL-injections attacks, as last I checked SQL does not recognize the "ropday abletay" command. And it also encrypts the data, thus protecting it from any hackers who do not know Pig Latin.

    Seriously now, why is it that every time someone points out the flaws to a bad idea, there's always someone else to point out how, if you just stand on your head and learn to whistle under water, you could make it work?

  • Jay (unregistered) in reply to Tim
    Tim:
    or *use the god damn escape function provided by the library!*

    Umm, and in Java, or C++, just what is the name of that function in the library? I've always wondered why the Java JDBC package does not include such an escape function -- like maybe call the same function that they surely use for prepared queries -- but they don't expose it, so you have to write your own.

    Not that writing your own is hard.

  • Jay (unregistered) in reply to LoztInSpace
    LoztInSpace:
    You can and should still use parameters. With a bit of thought there is nothing to stop you dynamically building a query that is like

    SELECT x, y, z from a, b, c where p=? and q=? and r=? then go through & add all the parameters.

    rather than

    SELECT x, y, z from a, b, c where p='bob' and q='arthur' and r=27

    You quite obviously have all the information you need so why not just do the right thing?

    Umm, yes, but what if you have something more like this:

    String q="select customer_id from customer"
    if (min_balance!=null || max_balance!=null)
      q+=" left join transaction using (customer_id)";
    q+=" where active=true";
    if (city!=null)
      q+=" and city="+esc(city);
    if (accountType!=null)
      q+=" and account_type="+esc(accountType);
    if (min_balance!=null)
      q+=" and sum(transaction.amount)>="+min_balance;
    if (max_balance!=null)
      q+=" and sum(transaction.amount)<="+max_balance;
    if (sort==SORT_NAME)
      q+=" order by customer.last_name";
    else if (sort==SORT_CITY)
      q+=" order by customer.city, customer.address";
    

    Please tell me how you would do that with a prepared statement.

    Sure, in principle, you could construct a separate prepared query for every possible combination of conditions, and then plug the values in to the right place in each of these. But I've had plenty of cases in real life where I constructed queries on the fly like that where there were easily hundreds of possible combinations. Not only would this be very tedious to code, but it would be a nightmare to maintain, as every change would have to be made dozens of times. And imagine testing such a monstrosity!

    I have nothing against prepared statements, but in all but the most simple applications, I routinely have to build queries on the fly out of pieces like this.

  • iMalc (unregistered) in reply to Jaime

    Of course they do something you idiot! Quote from one webpage: "stored procedures can help to provide protection against SQL Injection attacks, but ultimately developers must understand the underlying causes of these vulnerabilities and build applications with the appropriate threats in mind.".

    In the case of the article it's great to see that if we use two spaces between 'drop' and 'table' that we're still going to be able to do the damage.

  • Jay (unregistered) in reply to An unhappy pentester
    An unhappy pentester:
    Better yet, don't allow manky data that it's difficult to handle into your database in the first place. Telephone field? Why not only accept numeric characters and dashes? Address field? Why do you need CRs, LFs, null bytes, and diamond brackets?

    If you whitelist characters for given form fields, and encode whenever you handle data from untrusted source ... etc

    While I'm all for validating inputs, this could never be a general strategy against SQL injection. Yes, you can limit telephone numbers to hyphens and digits, etc., but sooner or later your database will surely have some field where almost any character is valid. How about a field to hold the text of a math problem? Are you going to bar "<" and ">"? That would be a little impractical. Or how about a field for text of posts on a SQL programmers forum? Hard to see how you could exclude anything that might look like SQL commands from that. For that matter, SQL injection doesn't require bizarre, far-out characters that people wouldn't use in many text fields: Just single quotes, semi-colons, and alphabetics, really. Are you going to forbid the use of contractions in all text fields?

    A solution that "usually works" just isn't really practical. Especially when we're talking about security, when you know that the hackers will be looking for the one place where there's a hole.

  • Sigivald (unregistered) in reply to Paul

    Panzi said You always have to assume that your SQL code will be run on some crap DB so you should use prepared statements

    Well, I dunno about you, but I sure as hell don't.

    My SQL code will be run on MS SQL Server (normally Express edition), and nothing else, period, end of statement.

    Of course, that's because I'm not a web developer...

    Or in whatever other really weird niche it is that means you have to write ODBC code against arbitrary backing stores...?

  • (cs) in reply to Jay
    Jay:
    <pedantry level=2> There are only 48 states in the United States. Virginia and Kentucky are "commonwealths".... </pedantry>

    So are Massachusetts and Pennsylvania. If you're going to be pedantic, at least be correctly pedantic.

  • (cs) in reply to Jay
    Jay:
    String q="select customer_id from customer"
    if (min_balance!=null || max_balance!=null)
      q+=" left join transaction using (customer_id)";
    q+=" where active=true";
    if (city!=null)
      q+=" and city="+esc(city);
    if (accountType!=null)
      q+=" and account_type="+esc(accountType);
    if (min_balance!=null)
      q+=" and sum(transaction.amount)>="+min_balance;
    if (max_balance!=null)
      q+=" and sum(transaction.amount)<="+max_balance;
    if (sort==SORT_NAME)
      q+=" order by customer.last_name";
    else if (sort==SORT_CITY)
      q+=" order by customer.city, customer.address";
    

    Please submit this for CodeSOD.

  • (cs) in reply to NoAstronomer
    NoAstronomer:
    and of course in a years time some poor sap of a developer will be trying to use a query that does actually need a UNION and will have no idea why it doesn't work.

    Ummm, only if that developer was entering SQL via the Name field of a webform, or some related idiocy. It's not like this code gets run when they type SQL into the database admin application.

  • Speaker-to-Animals (unregistered)

    Jesus, haven't these people ever heard of SQL parameterization?a

  • caper (unregistered)

    Please tell me how you would do that with a prepared statement.

    Use an array. Trying some PHP off the top of my head:

    if ( condition1 ) { ....sql .= "where thing = ?" ....array_push( params, value1 ) } if ( condition2 ) { ....sql .= "and thing = ?" ....array_push( params, value2 ) }

    foreach( params as value ) { ....i++; ....statement->bindParam( i, value ) }

    Handling of "AND" vs "WHERE" left as an exercise for the reader.

  • blunder (unregistered)

    The other day we got the inevitable spat of comments where 20 PHP developers pointed to the other 19 and said, "I'm not like those guys."

    Today's group must be a different 20, because they're all proposing SQL injection "solutions" that involve building queries directly from user input.

  • Tharg (unregistered)

    Alternatively, you could go completely bonkers and use a stored procedure. That way the DB itself would be invulnerable to sql injection attacks in any and all forms, for the simple reason that there would be no SQL to inject.

    Anything else is posturing (and drivel).

  • Tharg (unregistered)

    Oh,

    and by the way, I was so busy going OTT about SQL injection that I forgot to mention the lunacy of allowing the application to do DDL on the fly. How exactly can a DBA (such as myself) manage a system where the db is altered by the application unannounced and uncontrolled? If anyone could oblige me with an informed answer to that I'd be ever so grateful.

    As to the PHP idiots out there, I call bullshit on you. You post a clear cut statement of requirement, and I'll post the Oracle stored procedure that does it, complete with unit tests and outcomes.

    Conduct yourselves on the basis of demonstrable proven code, not assertions and assumptions.

    Put up or shut up.

  • (cs) in reply to Tharg
    Tharg:
    Oh,

    and by the way, I was so busy going OTT about SQL injection that I forgot to mention the lunacy of allowing the application to do DDL on the fly. How exactly can a DBA (such as myself) manage a system where the db is altered by the application unannounced and uncontrolled? If anyone could oblige me with an informed answer to that I'd be ever so grateful.

    As to the PHP idiots out there, I call bullshit on you. You post a clear cut statement of requirement, and I'll post the Oracle stored procedure that does it, complete with unit tests and outcomes.

    Conduct yourselves on the basis of demonstrable proven code, not assertions and assumptions.

    Put up or shut up.

    Dude, is this your first time on the internet? No one's going to shut up.

  • PITA (unregistered) in reply to Sigivald
    Sigivald:
    Panzi said You always have to assume that your SQL code will be run on some crap DB so you should use prepared statements

    Well, I dunno about you, but I sure as hell don't.

    My SQL code will be run on MS SQL Server (normally Express edition), and nothing else, period, end of statement.

    Of course, that's because I'm not a web developer...

    Or in whatever other really weird niche it is that means you have to write ODBC code against arbitrary backing stores...?

    MS SQL Server Express - so Panzi was right?

  • Leo (unregistered) in reply to Jay
    Jay:
    RogerWilco:
    Even things that first ask you what country you live in, and then go on asking you what state, even if you don't happen to be living in a federal state, and the only ones they allow you to pick are the USA states, and sometimes the Canadian ones.
    <pedantry> There are no "states" in Canada. Canada is divided into provinces. </pedantry>

    Yes.

    <pedantry level=2> There are only 48 states in the United States. Virginia and Kentucky are "commonwealths". The District of Columbia and Puerto Rico are also often included on a "States" dropdown, when they clearly are not states. </pedantry>

    No.

    1. Massachusetts and Pennsylvania are "Commonwealths" also.
    2. Nonetheless, MA, VA, PA, and KY are still states, they are just states named "Commonwealth of X", instead of "State of X".

    (Puerto Rico and the Northern Mariana Islands are also named "Commonwealth", but are not states.)

  • (cs)

    Lots of high level intellectual wanking going on here, but no-one with their feet on the ground. In the real world, how does anyone know if SQL injection works? They might go around randomly testing simple SQL injections, but if 1=1 and 2=2 don't work, they probably stop there.

    Simple solution for minimal security: pass all your text input strings to the database in reverse order (i.e. right to left text order)...

  • Jay (unregistered) in reply to Someone You Know
    Someone You Know:
    Jay:
    <pedantry level=2> There are only 48 states in the United States. Virginia and Kentucky are "commonwealths".... </pedantry>

    So are Massachusetts and Pennsylvania. If you're going to be pedantic, at least be correctly pedantic.

    I concede. I have been out-pedanted. I was going from memory -- I forgot about MA and PA.

    If this had been a real act of pedantry and I was actually trying to ridicule someone, I would have looked it up.

  • Jay (unregistered) in reply to caper
    caper:
    >Please tell me how you would do that with a prepared statement.

    Use an array. Trying some PHP off the top of my head:

    if ( condition1 ) { ....sql .= "where thing = ?" ....array_push( params, value1 ) } if ( condition2 ) { ....sql .= "and thing = ?" ....array_push( params, value2 ) }

    foreach( params as value ) { ....i++; ....statement->bindParam( i, value ) }

    Handling of "AND" vs "WHERE" left as an exercise for the reader.

    Okay, I'll buy that, that will work. Seems to me like it's a lot harder to read than just writing an escape function and using it where you need it, though. 'Might create performance issues with creating prepared statements that are only used once each, but I guess I'd worry about that if it happened.

  • Jay (unregistered) in reply to frits
    frits:
    Jay:
    String q="select customer_id from customer"
    if (min_balance!=null || max_balance!=null)
      q+=" left join transaction using (customer_id)";
    q+=" where active=true";
    if (city!=null)
      q+=" and city="+esc(city);
    if (accountType!=null)
      q+=" and account_type="+esc(accountType);
    if (min_balance!=null)
      q+=" and sum(transaction.amount)>="+min_balance;
    if (max_balance!=null)
      q+=" and sum(transaction.amount)<="+max_balance;
    if (sort==SORT_NAME)
      q+=" order by customer.last_name";
    else if (sort==SORT_CITY)
      q+=" order by customer.city, customer.address";
    

    Please submit this for CodeSOD.

    Okay. Suppose you had this problem, i.e. need to search for customers where the set of search criteria can include one or more of city, account type, and balance; and where the output may be sorted by name or city plus address. How would you write it more cleanly? Is the above example easy-to-follow code? I concede, no. Is there a better alternative that would be more readable and more maintainable? I can't think of one. If you have a better solution, I'd like to use it in some of my programs.

  • (cs) in reply to Jay
    Jay:
    frits:
    Jay:
    String q="select customer_id from customer"
    if (min_balance!=null || max_balance!=null)
      q+=" left join transaction using (customer_id)";
    q+=" where active=true";
    if (city!=null)
      q+=" and city="+esc(city);
    if (accountType!=null)
      q+=" and account_type="+esc(accountType);
    if (min_balance!=null)
      q+=" and sum(transaction.amount)>="+min_balance;
    if (max_balance!=null)
      q+=" and sum(transaction.amount)<="+max_balance;
    if (sort==SORT_NAME)
      q+=" order by customer.last_name";
    else if (sort==SORT_CITY)
      q+=" order by customer.city, customer.address";
    

    Please submit this for CodeSOD.

    Okay. Suppose you had this problem, i.e. need to search for customers where the set of search criteria can include one or more of city, account type, and balance; and where the output may be sorted by name or city plus address. How would you write it more cleanly? Is the above example easy-to-follow code? I concede, no. Is there a better alternative that would be more readable and more maintainable? I can't think of one. If you have a better solution, I'd like to use it in some of my programs.

    What do you think this is, rentacoder.com?

  • (cs) in reply to galgorah
    galgorah:
    whatever:
    Provide a link, and I'll wager they'll quickly change their minds.
    Alex won't, I'm sure, even if the submitter gave him the url. Which is a good thing :)

    The submitter probably would have had better luck providing a link to his customer. "It will break if they do '1 = 1'" looks picky to a non-tech savvy user. "It still isn't secure. CLICK HERE TO BREAK IT" looks scary to a non-tech savvy person. Especially if they actually click the link.

    Of course, all that would accomplish is getting the one particular case fixed, not "1 = 1"

  • Quirkafleeg (unregistered) in reply to ContraCorners
    ContraCorners:
    Tharg:
    Put up or shut up.
    Dude, is this your first time on the internet? No one's going to shut up.
    Or put up, for that matter.
  • jammer5 (unregistered)

    If you squint the right way, you cab see Freddy.

  • Anonymous (unregistered) in reply to Quirkafleeg
    Quirkafleeg:
    ContraCorners:
    Tharg:
    Put up or shut up.
    Dude, is this your first time on the internet? No one's going to shut up.
    Or put up, for that matter.
    Given that he's a DBA he's probably just glad that people are talking to him for once.
  • AdT (unregistered) in reply to mike
    mike:
    OMG, please don't store html in my db. Html is for the presentation layer.

    Duh, that's why it's called PL/SQL (presentation layer SQL). I thought you guys knew that…

  • Tharg (unregistered)

    Guys,

    tee hee, nice response. I guess it does come across an naieve, but as I have noted with protagonists far and wide, a call to prove the BS they're peddling usually results in a plethora of zero responses - just like here.

    I have to sigh and say Q.E.D. and then get on with life. Anyhow, someone talked to me just last year, don't you know?

    I'm just off to find my sandals, shorts, beard trimmer, and circular gold-rimmed glasses. I reckon they're somewhere in the dungeon where I work....

  • (cs) in reply to Tharg
    Tharg:
    Alternatively, you could go completely bonkers and use a stored procedure. That way the DB itself would be invulnerable to sql injection attacks in any and all forms, for the simple reason that there would be no SQL to inject.

    Anything else is posturing (and drivel).

    This is drivel. Stored procedures do not protect against SQL injection. They simply change how to exploit the system.

    Just inject "SELECT * FROM sys.objects" first, then inject a procedure call to do anything you want to do. Since every is done in a procedure, it is gauranteed that there will be a procedure to do anything that you want to do.

Leave a comment on “Injection Proof'd”

Log In or post as a guest

Replying to comment #:

« Return to Article