Sql injection question

This is about a stackoverflow question.
http://stackoverflow.com/questions/1267025/how-to-calculate-value-of-string-in-oracle
I (aka tuinstoel) have provided an answer how to protect against sql injection but I'm not completely sure I'm offering good advice.
My answer on stackoverflow:
http://stackoverflow.com/questions/1267025/how-to-calculate-value-of-string-in-oracle/1268243#1268243
Can anyone say whether my method is sound or provide one or more counterexamples?

how about parsing the dynamic SQL and getting an execution plan for it first - and then check that execution plan against a kind of predefined templateIsn't a nice xml output not much easier to parse?
SQL>  declare
     cl clob;
begin
     dbms_lob.createtemporary (
          cl,
          true
     sys.utl_xml.parsequery (
          user,
          'select e.deptno from emp e where deptno = 10',
          cl
     dbms_output.put_line (cl);
     dbms_lob.freetemporary (cl);
end;
<QUERY>
  <SELECT>
    <SELECT_LIST>
      <SELECT_LIST_ITEM>
        <COLUMN_REF>
          <SCHEMA>MICHAEL</SCHEMA>
          <TABLE>EMP</TABLE>
          <TABLE_ALIAS>E</TABLE_ALIAS>
          <COLUMN_ALIAS>DEPTNO</COLUMN_ALIAS>
          <COLUMN>DEPTNO</COLUMN>
        </COLUMN_REF>
        <COLUMN_ALIAS>DEPTNO</COLUMN_ALIAS>
      </SELECT_LIST_ITEM>
    </SELECT_LIST>
  </SELECT>
  <FROM>
    <FROM_ITEM>
      <SCHEMA>MICHAEL</SCHEMA>
      <TABLE>EMP</TABLE>
      <TABLE_ALIAS>E</TABLE_ALIAS>
    </FROM_ITEM>
  </FROM>
  <WHERE>
    <EQ>
      <COLUMN_REF>
        <SCHEMA>MICHAEL</SCHEMA>
        <TABLE>EMP</TABLE>
        <COLUMN>DEPTNO</COLUMN>
      </COLUMN_REF>
      <VALUE>10</VALUE>
    </EQ>
  </WHERE>
</QUERY>
PL/SQL procedure successfully completed.;)

Similar Messages

  • SQL injection and SQLFury

    We have recently had an SQL injection attack on our site.  The web form in question was calling a second cfm with a post command.  The second cfm did the actually db insert. After extensive research and revamping of the web form I believed that I had shut it down rather convincingly. I did the following to secure the form:
    - implemented the cfqueryparam tag on all applicable fields being entered in the form
    - introduced a hidden, random numeric variable for verification before completing the insert; it tests for its existence and if it is numeric
    - consolidated the two cfms into one page so the entry and insert are done in one cfm (to eliminate injection going directly thru insert cfm)
    However, I am still getting intermittent injection errors into my MS SQL table.  I don't believe it is getting in through the revised web form and am at a loss as to how it's getting through.
    I am now at the point that I am looking for a utility that will scan through my site or specific pages to identify SQL injection vulnerabilties.  I found something called SQLFury and downloaded it; however, there is literally no documentation with it and I have no idea how to run it.  I've researched the web and found no assistance on how to use this utility.  Is anyone familiar with this utility or does anyone know of any other utility that will assist with validating ColdFusion methods?
    Any assistance would be very much appreciated.

    Ian:
    Thanks for the information.  The utility is helpful and confirmed for me that my page was secure from SQL injection.  The additional insight you provided has lead me to discover that my issue was not an SQL injection, but a Cross Scripting attack.  A web vulnerability utility from Acunetix helped me determine that.
    Thanks again,
    ...Wes

  • SQL injection on login system by Adobe?

    Hello everybody!
    I recently bought a wonderful book "Adobe Dreamweaver CS5 with PHP - Training from the source" by Daivid Powers.
    In the book is described how you can create a login system.
    What I would like to ask is: Have the dreamweaver server behaviors any kind of protection against SQL injection?
    Unfortunately I do not know PHP in order to recognize the code generated by server behaviors and be able to answer this question by myself..
    I just want to know how safe is to publish a website based on the dreamweaver server behaviors..
    Thank you in advance!

    Any form values and inbound URL parameters will be sanitized (via the function GetSQLValueString) based on several criteria:
    a) generally applied sanitizing functions: stripslashes, mysql_real_escape_string
    b) in case of a numeric value (integer, double) the function GetSQLValueString will additionally apply the PHP function intval respectively doubleval

  • Sql injection character fields

    Is it true that with MSSQL in the background, character fields can't be used for sql injection?
    A)   One source says that in MSSQL single quotes are escaped into double quotes.
    B)   Another source says that " SQL injection (within ColdFusion apps) is really only an issue with non textual fields. If a text value is tampered with you'll end up with tampered text, but that text will all be part of the core string (within quotes) passed as a value, and will therefore not be executed as separate statements. Numbers, on the other hand, are not enclosed within quotes, and so extraneous text can be tampered "
    Questions about A):   How does escaping 's with "s help, by making string literals in MSSQL not valid?
                                    How could A) above be true when names like O'Mally are being stored with a single quote ?
    Questions about B)    Does it mean code like DELETE * FROM atable would just be stored as a string and not execute ?
                                    If so, is that accurate ?

    To actually answer your question's.
    A) A single quote in SQL is a comment.  To store a single quote as DATA one has to escape it by doubling it.  So to store O'Mally it would be passed as o''Mally.
    The simple SQL injection attack is to end a number value with a random value, that is followed with a ; to end the SQL statment and then another statement can be run, this is then followed by a single quote to comment out any other SQL in the original statement.  ColdFusion automatically escapes single quotes in text fields in most situations, so this is harder to do with text fields, but not impossible.

  • Preventing SQL injection - can't use cfqueryparam in this case

    Hello. I have a form with a checkbox next to each row.  If the user checks some boxes, then clicks the "Delete" button, I want to execute the following query, but I want to protect it from sql injection attacks:
        <cfquery datasource="#application.mainDS#">
            delete userMessages
            where messageID in (#form.messageID#)
        </cfquery>
    As written above, it works fine.  But if I try to protect this code with <cfqueryparam value="#form.messageID#" cfsqltype="cf_sql_varchar">, I get this error: "Conversion failed when converting the varchar value '7,21' to data type int" (7 and 21 are the messageID's to be deleted).  Obviously the comma prevents conversion to an integer.
    If I use cfsqltype="cf_sql_integer", then the string gets converted to a single integer (in this case 40015, which is nonsense).
    I tried passing form.messageID to a stored procedure, but I seemed to have the same problem there.  I could run the query in a loop where I just delete one row at a time, but I'd like to run just one query if I can do it safely.  Any ideas?
    Thanks.
    PK

    I agree that you should not do an SQL "DELETE" from a web page.  Instead, use "soft deletes," where you contrive for there to be a deleted_flag (boolean), and maybe deleted_by (varchar) and deleted_timestamp.  Then create an SQL "VIEW" which automagically omits the "deleted" records.
    It is also a very good idea to refer to the records using a nonsensical, made-up "moniker" instead of actual record-IDs.  You see, "if I am a nasty person and I know that there is a record #123456, then I'll bet I know the record-IDs of 123,455 other records, too."  But if you refer to the record as "QZB0E9S" and the next record-id in the list is "4Q_9RJPEM2" then it won't take me long to realize that I can't get too far, not even by brute-force.  (And if I see that the record-IDs seem to have verification tags, like "QZB0E9S:4E396", then I know that I am really scroo'd in my hacking-attempt because even if I did somehow million-monkeys my way into a valid record-ID, I've got no earthly idea how to come up with the tag.
    It pays to code defensively, like this.  And it doesn't really take more time.  Without question, always use <cfqueryparam> !!

  • Is cfinsert and cfupdate open to SQL Injection

    Hello All,
    I'm looking for a real answer on if cfinsert and cfupdate are vulnerability to SQL Injection. The closest thing I can find from Adobe is Ben Forta's Personal recommendation. I was hoping to find some form of "official note" in the live docs to indicate there is a SQL Injection issue with cfinsert  - cfupdate. (Other than someone's post  to Ben's Blog)
    http://www.forta.com/blog/index.cfm/2006/10/3/Use-CFINSERT-And-CFUPDATE
    In this forum I have seen this question asked, and the only answer is "You should validate your inputs". Yes, you should, but that does not answer the question of if cfinsert and cfupdate is vulnerability to SQL Injection.
    I have found this blog entry that if I interpret is correctly from his findings cfinsert and cfupdate where only vulnerability to SQL Injection IF you did not give  cfinsert  - cfupdate the list of fields to take action on. -Is this true?
    http://blog.securityps.com/2009/05/demystifying-cfinsert-sql-injection.html
    Also, on a closely related note, is cfinsert  - cfupdate on ColdFusion 9 also vulnerable? If so, why? Seems like a BUG that could be easly addressed by the CF server team.
    Thank you,

    I do agree with you here.  But to be devil's advocate for a second: the same could be said of <cfquery>.  One has to take additional measures to ensure the same vulnerabilities are mitigated with that.
    I'm not sure that it's really news that these two tags are not the most well-thought-out features in the CF arsenal, and if you listen to most opinions in the community regarding <cfinsert> and <cfupdate>, it's: "don't use them".
    They're great for quick and dirty insert/update processes in internal or test code, but I'd never use them in production.
    It also remains a fact that any external input (form fields, URL param) must be validated as being kosher and within expected margins before they're used in any way.  That is just common sense.  And if one neglects to do that: one brings any eventuality onto one's self.  The problem here really is with people not doing their "due diligence" on externally sourced data, not specififcally with <cfinsert>, <cfupdate> or <cfquery>.
    Still: I think Adobe should make it more clear in the docs that additional measures need to be take to make them safe.  And by that time... one might as well use a <cfquery> to do the SQL.
    Adam

  • Best way of avoiding SQL injection?

    Hey,
    I was wondering what you guys would recommend to prevent SQL injections. Now, I know that you can use the PreparedStatement and setString for cases like this:
    String userName  = request.getParameter("username");
    String sqlString = "SELECT * FROM UserTable WHERE USERNAME='" + userName ;but what can you do when you have cases like these:
    String userdef_table  = request.getParameter("userdef_table");
    String userName  = request.getParameter("username");
    String sqlString = "SELECT * FROM "+ userdef_table +" WHERE USERNAME='" + userName ;Note: userdef_table can be created by the admin so I wont know what tables are around.
    thanks,
    domet

    For Your First Question
    1) using PreparedStatement is the best way, but yes you will have to catch the Table Not Found Exception very well in case the passed table deso not exist... Thats The Only Logical Answer For your Query
    For Your Second Query
    1) Create a String variable which will have the required reflex string ie the text you would liketo have after LIKE keyword and then pass the variable to the prepare statement
    this
    ?% will not work for its wrong SQL query
    String likeThis = "%Bill%"; <or what ever>
    the Query part will be like this ".......like ?"
    setString(....,likeThis);
    Hope This Works
    Bhaskar

  • SQL Injection, replace single quote with two single quotes?

    Is replacing a single quote with two single quotes adequate
    for eliminating
    SQL injection attacks? This article (
    http://www.devguru.com/features/kb/kb100206.asp
    ) offers that advice, and it
    enabled me to allow users to search name fields in the
    database that contain
    single quotes.
    I was advised to use "Paramaterized SQL" in an earlier post,
    but I can't
    understand the concept behind that method, and whether it
    applies to
    queries, writes, or both.

    Then you can use both stored procedures and prepared
    statements.
    Both provide better protection than simply replacing
    apostrophes.
    Prepared statements are simple:
    Set myCommand = Server.CreateObject("ADODB.Command")
    ...snip...
    myCommand.CommandText = "INSERT INTO Users([Name], [Email])
    VALUES (?, ?)"
    ...snip...
    myCommand.Parameters.Append
    myCommand.CreateParameter("@Name",200,1,50,Name)
    myCommand.Parameters.Append
    myCommand.CreateParameter("@Email",200,1,50,Email)
    myCommand.Execute ,,128 'the ,,128 sets execution flags that
    tell ADO not to
    look for rows to be returned. This saves the expense of
    creating a
    recordset object you don't need.
    Stored procedures are executed in a similar manner. DW can
    help you with a
    stored procedure through the "Command (Stored Procedure)"
    server behavior.
    You can see a full example of a prepared statement by looking
    at DW's
    recordset code after you've created a recordset using version
    8.02.
    "Mike Z" <[email protected]> wrote in message
    news:eo5idq$3qr$[email protected]..
    >I should have repeated this, I am using VBScript in ASP,
    with an Access DB.
    >

  • SQL Injection on CallableStatement

    I will try to post this all in one line, as the tags are not working today. I know that one should use PreparedStatement over Statement to obviate the thread of a SQL injection attack. Is CallableStatement vulnerable as well? For reference, this would be running against an Oracle RDBMS. Thanks!
    - Saish

    I guess there is no hard-and-fast rule.Well, I guess the hard and fast rule is "only use
    bound variables". If you've got a sane database
    design then that shouldn't cause you any problems.
    Dave.I agree. I was approaching the issue mainly from a security perspective in locking down a legacy system against SQL injection attacks. Using Eclipse, I was able to zero-in on usages of Statement fairly easily. But the more I looked into CallableStatement, the more I realized that I woud have to inspect each invocation manually. (Just in case someone did not bind variables or built a dynamic SQL string).
    - Saish

  • SQL Injection and variable substitutions

    Hello helpful forum, I'm trying to understand what really goes on "behind" the scenes
    with the variable substitutions in order to protect from sql injections.
    I'm using apex 3.0.0.00.20
    The trickiest component seems to be a Report of type "pl/sql returning sql", since
    multiple dynamic sql interpretations are done there.
    consider the following innocent looking disaster:
    DECLARE
    l_out VARCHAR2(2000);
    BEGIN
    l_out := 'select * from test_injection t where t.name like ''%' || :NAME || '%''';
    RETURN l_out;
    END;
    if NAME is a single quote the report will return:
    failed to parse SQL query: ORA-00911: invalid character
    which hints to the fact that NAME is not escaped, and you are in fact able to access db functions
    as in: '||lower('S')||'
    I also tried to put there a function that runs in a autonomous transaction to log its calls, and
    I see that it's called five times for each request.
    consider now the similar solution (notice the two single quotes):
    DECLARE
    l_out VARCHAR2(2000);
    BEGIN
    l_out := 'select * from test_injection t where t.name like ''%'' || :NAME || ''%''';
    RETURN l_out;
    END;
    with this second example nothing of the above is possible.
    So my theory (please confirm it or refute it) is that there is a first variable substitution done
    at the pl/sql level (and in the second case :NAME is just a string so nothing is substituted).
    Then the dynamic sql is executed and it returns the following string:
    select * from test_injection t where t.name like '%' || :NAME || '%'
    now another substitution is done (at an "APEX" level) and then query is finally executed to return
    the rows to the report.
    The tricky point seems to be that the first substitution doesn't escape the variable (hence the error
    with the single quote), while the second substitution does.
    Please let me know if this makes sense and what are the proper guidelines to avoid sql injection with
    the different kinds of reports and components (SQL, pl/sql returning sql, processes, ...)
    Thanks

    Giovanni,
    You should build report regions like this using the second method so that all bind variables (colon followed by name) appear in the resultant varchar2 variable, l_out in your example, which will then be parsed as the report query. This addresses not only the SQL injection problem but the shared-pool friendliness problem.
    Scott

  • SQL Injection -- DBA role..

    Hi all,
    I'm working as a SQL Server DBA,Now a days we are facing issue with attacks(SQL Injection),most of attacks are taken care by Firewalls but still some attacks hitting Database.
    As a DBA  How to check whether database got effected
    Please help me by providing hints and tips to analysis SQL injection.
    Thanks in advance

    There is no easy ways to detect sql injection. You should analyze activity against databases and work with developers to address it.
    Basically, you can capture sql_completed/rpc_completed events in XEvent or SQL Trace and review them. Anything, which is not parameterized, could be the subject of injection attach (it depends on Client Code and implementation). 
    As the side note, script below provides you the list of the databases together with number of cached execution plans that were used just once. SQL Injection targets non-parameterized queries. So the databases with large number of single-used plans are more
    likely to be affected. In any case, do not rely on output much - large number of single-used plans could be just the sign of bad design rather than being affected. As I said, you need to review client app code just to be sure.
    select
    epa.value as [DB ID],
    db_name(convert(int,epa.value)) as [DB Name],
    count(*) as [Single Use Plans]
    from
    sys.dm_exec_cached_plans p
    cross apply sys.dm_exec_plan_attributes(plan_handle) AS epa
    where
    p.usecounts = 1 and
    p.objtype in ('Adhoc','Prepared') and
    epa.attribute = 'dbid'
    group by
    epa.value
    option (recompile)
    Thank you!
    Dmitri V. Korotkevitch (MVP, MCM, MCPD)
    My blog: http://aboutsqlserver.com

  • Sql injection

    What is SQL Injection?
    SQL Injection is a way to attack the data in a database through a firewall protecting it. It is a method by which the parameters of a Web-based application are modified in order to change the SQL statements that are passed to a database to return data. For example, by adding a single quote (‘) to the parameters, it is possible to cause a second query to be executed with the first.
    An attack against a database using SQL Injection could be motivated by two primary objectives:
    1. To steal data from a database from which the data should not normally be available, or to obtain system configuration data that would allow an attack profile to be built. One example of the latter would be obtaining all of the database password hashes so that passwords can be brute-forced.
    2. To gain access to an organisation’s host computers via the machine hosting the database. This can be done using package procedures and 3GL language extensions that allow O/S access.
    There are many ways to use this technique on an Oracle system. This depends upon the language used or the API. The following are some languages, APIs and tools that can access an Oracle database and be part of a Web-based application.
    * JSP
    * ASP
    * XML, XSL and XSQL
    * Javascript
    * VB, MFC, and other ODBC-based tools and APIs
    * Portal, the older WebDB, and other Oracle Web-based applications and API’s
    * Reports, discoverer, Oracle Applications
    * 3- and 4GL-based languages such as C, OCI, Pro*C, and COBOL
    * Perl and CGI scripts that access Oracle databases
    * many more.
    Any of the above applications, tools, and products could be used as a base from which to SQL inject an Oracle database. A few simple preconditions need to be in place first though. First and foremost amongst these is that dynamic SQL must be used in the application, tool, or product, otherwise SQL Injection is not possible.
    The final important point not usually mentioned in discussions about SQL injection against any database including Oracle is that SQL injection is not just a Web-based problem. As is implied in the preceding paragraph, any application that allows a user to enter data that may eventually end up being executed as a piece of dynamic SQL can potentially be SQL injected. Of course, Web-based applications present the greatest risk, as anyone with a browser and an Internet connection can potentially access data they should not.
    While second article of this series will include a much more in-depth discussion of how to protect against SQL injection attacks, there are a couple of brief notes that should be mentioned in this introductory section. Data held in Oracle databases should be protected from employees and others who have network access to applications that maintain that data. Those employees could be malicious or may simply want to read data they are not authorized to read. Readers should keep in mind that most threats to data held within databases come from authorized users.
    Protecting against SQL Injection on Oracle-based systems is simple in principle and includes two basic stages. These are:
    1. Audit the application code and change or remove the problems that allow injection to take place. (These problems will be discussed at greater length in the second part of this series.)
    2. Enforce the principle of least privilege at the database level so that even if someone is able to SQL inject an application to steal data, they cannot see anymore data than the designer intended through any normal application interface.
    The “Protection” section, which will be included in the second part of this series, will discuss details of how to apply some of these ideas specifically to Oracle-based applications.
    [http://www.securityfocus.com/infocus/1644]
    how oracle prevent sql injections?

    mango_boy wrote:
    damorgan wrote:
    And they do so using bind variables
    http://www.morganslibrary.org/reference/bindvars.html
    and DBMS_ASSERT
    http://www.morganslibrary.org/reference/dbms_assert.html
    do you have any suggestion for mysql users??Yes. Install Oracle.

  • Sql injection update signature

    hi,
    we are currently comparing cisco ips to tippingpoint, i have a cisco ips in front and tippingpoint in the back, so we are checking if cisco ips is missing on a lot of stuff , and currently it is missing on SQL injection attacks and cross scripting, which seems to be the weak point in cisco ips, its missing a lot on sql injection signatures, i mean why a simple update/set command does not have a signature ?

    Thank you for your reply, do you know how to get in contact with the ips signature engineers at Cisco , i would like to share my comparaison with them as well as an attack that is passing all sql injection signature containing update but with u%pdate and the sql database is interpreting it as a normal update.

  • SQL Injection Blocker

    Hello all-
    I've got a server with a huge number of ColdFusion templates
    (over 10,000) which I really need to protect agains SQL Injection.
    I know that CFQUERYPARAM is the best way to do this. I'd love
    to do it that way, but with so many pages, and so many queries it
    would take weeks/months to fix the queries, then test to make sure
    I didn't screw something up.
    So, I've come up with a plan that I wanted to get some input
    on.
    Currently, I have a page on my server that is included in
    almost every page that runs. It is a simple page that I can modify
    to change the status of my systems in the event of a database
    changeover, or some other sort of failure. (The pages still run,
    but no updating is allowed, only reading)
    Okay, so on this page which is always included, I was
    thinking about analyzing the variables that come over. I was
    thinking about looking for things that looked like a SQL injection
    attack and blocking the page from running.
    I wanted to know if this would work- anyone have ideas? This
    would be great because I could protect the entire server in about
    an hour. But, I don't want to give myself a false sense of security
    if this won't really do the job.

    First, here are some simple things you can do to protect all
    pages before you follow the other advice and plans in this thread:
    In CF administrator, click on your datasources and then the
    "Advanced" button.
    There you will uncheck all but the read and stored procedure
    and (possibly) write permissions. "Drop", "Create", etc., are
    definite no-nos here.
    If you haven't already, make one data source read-permissions
    only and refactor your code to use it everywhere except for
    carefully segregated updates, inserts and deletes.
    Now, in SQL Server itself, remove all permissions from the
    users that CF uses except for data_reader and (selectively) data
    writer and exec permissions on any procedures or functions you use.
    In SQL server, setup at least two CF users. One, should have
    only the data_reader permission (plus any read-only stored
    procedures).
    Find articles, such as this one:
    http://www.sqlservercentral.com/columnists/bknight/10securingyoursqlserver.asp,
    and follow their advice, start with locking down xp_cmdshell.
    These measures require little or no CF code changes but will
    block all but the most determined and skilled hackers. You still
    need to follow Adam's advice though.
    BTW, Dan is very wrong, ALL DB's are vulnerable to SQL
    injection.
    SQL server is not even the most vulnerable anymore (Studies
    show that Oracle now has that "honor").

  • SQL injection protection help

    In trying to help another user, I was reminded of a problem I
    face
    often. Trying to create a DW recordset using an IN clause (I
    think this
    got broken in the 8.0.2 update and seems to still be broken
    in CS3).
    I create a string held in a variable like this:
    $ids = (1,5,9,23,6)
    My advanced recordset is this:
    SELECT * FROM tbl WHERE id IN varIds
    Then I set the variable parameters to type=text,
    default=(-1), and
    runtime to $ids.
    The generated SQL doesn;t work because DW puts single quotes
    around my
    variable and the SQL query becomes invalid. DW creates this:
    SELECT * FROM tbl WHERE id IN '(1,5,9,23,6)'
    It should be:
    SELECT * FROM tbl WHERE id IN (1,5,9,23,6)
    So, I edited the SWITCH block at the top of the document to
    include a
    "custom" type, which is the same as the TEXT type but without
    the single
    quotes.
    case "custom":
    $theValue = ($theValue != "") ? $theValue : "NULL";
    break;
    Then in my SQL statement, I manually changed "text" to
    "custom".
    This work fine, but does that open me up to SQL injection or
    other bad
    stuff?
    Alec Fehl, MCSE, A+, ACE, ACI
    Adobe Community Expert
    AUTHOR:
    Microsoft Office 2007 PowerPoint: Comprehensive Course
    (Labyrinth
    Publications)
    Welcome to Web Design and HTML (Labyrinth Publications)
    CO-AUTHOR:
    Microsoft Office 2007: Essentials (Labyrinth Publications)
    Computer Concepts and Vista (Labyrinth Publications)
    Mike Meyers' A+ Guide to Managing and Troubleshooting PCs
    (McGraw-Hill)
    Internet Systems and Applications (EMC Paradigm)

    It looks like you're using PHP ... to protect from SQL
    injections I always
    do this:
    $query = "SELECT * FROM tbl WHERE col='%s' AND col2 IN
    (%d,%d)"
    $query = sprintf($query,"val",34,23);
    $result = mysql_query($query);
    This method ensures that if a user puts "DELETE FROM tbl" in
    an input
    field, it will not cause any deletions, instead the words
    'DELETE FROM tbl'
    will be inserted. Check out sprintf in the PHP manual - good
    stuff!
    One thing to remember about SQL injection, the injected SQL
    has to be
    entered somehow by the end-user (usually with a form); I may
    be wrong, but
    this sql statement looks like it is contained entirely within
    your scripts
    (i.e. it isn't getting getting a user-generated value to
    build any part of
    the SQL statement). Again, I'm guessing here - but it looks
    that way.
    Alex
    "Alec Fehl" <[email protected]> wrote in message
    news:[email protected]...
    > In trying to help another user, I was reminded of a
    problem I face often.
    > Trying to create a DW recordset using an IN clause (I
    think this got
    > broken in the 8.0.2 update and seems to still be broken
    in CS3).
    >
    > I create a string held in a variable like this:
    > $ids = (1,5,9,23,6)
    >
    > My advanced recordset is this:
    >
    > SELECT * FROM tbl WHERE id IN varIds
    >
    > Then I set the variable parameters to type=text,
    default=(-1), and runtime
    > to $ids.
    >
    > The generated SQL doesn;t work because DW puts single
    quotes around my
    > variable and the SQL query becomes invalid. DW creates
    this:
    >
    > SELECT * FROM tbl WHERE id IN '(1,5,9,23,6)'
    >
    > It should be:
    >
    > SELECT * FROM tbl WHERE id IN (1,5,9,23,6)
    >
    > So, I edited the SWITCH block at the top of the document
    to include a
    > "custom" type, which is the same as the TEXT type but
    without the single
    > quotes.
    > case "custom":
    > $theValue = ($theValue != "") ? $theValue : "NULL";
    > break;
    > Then in my SQL statement, I manually changed "text" to
    "custom".
    >
    > This work fine, but does that open me up to SQL
    injection or other bad
    > stuff?
    >
    >
    > --
    > Alec Fehl, MCSE, A+, ACE, ACI
    > Adobe Community Expert
    >
    > AUTHOR:
    > Microsoft Office 2007 PowerPoint: Comprehensive Course
    (Labyrinth
    > Publications)
    > Welcome to Web Design and HTML (Labyrinth Publications)
    >
    > CO-AUTHOR:
    > Microsoft Office 2007: Essentials (Labyrinth
    Publications)
    > Computer Concepts and Vista (Labyrinth Publications)
    > Mike Meyers' A+ Guide to Managing and Troubleshooting
    PCs (McGraw-Hill)
    > Internet Systems and Applications (EMC Paradigm)

Maybe you are looking for