CS3/CS4 protecting against SQL Injection

Hi:
I was wondering if the newer versions of Dreamweaver like CS3/CS4 do a good enough job to protect against SQL Injection when using the built in Insert/Update/Delete behaviors or should I use Commands with Stored Procedures (MS SQL)?
Thanks!
Mitch

David , Günter - many thanks for your help !
In my ignorance I appear to have been misled by my website host who, in response to a related problem, informed me as follows:
"your website's scripting does appear to be highly vulnerable to SQL injection attack, this can be easily seen via the following example:
/s-sub_detail.php?cat_id=TEST
As you can see, arbitrary data entered as the cat_id variable of the shopping cart script is being passed unchecked to the SQL server, which is then returning a notice relevant to the data passed (in the above example case this is an "unknown column" error) - This effectively demonstrates that your shopping cart script performs no validation on variables used within the script and passes them directly to the SQL server, which means arbitrary commands can potentially be added as variable data for the SQL server to execute.
In order to correct this all variables and any other posted data used by the shopping cart script must be fully validated by the script itself before being passed to the SQL server so that SQL commands cannot be executed by simply manually entering these as a script variable".
Thanks to David I understand the issue with the need for data validation but the response above appears to indicate that they believe there is more to it.
David and Günter - I would welcome your response to the above and perhaps recommendations for SQL injection vulnerability testing.
Kind regards
J

Similar Messages

SAP ABAP Secure Coding. Protection against SQL Injection

Dear community,
I've detected recently a problem with dynamic SQL queries. It seems to be security relevant. I'll be much appreciated, when you participate at my online survey to this topic at: http://de.surveymonkey.com/s/VC9CBVM It takes less than 1 min time. It is very important to understand, whether it is necessary to protect the coding against SQL injection? Or you can say from your expirience, that it isn't?
Thanks a lot!
Moderator Message: if you need a poll support from SCN, then there is an area http://scn.sap.com/poll-post!input.jspa?container=2015&containerType=14 to create such. Please use it and avoid external links.
Message was edited by: Kesavadas Thekkillath

Dear community,
I've detected recently a problem with dynamic SQL queries. It seems to be security relevant. I'll be much appreciated, when you participate at my online survey to this topic at: http://de.surveymonkey.com/s/VC9CBVM It takes less than 1 min time. It is very important to understand, whether it is necessary to protect the coding against SQL injection? Or you can say from your expirience, that it isn't?
Thanks a lot!
Moderator Message: if you need a poll support from SCN, then there is an area http://scn.sap.com/poll-post!input.jspa?container=2015&containerType=14 to create such. Please use it and avoid external links.
Message was edited by: Kesavadas Thekkillath

Lightswitch Security, Protection against SQL Injection attacks etc.

Hi all,
I have been hunting around for some kind of documentation that explains how Lightwitch handles typical web application vunerabilities such as SQL injection attacks.
In the case of injection attacks it is my understanding the generated code will submit data to the database via names parameters to protect against such things but it would be good to have some official account of how Lightswitch handles relevant OWASP
issues to help provide assurance to businesses that by relying on a framework such as Lightswitch does not introduce security risks.
Is anyone aware of such documentation? I found this but it barely scratches the surface:
http://msdn.microsoft.com/en-us/library/gg481776.aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1
There is this which describes best practices but nothing to say that these practices are adopte within Lightswitch
http://msdn.microsoft.com/en-us/library/gg481776.aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1
Thanks for any help, I am amazed that it is so difficult to find?

LS is a tool built in top of other technologies including Entity Framework.
Here is a security doc about EF.
http://msdn.microsoft.com/en-us/library/vstudio/cc716760(v=vs.100).aspx
LS uses Linq to Entities and therefore is not susceptible to SQL injection.
HTH,
Josh
PS... the only vulnerability that I'm aware of is when a desktop app is deployed as 2-tier instead of 3-tier. In that case, the web.config which contains connection strings is on the client machine, which is a risk. Here is a discussion related
to db security & 2 vs 3-tier.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/93e035e0-0d2e-4405-a717-5b3207b3ccac/can-sql-server-application-roles-be-used-in-conjunction-with-lightswitch?forum=lightswitch

CFInsert/Update: protection against SQL injection?

Hello,
I'm trying to find out if the use of CFInsert or CFUpdate
offers any protection against a SQL Injection attack. We are on a
project that uses many CFInserts and Updates, and lack the time to
rewrite new queries using CFQueryParam. Will a CFInsert or Update
handle the situation?

Validate every field before you get to the cfinsert/cfupdate
tag, something you should have been doing anyway.

Spry to block script characters to protect against sql injection

I am new so please be patient and I hope I am in the right forum. I would like to set up a Spry widget that I could apply to forms in my site for text area. This would block any code like <> * and only allow a-zA-Z and 0-9. I would like to be able to add this widget to Dreamweaver so that I can call it up any time I add a text area. I am hoping to use this to block SQL injection on my sites.
Can this be done by a rookie?
Thanks!

Sure it can be done, but there are some flaws in your idea. Having a client side validation is always good for the user experiance, but these validations are only executed client side, and when the user has javascript enabled. So when you users disable javascript they would probably still be able to create SQL injections.
So I wouldn't really use client side validations for you issue, but search for a server side alternative. Most server side languages already provide you with utilities you can use to prevent the most common SQL injection types. So you might want to digg in to that first.

Protect From SQL Injection in ASP

Hi, can anyone tell me different ways of how to protect from
SQL Injection in ASP via DW or other means? I thought there was
something in DW that would automatically do that.
This would be a simple text form field which will allow
visitors to search for a product from a db.
thanks

Google "SQL Injection ASP".
Murray --- ICQ 71997575
Adobe Community Expert
(If you *MUST* email me, don't LAUGH when you do so!)
==================
http://www.projectseven.com/go
- DW FAQs, Tutorials & Resources
http://www.dwfaq.com - DW FAQs,
Tutorials & Resources
==================
"ed19" <[email protected]> wrote in message
news:g9s98d$6nn$[email protected]..
> Hi, can anyone tell me different ways of how to protect
from SQL Injection
> in
> ASP via DW or other means? I thought there was something
in DW that would
> automatically do that.
>
> This would be a simple text form field which will allow
visitors to search
> for
> a product from a db.
>
> thanks
>

Preventing/securing against sql injection attacks

What's the best way to go about trying to secure/prevent from mysql injection attacks.
I guess this is not so good?
$JobTitle = $_POST['JobTitle'];
$sql = 'SELECT * FROM jobs WHERE JobTitle = "'.$JobTitle.'"';
So I'm currently using the mysqli real_escape_string:
$JobTitle = $_POST['JobTitle'];
$JobTitle = $conn->real_escape_string($JobTitle);
$sql = 'SELECT * FROM jobs WHERE JobTitle = "'.$JobTitle.'"';
or I could use:
$sql = 'SELECT * FROM jobs WHERE JobTitle = "$_POST['JobTitle'];"';
but I don't know about the above having not used it at all.
or I could use prepared statements which I dont particularly want to do because they are so long-winded especially when you have about 20 or so rows of data to insert/update into a database table
???????????????????? (ssssssssssssssss) I mean who the **** can keep track of that ****
Is there anything bad about using the below (no user input i.e., $_POST or $_GET)
$date = date('Y-m-d');
$sql = 'SELECT * FROM jobs WHERE jobDate < "'.$date.'"';
Just trying to get a handle on reasonable practices to use, when and where.
Any thoughts
Cheers
Os

Hi Ken,
Thanks for that. It seems as though this area is a bit of a grey one. I've searched just about everywhere and can't find any kind of difinitive answer.
I'm specifically exploring sqli as that is the way ahead now that sql is being dropped from future php releases.
I'm using prepared statements to insert and update the database and boy are they a pita to work with. My eyes can't cope with it....simply ridiculous to have to keep track of the binding method:
??????????????????????? and sssssssssssssssssss
Was looking for something simpler when selecting results to display on a page. Think for now I'll just go with the real_escape_string method and hope it provides some form of security.
$foo = $_POST['foo'];
$foo = $conn->real_escape_string($foo);
I'll just assume there is no risk if a user can't input any data i.e,
$variable = "foo";
SELECT * from table Where id = "'.$variable.'"

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 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 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.;)

Sql injection avoiding

If someone enters sql commands into a text element for address or name, how does cfqueryparam help protect against sql injection ?
Would a regular expression or something checking for dangerous key words help at least as much ?

It protects by explicitly telling the database "the string I am about to send you is just a string, to be substituted into a query as a variable". That way the database doesn't try and execute part of that string as SQL as can happen without.
There is also the cfsqltype attribute - if you're sending a number, but with the value "DROP TABLE users" then CF can stop it before it even gets to the database, so basically makes your variables type-safe to a degree.
If you want a watertight solution, go for both. Regex so you can nicely tell the user they've inputted something invalid, and queryparam as a last resort to stop someone screwing over your data.

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)

Dreamweaver CS3 and sql injection....

Any news if Dreamweaver CS3 will have the same "problems"
brought on by the
8.0.2 update to Dreamweaver 8?
Thanks!

Excellent...glad to hear it and I look forward to getting
CS3. I held off
on 8 because of the so called problems.
"Murray *ACE*" <[email protected]> wrote
in message
news:[email protected]...
> Yes, that's what I do. Honestly, I've not seen any
problems there.
>
> --
> Murray --- ICQ 71997575
> Adobe Community Expert
> (If you *MUST* email me, don't LAUGH when you do so!)
> ==================
>
http://www.dreamweavermx-templates.com
- Template Triage!
>
http://www.projectseven.com/go
- DW FAQs, Tutorials & Resources
>
http://www.dwfaq.com - DW FAQs,
Tutorials & Resources
>
http://www.macromedia.com/support/search/
- Macromedia (MM) Technotes
> ==================
>
>
> "Pizza Good" <[email protected]> wrote in
message
> news:[email protected]...
>>I think it comes up more when you have a form and
pass the values to a
>>recordset which uses those values to query and filter
a recordset.
>>
>>
>> "Murray *ACE*"
<[email protected]> wrote in message
>> news:[email protected]...
>>>I am processing form input, which I believe is
where SQL injection comes
>>>in.
>>>
>>> --
>>> Murray --- ICQ 71997575
>>> Adobe Community Expert
>>> (If you *MUST* email me, don't LAUGH when you do
so!)
>>> ==================
>>>
http://www.dreamweavermx-templates.com
- Template Triage!
>>>
http://www.projectseven.com/go
- DW FAQs, Tutorials & Resources
>>>
http://www.dwfaq.com - DW FAQs,
Tutorials & Resources
>>>
http://www.macromedia.com/support/search/
- Macromedia (MM) Technotes
>>> ==================
>>>
>>>
>>> "Pizza Good" <[email protected]> wrote
in message
>>> news:[email protected]...
>>>> That's good, or perhaps you are not building
the types of sites that
>>>> may encounter the so called problems?
>>>>
>>>>
>>>> "Murray *ACE*"
<[email protected]> wrote in message
>>>> news:[email protected]...
>>>>>I have to say that I've used 8.0.2 with
such things quite a bit and not
>>>>>encountered *any* of the posted problems.
>>>>>
>>>>> --
>>>>> Murray --- ICQ 71997575
>>>>> Adobe Community Expert
>>>>> (If you *MUST* email me, don't LAUGH
when you do so!)
>>>>> ==================
>>>>>
http://www.dreamweavermx-templates.com
- Template Triage!
>>>>>
http://www.projectseven.com/go
- DW FAQs, Tutorials & Resources
>>>>>
http://www.dwfaq.com - DW FAQs,
Tutorials & Resources
>>>>>
http://www.macromedia.com/support/search/
- Macromedia (MM) Technotes
>>>>> ==================
>>>>>
>>>>>
>>>>> "Paul Whitham AdobeCommunityExpert"
<[email protected]> wrote in
>>>>> message
news:[email protected]...
>>>>>> Using stored procedures is a good
safe guard against SQL injection
>>>>>> because you have to define your
parameter types, in much the same way
>>>>>> that the parameters in the 8.0.2
worked.
>>>>>>
>>>>>> Yes it did break a number of
extensions because the underlying code
>>>>>> was completely rewritten but it is
my understanding that most of
>>>>>> these were subsequently patched to
work with it.
>>>>>>
>>>>>> --
>>>>>> Paul Whitham
>>>>>> Certified Dreamweaver MX2004
Professional
>>>>>> Adobe Community Expert - Dreamweaver
>>>>>>
>>>>>> Valleybiz Internet Design
>>>>>> www.valleybiz.net
>>>>>>
>>>>>> "Pizza Good"
<[email protected]> wrote in message
>>>>>>
news:[email protected]...
>>>>>>>I think what he is referring to
is the sql injection "prevention"
>>>>>>>code that was introduced in the
8.0.2 update. I read a bunch of
>>>>>>>issues related to the way
recordsets were coded and that a page that
>>>>>>>was coded lets say in ASP using
8.0.1 that had used QueryString
>>>>>>>values that were passed into the
recodset for filtering/searching no
>>>>>>>longer worked. I also read that
8.0.2 "broke" a lot of extensions
>>>>>>>because of the fix.
>>>>>>>
>>>>>>> I am still using MX2004, but I'm
curious if the supposed problems
>>>>>>> that came up with 8.0.2 could be
totally avoided if a programmer
>>>>>>> used Stored Procedures?
>>>>>>>
>>>>>>> Hopefully that makes sense.
>>>>>>>
>>>>>>>
>>>>>>> "Paul Whitham
AdobeCommunityExpert" <[email protected]> wrote in
>>>>>>> message
news:[email protected]...
>>>>>>>> Most of the change that was
made to the recordset in 8.0.2 was to
>>>>>>>> eliminate SQL injections.
What specifically are you refering to as
>>>>>>>> an issue now
>>>>>>>>
>>>>>>>> --
>>>>>>>> Paul Whitham
>>>>>>>> Certified Dreamweaver MX2004
Professional
>>>>>>>> Adobe Community Expert -
Dreamweaver
>>>>>>>>
>>>>>>>> Valleybiz Internet Design
>>>>>>>> www.valleybiz.net
>>>>>>>>
>>>>>>>> "Brendon"
<[email protected]> wrote in message
>>>>>>>>
news:[email protected]...
>>>>>>>>> Those that are beta
testing it would know - if they were doing
>>>>>>>>> serverside/sql related.
It wouldn't be speculation at all - in
>>>>>>>>> fact it would be pretty
straight forward to test.
>>>>>>>>> I'd be very surprised if
they havn't fixed the issue - in fact I
>>>>>>>>> thought it was fixed in
the 8.0.2 update, but I could be wrong.
>>>>>>>>>
>>>>>>>>> Brendon
>>>>>>>>>
>>>>>>>>> "Deaf Web Designer"
<[email protected]> wrote in
>>>>>>>>> message
news:[email protected]...
>>>>>>>>>> DW CS3 is not here
as yet.
>>>>>>>>>>
>>>>>>>>>> Only time will tell
once you have DW CS3 installed on your
>>>>>>>>>> platform and find
>>>>>>>>>> out if that is the
case.
>>>>>>>>>>
>>>>>>>>>> At this point, it is
all speculation without knowing the fact of
>>>>>>>>>> the problem.
>>>>>>>>>> Try to be a bit more
patient until official release of product
>>>>>>>>>> sometime this
>>>>>>>>>> spring.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

SQL Injection concerns

I have been studying sql injection attacks and the
mysql_real_escape function.
I read the adobe technote about sql injection and it noted
that Dreamweaver 8.0 incorporates anti-sql injection code to
prevent attacks and it specifically refers to Add, Delete, and
Update; Filtered Recordsets, and Login User server behaviors. Can
anyone please confirm this to put my mind at ease?
The Search form and results page uses a filtered recordset,
so can I presume that it is guarded from attack?
Can you tell me of any areas that I need to add anti-sql
injection code myself?
Thank you so much for your help!

EviePhillips wrote:
> The code on this second page (the one where the form
posts to) ECHOs the form
> variables. Do I need to enter the
mysql_real_escape_string around each of the
> ECHOed posted form variables?
No, mysql_real_escape_string() is used only when inserting
user input
values into a database. You cannot use it without a database
connection.
However, you should pass the values to htmlentitities()
before
displaying them in your page. You can do this by accessing
the Format
menu in the Dynamic Text dialog box. After using the Bindings
panel to
insert the value, switch to the Server Behaviors panel, and
double-click
the Dynamic Text entry to open the dialog box.
> I am then going to use the ADD Record server behavior to
add the data to my
> database from this page, which based on your counsel is
fully protected from
> sql injection.
>
> You are very kind for sharing your knowledge!
> EP
>
David Powers, Adobe Community Expert
Author, "The Essential Guide to Dreamweaver CS4",
"PHP Solutions" & "PHP Object-Oriented Solutions"
http://foundationphp.com/

SQL Injection Help

Hi there I have created a site and I am told that I should
protect my self against SQL Injection attacks. I have created the
site using Dreamweaver and dont know if it creates code with this
in mind. Can anyone suggest what to do?
Mally

Hi there I have created a site and I am told that I should
protect my self against SQL Injection attacks. I have created the
site using Dreamweaver and dont know if it creates code with this
in mind. Can anyone suggest what to do?
Mally

CS3/CS4 protecting against SQL Injection

Similar Messages

Maybe you are looking for