Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87207
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain craigfrancis.co.uk designates 74.125.82.52 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <872B5165-6A87-4024-BB9D-514E83A22E6F@craigfrancis.co.uk>
Date: Fri, 17 Jul 2015 14:00:18 +0100
To: internals@lists.php.net
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: [RFC] String Types (security)
From: craig@craigfrancis.co.uk (Craig Francis)

Hi,

I'm looking at creating an RFC to address security issues that relate to =
poor string handling / escaping, such as SQL-Injection, XSS, etc.

Considering these are still major issues on the OWSP Top 10, we need to =
do more to mitigate them.

For example, an inexperienced programmer can easily create an XSS =
vulnerability with:

echo '<p>Searched for: ' . $_GET['q'] . '</p>';

I'm proposing that we extend the error_reporting of E_NOTICE, so that =
PHP itself can tell the developer when they have made a mistake.

And this will work well with existing SQL prepared statements, ORMs, =
templating systems, etc.

--------------------------------------------------

So PHP assigns a "type" to every string (this must be done by PHP =
itself, "value objects" still allow mistakes).

This defaults to the "plain" string type... for example, values that =
come from GET/POST/COOKIE, the database, file_get_contents(), etc.

When a string is passed though htmlentities(), the returned string has a =
"html" type.

When a string is passed though pg_escape_literal(), the returned string =
has an "sql" type.

There are more :-)

---

When an "sql" string is concatenated with an "sql" string, it would =
result in an "sql" string.

When a hard coded string in the PHP script itself is concatenated with =
an "sql" string, the result is an "sql" string.

But if you concatenate an "sql" string with a "plain" string, then PHP =
will raise a Notice.

---

Then functions such as mysqli_query() can test the provided string =
type... e.g. a "plain" string can raise a Notice.

This could extend the PHP7 scalar type hints, so methods could check the =
string types as well.

And likewise, anything that is sent as output (e.g. echo/print) would be =
tested against a configurable output type, which defaults to "html".

--------------------------------------------------

There are a couple of edge cases (with solutions)... but does this =
interest anyone?

Craig=