On 31 Jul 2015, at 15:00, Joe Watkins <[email protected]> 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 happening, right ?
Hi Joe,
I've just replied to Matt and your email came in as I sent... so a bit of a change there.
But what I was proposing was that PHP simply checks the way in which the variables (strings) are
being passed around... if something from $_GET is passed into mysqli_query without being escaped (as
a parameter or as a quoted escaped string), it will still continue, but a note will be written to
the log (or on the page if display_errors is on).
The same would happen when you echo a $_GET variable :-)
So in 3015, if the taint checking isn't configured properly (switched on)... it wouldn't
change the execution, it's just not checking things (oh well), it should still have been coded
properly to begin with.
So the way in which PHP executes is not effected, it's just picking up the "oh, you
probably shouldn't be doing this".
Now Matt's suggestion allowed things to be actively blocked... I'm not sure I'd use
that, but it might work for some (I'd just be happy having a log to check, in the same way that
I use the logs for undefined variables, script timeouts, etc).
And yes, you won't get a perfect system (there are some edge cases)... but keeping it as simple
as possible (hence why I want to take a slightly different approach to the 2008 RFC), it should pick
up the most common mistakes.
But please do talk about security, you may be wrong, but thats fine, I'm sure someone will be
able to correct you... I personally feel that too many people try to ignore security, and
that's why we keep having so many problems (that said, performance and accessibility also need
some attention, but that's more for the developers creating the websites, rather than PHP
internals).
Craig
On 31 Jul 2015, at 15:00, Joe Watkins <[email protected]> wrote:
> 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 implementation ... it's not
> hard to imagine these things happening, right ?
>
> When I made reference to safe_mode, it wasn't because I misunderstood the concept, I
> know you're not introducing another safe mode, but introducing a INI, or build, or
> configuration option that says "we got this" is doomed to fail whatever.
>
> I don't like to talk about security, it's not something I feel qualified to talk
> about really, but I can observe that catch-all security "features" have already been
> proven to fail ...
>
> It's the year 3015, we're all running PHP442, our taint implementation is
> flawless, every major framework (which we have a futurish word for) relies on tainting and thinks
> SQLi is no longer a thing to worry about, because "we got this". A junior sysadmin, on
> mars, is charged with upgrading PHP on the server that is responsible for crop irrigation on the
> terra-formed world, and forgets to configure taint properly. The upgrade goes live, renegade ruby
> fans hack the system disrupting food production, leading to the eventual death of everything.
>
> It's Friday afternoon, and that was a bit of fun ... I hope I lifted your mood ... push
> on, I can be wrong, Pierre can be wrong, we can all be wrong ...
>
> Cheers
> Joe
>
> On Fri, Jul 31, 2015 at 11:40 AM, Craig Francis <[email protected]> wrote:
> On 30 Jul 2015, at 17:02, Joe Watkins <[email protected]> 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 said, and I have read those responses again, but
> unfortunately I still feel that I was right in my assumptions (notes below, maybe some interesting
> additions?).
>
> In general I have been getting very frustrated that no-one seems to really care about security
> (and to be fair, it has been annoying me for far too many years).
>
> Keeping in mind that I work with other developers who routinely keep introducing
> vulnerabilities like SQLi, XSS, CSRF... and doing annoying things like switching the CSP off,
> because they copy/paste some hideous/insecure JS, and can't be bothered to work out why the
> "eval" function isn't working.
>
> So maybe I should start a new thread, without Matt's subject (btw Matt, I really
> appreciate what you are trying todo, I disagree with the blocking element, and I think we can also
> address more than just SQL injection vulnerabilities)... maybe something like "I've found
> this one weird trick that will fix every security issue"... sorry, I hate that kind of
> approach, but if it gets a response, maybe its worth it :-)
>
> Craig
>
>
>
> --------------------------------------------------
> http://news.php.net/php.internals/87346
> From: Matt Tait
> Reply: N/A
>
> Original suggestion.
>
> --------------------------------------------------
> http://news.php.net/php.internals/87348
> From: Rowan Collins
> Reply: Matt Tait
>
> Suggestion to Matt to look for previous RFCs.
>
> --------------------------------------------------
> http://news.php.net/php.internals/87350
> From: Christoph Becker
> Reply: Matt Tait
>
> Points out the existing Taint RFC from 2008, by Wietse Venema.
>
> --------------------------------------------------
> http://news.php.net/php.internals/87355
> From: Pierre Joye
> Reply: Matt Tait
>
> Pointing out that there is more than SQLi (true), and it might be an impossible task (I
> disagree, as explained later).
>
> --------------------------------------------------
> http://news.php.net/php.internals/87361
> From: Thomas Bley
> Reply: Matt Tait
>
> Suggesting the use of bound parameters / prepared statements, which I agree is how it should be
> coded by the website developers, but I think the PHP language itself can help identify when this has
> not been done (just by raising a notice, not blocking anything).
>
> Also Thomas points out that static code analysis could identify these issues, but these are far
> from perfect, and PHP is in a much better position to be doing this... and has the advantage of
> being available to everyone.
>
> Just to note, I've played with a couple of static code analysers which cost in the region
> of £19,000 per year, and they still don't find the same number of escaping issues that my
> suggestion can find (they do look at other issues, so don't get rid of them, but this one thing
> that can be done better with the programming language itself).
>
> --------------------------------------------------
> http://news.php.net/php.internals/87363
> From: Lester Caine
> Reply: Matt Tait
>
> Short answer saying you should not use mysql... which I think is a bit short sighted (on the
> assumption that mysqli is a similar interface for most website developers).
>
> I'm not against using tools like ORMs (e.g. Doctrine), bound parameters / prepared
> statements, or even stored procedures... but they all have issues, and are all vulnerable to the
> kind of misuse I'm trying to address (explained in the next email).
>
> --------------------------------------------------
> http://news.php.net/php.internals/87370
> From: Me (Craig Francis)
> Reply: Lester Caine
>
> Just saying I disagree with Lester, and giving a very simple example of how developers can
> still mess up (once you start adding some abstractions, like an ORM, this becomes much harder to
> detect, and is why I'm so insistent that PHP needs to be checking for these issues).
>
> This is where I also suggest an alternative to Matt's original suggestion (something I
> posted 12 days before, and didn't really get any response).
>
> --------------------------------------------------
> http://news.php.net/php.internals/87383
> From: Lester Caine
> Reply: Me (Craig Francis)
>
> Kind of missing the point (maybe my example was too simple), and is talking about how Matts
> solution would cause problems.
>
> And I agree (sorry Matt), I don't think Matt's solution would work... but if Lester
> had read my reply, he would have seen that my suggestion was about education (but it can also help
> experienced developers as well).
>
> --------------------------------------------------
> http://news.php.net/php.internals/87386
> From: Me (Craig Francis)
> Reply: Lester Caine
>
> Trying to explain to Lester that I agree on education, and pointing out that my solution is
> different... and how (maybe my email was too long to read?).
>
> --------------------------------------------------
> http://news.php.net/php.internals/87391
> From: Joe Watkins
> Reply: Me (Craig Francis)
>
> Saying you agree with Pierre... I do as well, as Pierre was talking about Matt's solution.
>
> --------------------------------------------------
> http://news.php.net/php.internals/87393
> From: Me (Craig Francis)
> Reply: Joe Watkins
>
> Pointing out that my suggestion was different... I realise I'm now trying to derail
> Matt's original thread (this one seems to be getting some attention), but I really want to
> address these same issues.
>
> --------------------------------------------------
> http://news.php.net/php.internals/87396
> From: Xinchen Hui
> Reply: Joe Watkins
>
> Giving a quick status update on the original 2008 implementation... which I personally think is
> good, but could be made better by switching the logic around (I believe this will make the
> implementation easier, and avoid many edge cases).
>
> --------------------------------------------------
> http://news.php.net/php.internals/87400
> From: Scott Arciszewski
> Reply: Matt Tait
>
> Pointing out that Cross-Site Scripting is a bigger issue now... where I think that taints can
> address both issues (and more).
>
> He also says that prepared statements is a solved problem (something that I partially disagree
> with, and have explained above, but I realise that Scott is replying to Matt's original email,
> so may not have read that far yet).
>
> --------------------------------------------------
> http://news.php.net/php.internals/87403
> From: Me (Craig Francis)
> Reply: Xinchen Hui
>
> Just saying that I appreciate the work Xinchen is doing, and offering to help (assuming I
> can)... I do also go off on a bit of a tangent, as I think that if we invert the 2008 RFC to mark
> things when they are escaped (rather than tainting everything as they are created), then I think the
> implementation would be a lot easier.
>
> --------------------------------------------------
> http://news.php.net/php.internals/87404
> From: Me (Craig Francis)
> Reply: Scott Arciszewski
>
> Pointing out that I have a different suggestion.
>
> I also wanted to say that I don't think SQL injection is a solved problem, as I tried to
> explain earlier (which Scott may not have read yet)... but I certainly didn't want Scott to
> just sit back and think everything is solved now, so no need to discuss.
>
> --------------------------------------------------
> http://news.php.net/php.internals/87405
> From: Scott Arciszewski
> Reply: Me (Craig Francis)
>
> Skipping over my suggestion, and just saying that education is needed... which is what I'm
> also trying to do.
>
> But as PHP is the only thing that can be forced in front of a new developer, it is really the
> only common thing that can do that education (there is no way you can find and talk to every single
> new developer just by answering questions on Stack Overflow).
>
> And just as an example, college students leaning to write C programs in 2015 and creating
> buffer overflow vulnerabilities... they still make mistakes (even highly experienced developers
> still make these mistakes)... and you also have to recognise that not every programmer will go to a
> college, and that not all colleges actually teach their students about this (unfortunately).
>
> --------------------------------------------------
> http://news.php.net/php.internals/87406
> From: Ronald Chmara
> Reply: ???
>
> I'm going to assume this is a reply to Matt's suggestion (or just the subject).
>
> And I agree, that suggestion would break every single application... hence why I'm not
> suggesting that approach.
>
> --------------------------------------------------
> http://news.php.net/php.internals/87407
> From: Me (Craig Francis)
> Reply: Ronald Chmara
>
> I'm just explaining that I've hijacked the email thread started by Matt, and that
> there is more to the discussion.
>
> --------------------------------------------------
> http://news.php.net/php.internals/87408
> From: Me (Craig Francis)
> Reply: Scott Arciszewski
>
> I am getting a little frustrated, and just want to move the discussion on.
>
> Unfortunately what you don't know is that I've been having this issue for too many
> years, and I'm getting quite annoyed that we aren't addressing these problems in a simple
> way.
>
> Instead, what I keep seeing is more complicated half solutions (e.g. ORMs and query builders,
> where typical website developers have no idea what the SQL/DB is doing, so vulnerabilities still
> creep in, and introduce other problems like n+1).
>
> The amount of times I've been to PHP conferences where the speaker is explaining some new
> way that they are doing OOP (or maybe even functional programming), and I'm sure they are
> really proud of their highly complex solution that few people in the audience understand (and no,
> I'm usually able to follow along, my experience is trying to explain what the talk was about to
> another audience member afterwards).
>
> But ultimately they haven't addressed anything todo with security, and it is often less
> performant (typical response "hey, get a faster computer"), it has instead taken them 3+
> months to implement, has resulted in another 1 or 2 layers of abstraction that the typical developer
> does not understand (they just run it, and hope for the best).
>
> Then in 6 months time they will have moved on to a different complex solution, and can't
> be bothered to support the old one any more (because they just want something hard/complex to work
> on? I'm assuming it's an ego thing?).
>
> --------------------------------------------------
> http://news.php.net/php.internals/87409
> From: Joe Watkins
> Reply: Me (Craig Francis)
>
> Where we are today... where you are talking about the RFC (from 2008, or the one from Matt),
> not what I've just said about my suggestion (which, if you haven't read, is different).
>
> --------------------------------------------------
>
>
>
>
>
>
> On 30 Jul 2015, at 17:02, Joe Watkins <[email protected]> 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".
>>
>> There is a good chance the majority of the people replying have read the RFC, and found
>> reason to be negative, reserved, cautious, or whatever.
>>
>> The best thing you can do now is read those responses again, and try to find what they are
>> saying, if you want the conversation to continue.
>>
>> Cheers
>> Joe
>>
>> On Thu, Jul 30, 2015 at 4:38 PM, Craig Francis <[email protected]> wrote:
>> On 30 Jul 2015, at 16:24, Scott Arciszewski <[email protected]> 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 notice this is what I'm trying to do
>> (so not just people asking questions on Stack Overflow).
>>
>> My suggestion is to educate, it also has a nice side effect of having a simple checking
>> process for everything else (without breaking anything).
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 30 Jul 2015, at 16:24, Scott Arciszewski <[email protected]> wrote:
>>
>> > On Thu, Jul 30, 2015 at 11:20 AM, Craig Francis
>> > <[email protected]> wrote:
>> >> On 30 Jul 2015, at 14:43, Scott Arciszewski <[email protected]> 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 than SQL Injection, especially in business
>> >>> applications.
>> >>
>> >>
>> >> Good, because my suggestion was also addressing XSS with poor (or completely
>> >> missing) HTML escaping... have a look:
>> >>
>> >> http://news.php.net/php.internals/87207
>> >>
>> >> https://bugs.php.net/bug.php?id=69886
>> >>
>> >> Now I admit it won't fix everything with XSS (as HTML escaping is a bit
>> >> harder), but it certainly will pick up quite a lot of the issues (and it wont break anything either,
>> >> just help developers identify problems).
>> >>
>> >> And no, SQL injection is far from a solved problem... this is why, after 15 years
>> >> of me trying to tell my fellow developers to not make these mistakes, I'm still finding them
>> >> making them over and over again... hence why I'm making the above suggestion.
>> >>
>> >> Craig
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On 30 Jul 2015, at 14:43, Scott Arciszewski <[email protected]> wrote:
>> >>
>> >>> On Tue, Jul 28, 2015 at 1:33 PM, Matt Tait <[email protected]> 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 short, we make zend_strings track where their value originated. If it
>> >>>> originated as a T_STRING, from a primitive (like int) promotion, or as a
>> >>>> concatenation of such strings, it's query that can't have been
>> >>>> SQL-injected
>> >>>> by an attacker controlled string. If we can't prove that the query is
>> >>>> safe,
>> >>>> that means that the query is either certainly vulnerable to a
>> >>>> SQL-injection
>> >>>> vulnerability, or sufficiently complex that it should be parameterized
>> >>>> just-to-be-sure.
>> >>>>
>> >>>> There's also a working proof of concept over here:
>> >>>>
>> >>>> http://phpoops.cloudapp.net/oops.php
>> >>>>
>> >>>> You'll notice that the page makes a large number of SQL statements,
>> >>>> most of
>> >>>> which are not vulnerable to SQL injection, but one is. The proof of
>> >>>> concept
>> >>>> is smart enough to block that one vulnerable request, and leave all of the
>> >>>> others unchanged.
>> >>>>
>> >>>> In terms of performance, the cost here is negligible. This is just basic
>> >>>> variable taint analysis under the hood, (not an up-front intraprocedurale
>> >>>> static analysis or anything complex) so there's basically no slow
>> >>>> down.
>> >>>>
>> >>>> PHP SQL injections are the #1 way PHP applications get hacked - and all
>> >>>> SQL
>> >>>> injections are the result of a developer either not understanding how to
>> >>>> prevent SQL injection, or taking a shortcut because it's fewer
>> >>>> keystrokes
>> >>>> to do it a "feels safe" rather than "is safe" way.
>> >>>>
>> >>>> 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.
>> >>>>
>> >>>> Matt
>> >>>
>> >>> Hi Matt,
>> >>>
>> >>>> PHP SQL injections are the #1 way PHP applications get hacked - and all
>> >>>> SQL
>> >>>> injections are the result of a developer either not understanding how to
>> >>>> prevent SQL injection, or taking a shortcut because it's fewer
>> >>>> keystrokes
>> >>>> to do it a "feels safe" rather than "is safe" way.
>> >>>
>> >>> 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 information that indicates that SQLi is
>> >>> still more prevalent than XSS, I'd love to see this data.
>> >>>
>> >>> In my opinion, SQL injection is almost a solved problem. Use prepared
>> >>> statements where you can, and strictly whitelist where you cannot
>> >>> (i.e. "ORDER BY {$column} ASC")
>> >>>
>> >>> Scott Arciszewski
>> >>> Chief Development Officer
>> >>> Paragon Initiative Enterprises <https://paragonie.com>
>> >>>
>> >>> --
>> >>> PHP Internals - PHP Runtime Development Mailing List
>> >>> To unsubscribe, visit: http://www.php.net/unsub.php
>> >>>
>> >>
>> >
>> > Just because the solution is known doesn't mean it's known to
>> > everyone. Diffusion of knowledge and good habits is the hardest
>> > problem in application security to solve. Look, for example, at how
>> > many college students learn to write C programs with buffer overflow
>> > vulnerabilities in 2015. We need more effort on education, which is
>> > part of what I've been focusing on with Paragon Initiative and Stack
>> > Overflow.
>> >
>> > Scott Arciszewski
>> > Chief Development Officer
>> > Paragon Initiative Enterprises <https://paragonie.com>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>