[PHP-DEV] VCS Account Request: matttait

Interested in helping security-audit and add security-related features to PHP core. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Introductions

Hi all, I'm Matt Tait; a security researcher at Google, and I'm quite interested in looking at and helping to build new security-related features within PHP; i.e. features that reduce the likelihood that deployments of PHP end up being hacked. In the short term, I'm quite intere

[PHP-DEV] VCS Account Request: matttait

To develop core security features, security enhancements and performance enhancements for PHP Core (i.e. the C code for Zend and PHP Core, not PHP extensions or PHP applications). Initially I\'ll be focusing on integrating compiler and security level improvements to PHP binaries. I have already

[PHP-DEV] Resetting wiki.php.net password

Hi all, I'm currently trying to reset my wiki.php.net password so I can propose an RFC, but unfortunately I'm getting the following error messages when I reset it via the page "https://wiki.php.net/start?do=resendpwd": ! Unable to modify user data. Please inform the Wiki-Admin ! e

[PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

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 originat

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

user-submitted SQL statements to the database by design? == This is accounted for in the RFC. Developers will be able to explicitly mark SQL queries as disabling the SQL-injection feature for the queries that explicitly warrant this (PHPMyAdmin being a good example). Again, this is only relevant i

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

t;> 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 a

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

community. Hope that helps clear things up! Matt On 5 August 2015 at 16:27, Anthony Ferrara wrote: > All, > > On Wed, Aug 5, 2015 at 10:40 AM, Julien Pauli wrote: > > On Tue, Jul 28, 2015 at 7:33 PM, Matt Tait wrote: > > > >> Hi all, > >> > >>

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

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" pr

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

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 yo