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 <cr...@craigfrancis.co.uk> wrote: > 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 > 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 <sc...@paragonie.com> wrote: > > > 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 > >>> 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 <sc...@paragonie.com> > wrote: > >> > >>> On Tue, Jul 28, 2015 at 1: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 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 > >
