On Tue, 23 Mar 2004 12:05:17 -0800, Pablo Gosse wrote:
I think you have misunderstod the concepts of making queries based on
user input. It is not the users who should create the query, all to
should do is provide the input to narrow down the queries.
I have not misunderstood the concepts
snip
The idea is exactly not to do any queries dynamically generated based
on user input! In the rare cases where this is needed you should not
allow any unparsed input.
/snip
A RARE case, in the world of web applications??? Hardly!
I agree that in an optimal situation queries will not
--- Michael Rasmussen [EMAIL PROTECTED] wrote:
The idea is exactly not to do any queries dynamically generated based
on user input!
This argument still makes no sense to me. Originally, you stated that a
better option to filtering and escaping data was to use a prepared
statement. Some of us
On Tue, 23 Mar 2004 08:25:32 -0800, Pablo Gosse wrote:
A RARE case, in the world of web applications??? Hardly!
I agree that in an optimal situation queries will not be based on user
input, but in the world of the web this is a pipe dream. In 99.99% of the
cases there will be some
On Tue, 23 Mar 2004 09:27:29 -0800, Chris Shiflett wrote:
This argument still makes no sense to me. Originally, you stated that a
better option to filtering and escaping data was to use a prepared
statement. Some of us have decided that you are referring to stored
procedures.
You still
--- Michael Rasmussen [EMAIL PROTECTED] wrote:
I think you have misunderstod the concepts of making queries based
on user input. It is not the users who should create the query, all
to should do is provide the input to narrow down the queries.
To be honest, I think Pablo understands the
snip
PG A RARE case, in the world of web applications??? Hardly!
PG
PG I agree that in an optimal situation queries will not be based on
PG user input, but in the world of the web this is a pipe dream. In
PG 99.99% of the cases there will be some dynamic element to a query.
PG The only
On Sunday 21 March 2004 06:39 pm, Chris Shiflett wrote:
--- Michael Rasmussen [EMAIL PROTECTED] wrote:
To be clear: make sure the data that the user submitted only
contains the characters you think are valid (don't bother trying
to guess malicious characters - you're sure to miss one)
On 21 Mar 2004 Chris Shiflett wrote:
I would never argue that something is an absolute defense, but I would
characterize my recommendation as a best practice.
Fair enough.
I agree with you that checking for valid characters is safer than
checking for malicious characters, but even the
On Sun, 21 Mar 2004 18:39:39 -0800, Chris Shiflett wrote:
Can you explain that (and defend it)?
The reason is security. A prepared statement cannot comprimize the
security of our database because all sql-statements are precompiled in the
DBMS. An example using pear:
$res =
snip
The reason is security. A prepared statement cannot comprimize the
security of our database because all sql-statements are precompiled
in the DBMS. An example using pear:
$res = DB:connect('mysql://someuser:[EMAIL PROTECTED]/thedb');
$sth = $res-prepare('select * from sometable
On Mon, 22 Mar 2004 14:36:44 -0800, Pablo Gosse wrote:
Huh? How does this accommodate for a dynamically generated query which is
based upon user input?
Have you read my arguments? A prepared statement cannot be dynamically
generated!
It is validated and its type set before it is
On 23 Mar 2004 Michael Rasmussen wrote:
The idea is exactly not to do any queries dynamically generated based on
user input! In the rare cases where this is needed you should not
allow any unparsed input.
There are some applications for which queries based on typed user input
are rare. But
--- Ali Ashrafzadeh [EMAIL PROTECTED] wrote:
I'm looking for a function To check SQL Injection in Mysql RDBMS
please tell me if anyone know good function or solution
In my opinion, this is the wrong approach.
SQL injection vulnerabilities exist when you use data that the user gave
you to
On Sun, 21 Mar 2004 13:49:22 -0800, Chris Shiflett wrote:
To be clear: make sure the data that the user submitted only contains the
characters you think are valid (don't bother trying to guess malicious
characters - you're sure to miss one) and is a valid length. Once you've
done this, and
--- Michael Rasmussen [EMAIL PROTECTED] wrote:
To be clear: make sure the data that the user submitted only
contains the characters you think are valid (don't bother trying
to guess malicious characters - you're sure to miss one) and is a
valid length. Once you've done this, and your
On 21 Mar 2004 Chris Shiflett wrote:
SQL injection vulnerabilities exist when you use data that the user gave
you to create your SQL statement. So, anytime that this happens, simply
make absolutely sure that the data you are using from the user fits a very
specific format that you are
--- [EMAIL PROTECTED] wrote:
Recently I've been in the middle of trying to build defenses against
SQL injection on a site I'm working on (proactively, we haven't had a
problem). While this principle seems exactly right, I find it's not as
easy to implement as it sounds, and I'd argue that
18 matches
Mail list logo
