Hi Matt,
My friend made a product called sql_firewall for PostgreSQL.
https://github.com/uptimejp/sql_firewall
http://pgsnaga.blogspot.jp/2015/08/postgresql-sql-firewall.html
It's not directly relevant to your proposal, but this kind of database extension
could be alternative.
PDO has parser
I don't think the proposal is useless nor ineffective.
Taint system is nice to have, but the proposal does not seem preferable
resolution.
Don't get me wrong. I agree with your discussion overall.
I tend to dislike all or nothing choice for security related issues
especially,
On 12 Aug 2015, at 00:43, Christoph Becker cmbecke...@gmx.de wrote:
On 10.08.2015 at 11:57, Craig Francis wrote:
You only have to skim read things like the second comment (with 27 up votes)
on the PDO prepare page to see that these problems are happening all the
time:
Hi all,
On Mon, Aug 10, 2015 at 6:57 PM, Craig Francis cr...@craigfrancis.co.uk
wrote:
I have been reading your conversation with great interest.
But I would urge you to see Matts suggestion as a simple addition to the
language (it's simpler than my suggestion), where his RFC seems to have
On 10.08.2015 at 11:57, Craig Francis wrote:
You only have to skim read things like the second comment (with 27 up votes)
on the PDO prepare page to see that these problems are happening all the time:
http://php.net/manual/en/pdo.prepare.php#111458
SELECT * FROM users WHERE
Hi Anthony, Julien, Yasuo,
I have been reading your conversation with great interest.
But I would urge you to see Matts suggestion as a simple addition to the
language (it's simpler than my suggestion), where his RFC seems to have already
addressed your concerns (and he seems to have a working
Matt,
You are of course welcome to disagree with the overwhelming body of security
advice that parameterized queries are the correct, secure way to prevent SQL
injection. In that case, you only need to not enable this feature. This
feature is off-by-default, and only attempts to help secure
Hi Matt,
On Thu, Aug 6, 2015 at 12:46 PM, Matt Tait matt.t...@gmail.com wrote:
I'll take a few of your points in turn.
With regards to the fact that not all SQL queries are directly
parameterizable, this is true. Structural parts of a query, such as table
names, column names and complex
On Fri, Aug 7, 2015 at 10:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Even if there is identifier placeholder, SQL keyword remains.
So to be perfect, you'll need another place holder for SQL keywords.
There is no escaping for SQL keywords and it has to be validation.
e.g. ORDER BY
Thanks for the feedback Anthony,
This feature specifically addresses the points you raise; the feature allows
parameterized queries constructed with structural parts of the query inserted
from configuration variables, so long as the resulting query is a safe-const as
defined by this RFC.
If
Hi Matt,
Am 06.08.2015 um 05:46 schrieb Matt Tait:
With regards to the fact that not all SQL queries are directly
parameterizable, this is true. Structural parts of a query, such as table
names, column names and complex conditions are hard to parameterize with
vanilla prepared statements, and
Thanks for your feedback, Anthony.
I'll take a few of your points in turn.
With regards to the fact that not all SQL queries are directly
parameterizable, this is true. Structural parts of a query, such as table
names, column names and complex conditions are hard to parameterize with
vanilla
On Tue, Jul 28, 2015 at 7:33 PM, Matt Tait matt.t...@gmail.com wrote:
Hi all,
I've written an RFC (and PoC) about automatic detection and blocking of SQL
injection vulnerabilities directly from inside PHP via automated taint
analysis.
https://wiki.php.net/rfc/sql_injection_protection
In
All,
On Wed, Aug 5, 2015 at 10:40 AM, Julien Pauli jpa...@php.net wrote:
On Tue, Jul 28, 2015 at 7:33 PM, Matt Tait matt.t...@gmail.com wrote:
Hi all,
I've written an RFC (and PoC) about automatic detection and blocking of SQL
injection vulnerabilities directly from inside PHP via automated
Thanks for the feedback Anthony and Julien,
The case you refer to using mysqli_real_escape_string is addressed in the
RFC, and cannot be injected when this feature is enabled, as the query is
always marked as tainted and always blocked, regardless of the connection.
Here's your example running
Matt,
To be clear: this feature does not track taint through escape functions,
regular expression filters, ctype_filters and the like by design. Security
best-practice and more than a decade of security consulting experience show
that developers who rely on filters and escaping rarely manage
On 31 Jul 2015, at 17:40, Ronald Chmara rona...@gmail.com wrote:
The RFC and bug report both make an erroneous assumption that unescaped GPC
input is wrong.
Hi Ronabop,
Slightly continuing our discussion, but also replying to your on-list message...
Starting with your examples:
1) Web
On 31 Jul 2015, at 15:00, Joe Watkins pthre...@pthreads.org wrote:
Even the best implementation need only have a single hole in it and
everything falls apart, one extension not doing something properly, or one
mistake in the implementation ... it's not hard to imagine these things
Thanks for the feedback Joe!
To be clear, this feature is not an alternative to coding SQL securely with
parameterized queries. Indeed, it's entire purpose is to help developers
move dangerously coded queries (i.e. ones that are not parameterized and
are dynamically constructed using parameters
This may have been true at one point in time, but my own experience
and the statistics collected by Dan Kaminsky of White Hat Security
indicates that Cross-Site Scripting vulnerabilities are much more
prevalent in 2015 than SQL Injection, especially in business
applications. If Google has
Morning Craig,
I think Pierre and I object to the concept, regardless of the
intricacies of any particular implementation.
Even the best implementation need only have a single hole in it and
everything falls apart, one extension not doing something properly, or one
mistake in the
Hi Matt,
I take it all back... I've been so sure of my own suggestion, I've not really
given your RFC a proper read... and I think this could work.
The main difference I had was the ability to support to support the escaping
functions (see pg_escape_literal for PostgreSQL, or htmlentities for
On 28/07/15 18:33, Matt Tait wrote:
What do you all think? There's obviously a bit more work to do; the PoC
currently only covers mysqli_query, but I thought this stage is an
interesting point to throw it open to comments before working to complete
it.
So who addresses all the other database
On Thu, Jul 30, 2015 at 8:38 AM, Craig Francis cr...@craigfrancis.co.uk
wrote:
On 30 Jul 2015, at 16:26, Ronald Chmara rona...@gmail.com wrote:
Perhaps I have missed something in this discussion
I think you have... my email from a couple of weeks ago was ignored... so
I replied to Matt's
On 30 Jul 2015, at 17:02, Joe Watkins pthre...@pthreads.org wrote:
Even if some of those people replying haven't read or don't understand what
you are suggesting, it is not a good tactic to assume that and reply with
read the RFC.
Hi Joe,
Sorry about yesterday, I have done as you have
On 30 Jul 2015, at 13:14, Joe Watkins pthre...@pthreads.org wrote:
I find myself agreeing with Pierre; The wrong signal would be sent. History
should teach us there is no such thing as (a) safe mode.
Hi Joe,
Please can you read my proposal (see the email you just replied to, also
I find myself agreeing with Pierre; The wrong signal would be sent. History
should teach us there is no such thing as (a) safe mode.
Xinchen did used to work on a taint extension, I wonder why that was
stopped ?
Worth noticing that the extension is rather complex, touching many parts of
the
Hey:
On Thu, Jul 30, 2015 at 8:14 PM, Joe Watkins pthre...@pthreads.org wrote:
I find myself agreeing with Pierre; The wrong signal would be sent. History
should teach us there is no such thing as (a) safe mode.
Xinchen did used to work on a taint extension, I wonder why that was
stopped ?
On 30 Jul 2015, at 16:24, Scott Arciszewski sc...@paragonie.com wrote:
Just because the solution is known doesn't mean it's known to everyone.
Yes, and if you could just read what I was suggesting, rather than looking at
the subject of this email (and the suggestion by Matt), then you will
On Thu, Jul 30, 2015 at 11:20 AM, Craig Francis
cr...@craigfrancis.co.uk wrote:
On 30 Jul 2015, at 14:43, Scott Arciszewski sc...@paragonie.com wrote:
This may have been true at one point in time, but my own experience
and the statistics collected by Dan Kaminsky of White Hat Security
On 30 Jul 2015, at 16:26, Ronald Chmara rona...@gmail.com wrote:
Perhaps I have missed something in this discussion
I think you have... my email from a couple of weeks ago was ignored... so I
replied to Matt's suggestion (which is similar, but different).
Please, just spend a few minutes
On 30 Jul 2015, at 13:47, Xinchen Hui larue...@php.net wrote:
anyway, with PHP7's new zend_string, and string flags, the
implementation will become easier.
Hi Xinchen,
Glad to hear that you are still looking into this... please let me know if
there is anything I can do to help
On 30 Jul 2015, at 14:43, Scott Arciszewski sc...@paragonie.com wrote:
This may have been true at one point in time, but my own experience
and the statistics collected by Dan Kaminsky of White Hat Security
indicates that Cross-Site Scripting vulnerabilities are much more
prevalent in 2015
Perhaps I have missed something in this discussion where such a change to
PHP does not break every single application that is supposed to pass raw,
user submitted, SQL *without* getting prepared/nerfed, or warned about, by
intentional application design.
If we're just limiting the nerfing for
On 29/07/15 16:11, Craig Francis wrote:
I completely disagree... prepared statements are just as vulnerable, and so
are ORM's.
You can push developers towards these solutions, and that would be good, but
you are completely blind if you think an uneducated developer won't do:
if
Even if some of those people replying haven't read or don't understand what
you are suggesting, it is not a good tactic to assume that and reply with
read the RFC.
There is a good chance the majority of the people replying have read the
RFC, and found reason to be negative, reserved, cautious, or
On 30 Jul 2015, at 08:24, Lester Caine les...@lsces.co.uk wrote:
But that is a perfect example of what I am talking about. You do not
educate people by publishing the very thing that is wrong. You educate
them by pointing out to them WHY the '?' was there in the first place.
I completely
On 29 Jul 2015, at 10:02, Lester Caine les...@lsces.co.uk wrote:
The problem is removing all of the poor quality on-line guides and
replacing them with ones which provide a mush better working model.
Trying to get PHP too pick up a few edge cases is a poor use of time.
I completely
Pierre Joye wrote on 28.07.2015 23:05:
The
On Jul 28, 2015 11:42 PM, Christoph Becker cmbecke...@gmx.de wrote:
Rowan Collins wrote:
On 28 July 2015 18:33:31 BST, Matt Tait matt.t...@gmail.com wrote:
Hi all,
I've written an RFC (and PoC) about automatic detection and blocking of
SQL
On 28/07/15 18:33, Matt Tait wrote:
What do you all think? There's obviously a bit more work to do; the PoC
currently only covers mysqli_query, but I thought this stage is an
interesting point to throw it open to comments before working to complete
it.
If you want a safe and stable system ...
Hi all,
I've written an RFC (and PoC) about automatic detection and blocking of SQL
injection vulnerabilities directly from inside PHP via automated taint
analysis.
https://wiki.php.net/rfc/sql_injection_protection
In short, we make zend_strings track where their value originated. If it
The
On Jul 28, 2015 11:42 PM, Christoph Becker cmbecke...@gmx.de wrote:
Rowan Collins wrote:
On 28 July 2015 18:33:31 BST, Matt Tait matt.t...@gmail.com wrote:
Hi all,
I've written an RFC (and PoC) about automatic detection and blocking of
SQL
injection vulnerabilities directly from
On 28 July 2015 18:33:31 BST, Matt Tait matt.t...@gmail.com wrote:
Hi all,
I've written an RFC (and PoC) about automatic detection and blocking of
SQL
injection vulnerabilities directly from inside PHP via automated taint
analysis.
https://wiki.php.net/rfc/sql_injection_protection
Have you
Rowan Collins wrote:
On 28 July 2015 18:33:31 BST, Matt Tait matt.t...@gmail.com wrote:
Hi all,
I've written an RFC (and PoC) about automatic detection and blocking of
SQL
injection vulnerabilities directly from inside PHP via automated taint
analysis.
44 matches
Mail list logo
