On Wed, 8 Sept 2021 at 09:32, Stephen Reay wrote:
> I had my share of issues with Craig’s PR, but I think the original goal of
> it was a good and useful concept
Thanks Stephen,
Just to confirm to others on-list... your "share of issues" was when we
looked at allowing all Integers, and you
On Wed, 8 Sept 2021 at 07:33, Claude Pache wrote:
> We all want to protect from injection vulnerability, but I think there are
> better way than is_literal.
>
> One way is to use templates, an area where PHP is ironically lagging
> behind. I suggest looking at JS tagged templates:
>
> On 8 Sep 2021, at 13:33, Claude Pache wrote:
>
>
>
>> Le 7 sept. 2021 à 11:49, Craig Francis a écrit :
>>
>>
>> Obviously I'd still like libraries to be able to protect everyone from
>> introducing Injection Vulnerabilities (as the majority of programmers don't
>> use static analysis),
> Le 7 sept. 2021 à 11:49, Craig Francis a écrit :
>
>
> Obviously I'd still like libraries to be able to protect everyone from
> introducing Injection Vulnerabilities (as the majority of programmers don't
> use static analysis), but that's for another day.
>
Hi,
We all want to protect
On Mon, 19 Jul 2021 at 19:59, Craig Francis
wrote:
> On Mon, 5 Jul 2021 at 19:14, Craig Francis
> wrote:
>
>> I have opened voting on https://wiki.php.net/rfc/is_literal for the
>> is-literal function.
>>
>
> This RFC has been rejected; with 10 votes in favour, and 23 against.
> [...]
> And
> On 20 Jul 2021, at 01:23, tyson andre wrote:
>
>> As an aside, only 4 of 23 'no' voters provided any comment as to why they
>> voted that way on the mailing list, which I feel undermines the point of
>> the Request For Comment process, with an additional 5 responding personally
>> off-list
Hi Craig Francis,
> As an aside, only 4 of 23 'no' voters provided any comment as to why they
> voted that way on the mailing list, which I feel undermines the point of
> the Request For Comment process, with an additional 5 responding personally
> off-list after prompting. This makes it harder
On Mon, 5 Jul 2021 at 19:14, Craig Francis wrote:
> Hi Internals,
> I have opened voting on https://wiki.php.net/rfc/is_literal for the
> is-literal function.
>
This RFC has been rejected; with 10 votes in favour, and 23 against.
I'd like to thank everyone who has been involved in this
On Mon, 19 Jul 2021 at 12:51, Guilliam Xavier
wrote:
> there was *indeed* an SQL injection vulnerability in that code.
Yep, you're right, there was an issue in there as well.
esc_like() also needs to use esc_sql() for the value to be added directly
to the SQL string.
By changing to
On Fri, Jul 16, 2021 at 2:47 AM Craig Francis
wrote:
> Just another day, and another injection vulnerability (please patch):
>
> https://woocommerce.com/posts/critical-vulnerability-detected-july-2021/
>
> If only escaping wasn't being used, so user values did not get included in
> certain
Thanks Nikita, that's good to know. I'm still familiarizing myself with the
source right now, so I apologize if this is something that commonly gets
spread as false information, I honestly was exploring the workings of
injection protection in the source after following this discussion, but
that's
On Sun, Jul 18, 2021 at 4:42 AM Jordan LeDoux
wrote:
> Related to the general topic of injection attacks, I was considering
> submitting a PR to change the default of PDO::ATTR_EMULUATE_PREPARES to
> FALSE, since this mistakenly can lead people to believe that using prepared
> statements with
Good morning,
On Mon, Jul 19, 2021 at 9:11 AM Jordan LeDoux wrote:
>
> > Are there documented SQL injection opportunities when using emulated
> prepares? I'm not aware of any.
>
> This was from my reading of the actual source, which of course may be
> flawed. It appeared that if emulated
> Are there documented SQL injection opportunities when using emulated
prepares? I'm not aware of any.
This was from my reading of the actual source, which of course may be
flawed. It appeared that if emulated prepares were used the values were
escaped and then passed as strings as part of the
>
> There's some BC-breaks to be aware of when switching emulated prepares.
> One example I know of is that when using emulated prepares you can reuse
> the same placeholder (as in the following example), but with emulated
> prepares disabled this does not work.
>
> $sql = "SELECT * FROM table
That sounds like something that would require both a deprecation and an RFC
for the change then, even if the actual change in the source is small.
It still may be worth exploring, since this surely gives a large number of
people false confidence in protection against injection attacks, as nearly
On 18/07/2021 03:41, Jordan LeDoux wrote:
Related to the general topic of injection attacks, I was considering
submitting a PR to change the default of PDO::ATTR_EMULUATE_PREPARES to
FALSE, since this mistakenly can lead people to believe that using prepared
statements with PDO and MySQL
Related to the general topic of injection attacks, I was considering
submitting a PR to change the default of PDO::ATTR_EMULUATE_PREPARES to
FALSE, since this mistakenly can lead people to believe that using prepared
statements with PDO and MySQL protects against injection attacks. In fact,
this
On Sat, 17 Jul 2021 at 4:05 pm, Marco Pivetta wrote:
> my belief is that this is not a runtime problem, but rather a type-level
> issue with tainted/untainted input/output.
>
Thank you for the feedback Marco,
As you appreciate, I don’t believe we can get every PHP developer to use
Static
Hey Craig,
On Mon, Jul 5, 2021 at 8:15 PM Craig Francis
wrote:
> Hi Internals,
>
> I have opened voting on https://wiki.php.net/rfc/is_literal for the
> is-literal function.
>
> The vote closes 2021-07-19
>
> The proposal is to add the function is_literal(), a simple way to identify
> if a
On Sat, 17 Jul 2021 at 08:59, Hans Henrik Bergan
wrote:
> i can tell from only that diff that, at least as of 5.5.1, woocommerce is
> not compatible with @@SQL_MODE=ANSI_QUOTES :p
Yep, and I did that years ago - I preferred to use single quotes for
strings in PHP (so variables stood out),
oh thanks, now the vulnerability is clear. (i would still complain on that
as a pull request though, using double quotes for strings is just a
horrible idea, it's not compliant with ISO sql, and it depends on the MySQL
server it's running on *not* having @@SQL_MODE=ANSI_QUOTES enabled which
On Fri, 16 Jul 2021 at 21:24, Hans Henrik Bergan
wrote:
> short of a bug in esc_like(), i don't even see the vulnerability issue in
> that code?
>
Sorry Hans, I copied the wrong diff.
There were only 2 changes from woocommerce 5.5.0 to 5.5.1.
Like you I was wondering what that diff was doing
short of a bug in esc_like(), i don't even see the vulnerability issue in
that code?
that sanitize call looks like a data corruption issue and i bet it fails to
search for binary data, but i don't see the critical vulnerability?
On Fri, 16 Jul 2021 at 15:50, Dan Ackroyd wrote:
> On Mon, 12 Jul 2021 at 19:57, Craig Francis
> wrote:
>
> > the “go-safe-html” library authors decided that
> > "the ergonomics of trusting concatenated constants far outweighs the
> security concern".
>
> Go is a quite different programming
On Mon, 12 Jul 2021 at 19:57, Craig Francis wrote:
> the “go-safe-html” library authors decided that
> "the ergonomics of trusting concatenated constants far outweighs the security
> concern".
Go is a quite different programming language to PHP.
When they say 'constants', they appear to be
On Fri, Jul 9, 2021 at 12:23 AM Máté Kocsis wrote:
> Hi Nikita,
>
> I performed a few other benchmarks in order to provide a little bit more
> insights into the performance aspect of the RFC. My latest measurement is
> using the same setup as the previous
> one, although I made a few smaller
Just another day, and another injection vulnerability (please patch):
https://woocommerce.com/posts/critical-vulnerability-detected-july-2021/
If only escaping wasn't being used, so user values did not get included in
certain strings :-)
diff -r
Injection Vulnerabilities remain at the top of the OWASP "Top 10 Web
Application Security Risks".
It’s important to remember that Injection Vulnerabilities don't just affect
the developer, but rather the data of potentially thousands of people using
the website/system.
These can even occur when
On Mon, 12 Jul 2021 at 14:17, Dan Ackroyd wrote:
> On Mon, 12 Jul 2021 at 02:09, Craig Francis
> wrote:
> >
> > you can choose not to use string concatenation ... allowing anyone to
> customise it to their needs
>
> Please can you explain how:
>
> i) An individual programmer can enforce that
On 11/07/2021 18:00, Dan Ackroyd wrote:
What it won't do, is tell you when you've forgotten to use it,
Which is a huge difference.
You've edited out the crucial last part of that sentence:
> but nor would a built-in implementation
I don't know how to make this point more emphatically:
On Mon, 12 Jul 2021 at 02:09, Craig Francis wrote:
>
> you can choose not to use string concatenation ... allowing anyone to
> customise it to their needs
Please can you explain how:
i) An individual programmer can enforce that they don't accidentally
use string concatenation for stuff that is
On Sun, 11 Jul 2021 at 18:09, Dan Ackroyd wrote:
> As I said in my reply to Rowan, making it easy to track down issues where
> they occur, minimises the cost of using this feature over the years it
> would be used.
>
This implementation allows you to do all of that.
If you find debugging is a
On Tue, 6 Jul 2021 at 10:32, Craig Francis wrote:
> which will result in too many invalid errors, requiring them to make
> substantial/unnecessary changes
My understanding is that the majority of PHP developers use one of the
many frameworks available. All of those provide libraries that people
Rowan Tommins wrote:
> I still don't follow this reasoning, for the reasons I outlined here:
> ...
> Whether "$foo . $bar" is always non-literal, or non-literal only if one
> of its operands is, you're going to get an error about a non-literal
> string somewhere else in the program, and have to
On Fri, 9 Jul 2021 at 11:49, Lauri Kenttä wrote:
> is there a compelling reason why the internal names couldn't be marked
> literal
> (even if it's technically "wrong")?
Hi Lauri,
Just again quickly noting we’re only talking about ~0.43% difference,
nothing major in any way.
But we wanted
On 2021-07-07 12:23, Nikita Popov wrote:
permanent interned strings, which will be predominantly (or entirely?)
non-literal. At least it doesn't look to me like names of internal
functions/classes/etc are considered literal. I think this may be
problematic, in that now the permanent non-literal
Hi Nikita,
I performed a few other benchmarks in order to provide a little bit more
insights into the performance aspect of the RFC. My latest measurement is
using the same setup as the previous
one, although I made a few smaller changes in the process (e.g. changing
the order of the tests). So
The perf numbers are for current implementation.
Predictability seems more important than simplicity, considering what the
feature is for.
The only way to make the simpler implementation predictable in the same
kind of way was found to be unacceptable during discussion.
Cheers
Joe
On
On Wed, 7 Jul 2021 at 10:23 am, Nikita Popov wrote:
> The RFC indicates that the impact is minor, but I believe those
> measurements were made with the original version of the RFC, which did not
> try to distinguish literal and non-literal interned strings
Hi Nikita,
The performance test
On Mon, Jul 5, 2021 at 8:15 PM Craig Francis
wrote:
> Hi Internals,
>
> I have opened voting on https://wiki.php.net/rfc/is_literal for the
> is-literal function.
>
> The vote closes 2021-07-19
>
> The proposal is to add the function is_literal(), a simple way to identify
> if a string was
On 05-07-2021 20:14, Craig Francis wrote:
> Hi Internals,
>
> I have opened voting on https://wiki.php.net/rfc/is_literal for the
> is-literal function.
I am glad to see that the RFC eventually turned out as originally
proposed. It is simple and provides clear and strong guarantees about
the
On Tue, 6 Jul 2021 at 7:38 am, G. P. B. wrote:
> Although I think the idea of the feature is useful,
> I'm not so sure about the implementation.
> [...]
> Whereas using a function like concat_literal() which checks that the
> inputs are indeed literals provides immediate feedback that the type
>
On 06/07/2021 07:38, G. P. B. wrote:
This is I think the main issue with the current shape of the proposal.
This implementation will detect certain security issues, but finding the
root cause for them is going to be rather complicated, as the concatenation
operation is basically kicking the can
On Mon, 5 Jul 2021 at 20:15, Craig Francis wrote:
> Hi Internals,
>
> I have opened voting on https://wiki.php.net/rfc/is_literal for the
> is-literal function.
>
> The vote closes 2021-07-19
>
> The proposal is to add the function is_literal(), a simple way to identify
> if a string was written
Hi Internals,
I have opened voting on https://wiki.php.net/rfc/is_literal for the
is-literal function.
The vote closes 2021-07-19
The proposal is to add the function is_literal(), a simple way to identify
if a string was written by a developer, removing the risk of a variable
containing an
46 matches
Mail list logo
