Does variable and CFQueryParam checking also apply to Access databases? Is it needed
when using MS Access 2000 as a backend?
~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
Does val() and CfQueryParam checking also apply if you're using Access as your backend
database?
~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
[EMAIL PROTECTED] wrote:
Does variable and CFQueryParam checking also apply to Access databases? Is it
needed when using MS Access 2000 as a backend?
Yes.
I am not sure whether you get the performance improvements with Access,
but cfqueryparam is still a protection against SQL Injection
A long time ago, I made a really stupid mistake that results in deletion
of all data from a table...
A tip I picked up from somewhere - it might even have been this list - is to not ever
actually delete records using code. Instead, I have a dtDeleted field, which is set to
the current date
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kay Smoljak wrote:
| A long time ago, I made a really stupid mistake that results in
| deletion of all data from a table...
|
|
| A tip I picked up from somewhere - it might even have been this list
| - is to not ever actually delete records using
| Kay Smoljak wrote:
| A tip I picked up from somewhere - it might even have been this list
| - is to not ever actually delete records using code. Instead, I have
| a dtDeleted field, which is set to the current date when I want to
| delete the record. When doing selects, I add WHERE dtDeleted IS
Zac Spitzer wrote:
Kay Smoljak wrote:
|
| A tip I picked up from somewhere - it might even have been this list
| - is to not ever actually delete records using code. Instead, I have
| a dtDeleted field, which is set to the current date when I want to
| delete the record. When doing selects,
I add a IsDeleted flag to perform soft deletes and use DateChanged field to
record the last date that the record was updated.
-Original Message-
From: Kay Smoljak [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 05, 2003 7:47 AM
To: CF-Talk
Subject: all records deleted from table
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jochem van Dieten wrote:
| Zac Spitzer wrote:
|
|Kay Smoljak wrote:
||
|| A tip I picked up from somewhere - it might even have been this list
|| - is to not ever actually delete records using code. Instead, I have
|| a dtDeleted field, which is set
Zac Spitzer wrote:
Jochem van Dieten wrote:
|
| That is just a limitation of your specific dbms. Others can use much
| fancier indexing schemes. (If your database supports it, look into
| partial indexes for this type of problem.)
interesting i think oracle (at least in the 8i world)
-Original Message-
From: Jochem van Dieten [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 05, 2003 10:32 AM
To: CF-Talk
Subject: Re: all records deleted from table
PostgreSQL has them. I would expect DB2 to have them as wll,
since IBM
funded some research
To: CF-Talk
[EMAIL PROTECTED]
cc:
Subject: all records deleted
Jim Davis wrote:
-Original Message-
From: Jochem van Dieten [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 05, 2003 10:32 AM
To: CF-Talk
Subject: Re: all records deleted from table
http://simon.cs.cornell.edu/home/praveen/papers/partindex.de95.ps.Z
Typical indexing would have
I also now put a confirmation page between the link to delete and the
actual delete page.. this confirmation page has a form where you have to
actually type the word DELETE into a form field and hit the submit button
to do the deletion, so a web crawler can't trigger it.
At 09:30 AM 2/5/2003,
BTW, materialized views can be implemented in any
database that can use triggers. I don't really
understand why many database vendors insist on
naming them views when they are just extra tables.
Because putting Now, more tables! into the sales material just doesn't
have the same effect as
Dave Watts wrote:
BTW, materialized views can be implemented in any
database that can use triggers. I don't really
understand why many database vendors insist on
naming them views when they are just extra tables.
Because putting Now, more tables! into the sales material just doesn't
have
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 05, 2003 12:50 PM
To: CF-Talk
Subject: RE: all records deleted from table
BTW, materialized views can be implemented in any
database that can use triggers. I don't really
understand
Jochem van Dieten wrote:
PostgreSQL has them. I would expect DB2 to have them as wll, since IBM
funded some research into this:
snip
Interesting... I mostly use SQL Server, sometimes Interbase (not with CF yet though) -
I don't suppose you have any idea whether Interbase/Firebird supports
Kay Smoljak wrote:
Interesting... I mostly use SQL Server, sometimes Interbase (not with CF yet though)
- I don't suppose you have any idea whether Interbase/Firebird supports partial
indexes?
I never heard it does.
Although, the other idea posted in this thread (using a flag and a
Hi all,
I ran into a big problem this morning when I found out that all the data
from my table were somehow deleted. I wanted to make sure that it wasn't my
code so I did an extended search for delete from tablename and delete
tablename in my code and I'm positive that there is only one instance
?
-Original Message-
From: Tim Do [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 5 February 2003 9:31 AM
To: CF-Talk
Subject: all records deleted from table
Hi all,
I ran into a big problem this morning when I found out that all the data
from my table were somehow deleted. I wanted to make
yes.. I also check for some info first before you can even hit the delete
file
-Original Message-
From: Ryan Sabir [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 2:30 PM
To: CF-Talk
Subject: RE: all records deleted from table
Are you type checking the variables that get
PROTECTED]]
RS Sent: Wednesday, 5 February 2003 9:31 AM
RS To: CF-Talk
RS Subject: all records deleted from table
RS Hi all,
RS I ran into a big problem this morning when I found out that all the data
RS from my table were somehow deleted. I wanted to make sure that it wasn't my
RS code so I did
The items in red is where your problem lies!
a simple sql statement via the url could delete all data from your db.
Have a look at your webserver log file, do a search for DELETE, if its anywhere in the
log file then see if its a SQL statement, if so, thats the hacker, trace its IP
address...
-- Original Message --
From: Taco Fleur [EMAIL PROTECTED]
PS. there are many sites out there that do not know about
this, I used to work for a company called XXX who I told
about this problem, but they don't care (or did not believe
me). You can
The items in red is where your problem lies!
a simple sql statement via the url could delete all data
from your db. Have a look at your webserver log file, do
a search for DELETE, if its anywhere in the log file then
see if its a SQL statement, if so, thats the hacker, trace
its IP
I just noticed that the HTML is removed from the message so you wont see the
items in red.
CItem=#CItem# is where the problem lies.
talking about security.
I know to:
- always use val() with integers in my queries
- always filter ANY data submitted, including hidden fields
- use regEx to
Your name makes me hungry Taco :) taco's
At 09:33 AM 2/5/2003 +1000, you wrote:
I just noticed that the HTML is removed from the message so you wont see the
items in red.
CItem=#CItem# is where the problem lies.
talking about security.
I know to:
- always use val() with integers in
Just a couple of pieces of advice. First, I'd recommend using CFQUERYPARAM
instead of Val in your inline SQL whenever possible. Second, in my
experience, people aren't really interested in deleting your data usually.
They'd much rather do something less visible but more useful (to them),
like
A long time ago, I made a really stupid mistake that results in deletion
of all data from a table... almost embarrassed to admit this in public, but
it might apply here.
There was an admin page with a list of all of the records in the table,
along with a link to delete or edit each
In general, you should probably avoid posting
information about specific vulnerabilities on
specific servers. Someday, someone may be held
liable for negligence for doing that sort of
thing - I think it's just a matter of time - and
you probably don't want to be that person.
I
I see your point, and I thank you for the warning..
- Original Message -
From: Dave Watts [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 2:21 PM
Subject: RE: all records deleted from table
In general, you should probably avoid posting
32 matches
Mail list logo
