First class markup like JSX or XHP

[KorvinSzanto]

For a language that by-and-large supports the web, PHP has pretty limited support for markup and proper sanitization. It'd be amazing if PHP had support for XHP style markup and provided context-specific sanitized output by default:

<?php
// Using base elements

$user = $session->getLoggedInUser();
$avatar = <img src={$user->getAvatarUri()} />;
$usernameInput = <input id='username' name='username' value={$_POST['username']} />

$usernameForm = <form>
    <div class='avatar'>{$avatar}</div>
    <label for='username'>Username:</label>
    {$usernameInput}
</form>;

echo $usernameForm->render();

<?php
// Declaring a custom element

class ConfirmDialog extends \Element
{
    public function __construct(
        public readonly string $prompt,
        public readonly ?string $acceptString = 'Okay',
        public readonly ?string $cancelString = 'cancel'
    ) {}

    public function render()
    {
        return <div class='dialog'>
            <a class='close-icon' onclick='close()'>x</a>
            <strong>{$this->prompt}</strong>
            ($this->acceptString !== null && <button onclick='accept()'>{$this->acceptString}</button>)
            ($this->cancelString !== null && <button onclick='close()'>{$this->cancelString}</button>)
        </div>;
    }
}

// Using a custom element in a template file

namespace Foo;

use ConfirmDialog;

$prompt = $prompt ?? 'Confirm?';

return <ConfirmDialog prompt={$prompt} />;

Outputting without sanitization could use syntax or a type to manage:

• <div>{{$html}}</div>
• <div>{Element::unsafe($html)}

I believe having support for this sort of thing in PHP would lead to a huge reduction in XSS vulnerabilities introduced.

[pronskiy]

I'm not familiar with XHP, does the https://github.com/phplang/xhp extension cover your needs?

[KorvinSzanto]

That extension stopped being supported around the time hack fully split from PHP. It would be viable if it were supported and had support for the latest PHP versions though.

XHP is still supported in hack lang, just not in a way that is usable in PHP and JSX is also similar prior art

In my opinion this is something that should be supported either by core syntax, or by a default extension like ext-dom just for the benefit of eliminating XSS.

[pronskiy]

I found some discussions of this topic before https://externals.io/message/91797.

I have two followup questions:

• That extension has only two open issues. Besides compatibility, does it have any known problems? Maybe just making it compatible would be enough?
• It seems like the mainstream PHP community is fine with current templating systems like Blade/Twig. What do you think?

[KorvinSzanto]

In my opinion this is something that should be bundled into PHP to help eliminate XSS in the ecosystem. Extensions are great for proprietary projects that have limited compliance requirements, but it's tough to get people to use your open source project if it requires phpizing a github repo to get started.

To answer your questions:

1. I don't know if it has more issues. To me it's not really helpful if it's not bundled (until we can composer require extensions)
2. I think the mainstream php ecosystem was also fine using the mysql extension without prepared statements, but we recognized that we needed to replace it for modern feature support, maintainability, and security. In my mind adding a vanilla way to create safe HTML by default doesn't preclude the use of other templating engines if someone chooses in the same way JS still has handlebars, it just makes PHP a safer language by default and thereby makes the web as a whole safer.

To me it just makes sense for PHP, the language that likely generates the most HTML (along with xss vulnerabilities), to have first class support for generating safe HTML.

[OO00O0O]

There was proposal for https://wiki.php.net/rfc/is_literal that would solve this problem in general and universal way without adding another language(html/xml) parser.

[craigfrancis]

literal-string is available via Psalm and PHPStan, and matches the LiteralString type in Python (docs, PEP, example). While it's similar to taint checking, it is not the same (taint is flawed, and creates a false sense of security).

The LiteralString technique solves the problem by simply identifying "developer defined strings" (i.e. does not contain any user input, and therefore it can be trusted to completely prevent XSS, SQLi, etc)... it's up to libraries to take these trusted LiteralString values (e.g. a HTML template), and do context-aware escaping, parameterising, etc.

Unfortunately it's the escaping that gets complicated (and Blade/Twig cause problems because they do not do this, likewise pretty much all database abstractions); and it's why I don't think PHP should do escaping in core; e.g. what would happen with <a href="{$url}">, because in basic XML that would be fine with escaping the 5 special characters (", ', <, >, and &), but it must not allow javascript: URLs in HTML (or XHTML).

One other option, have a look at Tagged Templates, along with the isTemplateObject (not implemented in JS) that might work... and please note, this is different from Template Literals (which have caused so many XSS vulnerabilities, because developers don't think they need to escape values).

[Crell]

I don't think is_literal et al is at all related to the core question here, which is about having a native syntax for HTML that can be engine-optimized.

[craigfrancis]

@Crell LiteralString is a simpler solution that works with more than HTML (in XML form), e.g. SQL and CLI (you know how easy it is to make mistakes, especially with things like Doctrine QueryBuilder, and PSR-3 LoggerInterface)... but I'm also noting that context based escaping is really hard, and I doubt it would be added into PHP core (especially when variables are within inline JavaScript, CSS, SVG, MathML, etc).

[OO00O0O]

Thank you @craigfrancis ! It seems I was missing a lot of information on this topic.

[craigfrancis]

Thanks @OO00O0O; and to say I've been been a bit obsessed by it for years, is perhaps an understatement :-)

[Crell]

One advantage of a native/bundled syntax over the existing user-space solutions is the compiler can handle compilation and syntax validation, and translate it into more mundane and faster opcodes. Assuming we trust that code, anyway.

[craigfrancis]

In your first example, you have:

$usernameInput = <input id='username' name='username' value={$_POST['username']} />

Note the lack of quote marks aground the variable.

Are the variables simply passed though htmlspecialchars()?

If so, should the author be required to quote the attribute? or would PHP add the quotes marks automatically (single or double)? or would PHP need to do HTML attribute based escaping (e.g. spaces to %20)? as this could become a problem:

$_POST['username'] = 'abc onclick=evil()';

<input id='username' name='username' value=abc onclick=evil() />

And what happens with:

$_POST['url'] = 'javascript:evil()';

$link = <a href={$_POST['url']}>link</a>;

And what happens with:

$_POST['a'] = 123;
$_POST['a'] = '1; evil()';

$link = "<script>a = {$_POST['a']};</script>";

And these are the basic ones, wait until you start looking at what happens with complex parsing... e.g. CSS, Mutation XSS, the complexities of SVG and MathML (see mglyph and malignmark).

Also, what happens if $_POST['username'] is not defined? As that's kinda NULL, and PHP 8.1 deprecated NULL being passed to functions like htmlspecialchars(), and intends to make this a fatal error in PHP 9 (which might cause some problems), so I assume this will also cause fatal errors?

[KorvinSzanto]

Are the variables simply passed though htmlspecialchars()?

The variables are escaped, yes. Not by being passed to htmlspecialchars and not without context specific sanitization. For example, the sanitization needed for '"> is different depending on if you're an attribute key, a attribute value, a tag, or text content.

If so, should the author be required to quote the attribute

The distinction between '' and {} syntax in prior art is due to compiler optimizations I believe. '' only deals with strings while {} allows more complex expressions. As far as how we'd explicitly not escape an attribute value or text content I don't really know. I don't necessarily think that using the ' vs " distinction in PHP is a bad idea, I just don't think it works as cleanly as we'd like given that the text content within tags can't use the same paradigm. What might be better is using a value object like Raw::value($myHTML) or some other extra syntax.

However we do it, the answer is "yes" the author is required to use the special extra syntax that will allow their string to be unsanitized, but by default everything is sanitized.

And what happens with: <a href={$_POST['url']}>

There's a difference between sanitizing for breakout XSS like <a title="<?= $_POST['url'] ?>"> where an attacker sends "><script src='...'></script> and what you're saying where a developer is putting user submitted content directly into a field that supports extra functionality like javascript:.... I think we can definitely solve both, but I'd argue that we gain a huge amount and solve for the majority of XSS cases in the wild by simply solving the former.

That said, since we would actually be using a lexer to parse this stuff we can handle cases like this on a case-by-case. For example, we could disallow the use of javascript: urls in certain attributes entirely unless a flag is passed when the HTML is converted to a string like $html->render(HTML_ALLOW_JAVASCRIPT_URLS), or unless special syntax is used like <a allow-js:href="...">

---

In general all of your questions center around string interpolation and the types of vulnerabilities we see because of string interpolation. We get away from these types of issues for the most part by avoiding string interpolation entirely and instead using actual syntax to build out HTML.

[craigfrancis]

While I like the theory, I'm fairly sure the implementation is going to get far too complicated.

For reference, I tried to make Taint Checking work (recording the different contexts), but it got too complicated, and I gave up when I saw Preventing Security Bugs through Software Design, and the isTemplateObject feature for "Distinguishing strings from a trusted developer from strings that may be attacker controlled"... that's when I realised it's so much easier for the programming language to identify when a string is a LiteralString, and then have easily updated libraries, that focus on one area, using their specific domain knowledge (e.g. HTML, JS, CSS, SQL, CLI)... and different libraries can provide different solutions with this (e.g. ORM vs QueryBuilder for SQL).

[KorvinSzanto]

I'm not really sure I understand what you're thinking needs to be complicated, can you be more specific about what you think is prohibitively complicated about writing / integrating with an existing HTML parser?

It sounds like you're thinking that it's challenging to determine whether a string is intending a value to be a tag, an attribute key, an attribute value, or content and I don't really see why. We're talking about a lexer that understands the syntax, if you provide it syntax that it doesn't understand you'll simply get a parse error.

If you're more saying we don't know when we need to sanitize, the answer is simple there too; we always sanitize unless the developer uses the special "unsafe" syntax. It really isn't that complicated, I've done it (albeit without the html-like syntax sugar and with much worse performance than we could get in the core) in my PHPX library you can see how with this solution there isn't any way for an injected string to break out of an attribute value, or of string content. PHP itself can do this a lot more performantly and with the nice syntax sugar we see in things like JSX or XHP.

[craigfrancis]

I'm more talking about how XSS can come in multiple forms, where context is important. While this suggestion is simpler than DOMDocument, it still only solves the same small set of XSS issues that DOMDocument solves:

$url = 'javascript:alert()'; // From user

echo $x->render($x->a(href: $url, c: 'Website')); // Unsafe XSS

$link = <a href={$url}>Website</a>; // Unsafe XSS
echo $link->render();

$doc = new DOMDocument();
$p = $doc->createElement('a', 'Website');
$p->setAttribute('href', $url); // Unsafe XSS
$doc->appendChild($p);
echo $doc->saveHTML();

// <a href="javascript:alert()">Website</a>

Or how about <script>id = {$id};</script>, <button onclick={$action}>?

I'm not against this suggestion, but we have to be careful, I don't want developers thinking it solves XSS (creating a false sense of security).

[KorvinSzanto]

One thing that has come up is how we could go beyond preventing XSS into actually managing the types and sources of content that are allowed and one thought I had that I'd like to get out is that content security policies exist for this very reason.
What if as part of this we also added classes for creating and managing CSPs and used that to allow certain things:

$policy = \PhpMl\Csp::()->sources(default: 'self', script: 'https://somesite.com')->throwOnFailure();
$policy = \PhpMl\Csp::()->sources(default: 'self')->removeOnFailure();

// Globally
\PhpMl\PhpMl::setGlobalPolicy($policy);

// With a specific block
$myLink = 'javascript:doSomething()';
$content = <a href={$myLink}></a>

// Echo with global policy
echo $content; // <a></a>

// Echo rendered with specific policy
echo $content->renderWithPolicy($policy->allowUnsafeInline()); // <a href='javascript:doSomething()'>

This does increase the potential barrier for entry a bit, but I think this could also be a great thing for a web language to have.

[OO00O0O]

Twig has SecurityPolicy too. It helps control what data/functions from what objects are allowed. Additionally it escapes everything unless you use raw filter.

So what I think in general: no matter how many security solutions/hardening's you add you still have to know what you are doing.

[KorvinSzanto]

The goal isn't to make it so that developers don't have to think about what they are doing. The goal is to give developers a safe performant way to output html by default. I don't suggest this will prevent all XSS, this just puts us in a position where we're not unsafe by default like we are today.

[dakur]

Just a side-note: latte templating system has strong context-aware escaping functionalities. Not an ad, just to be aware of various user-land solutions :)

[KorvinSzanto]

DOMDocument (and by extension PHPX) can also generate safe valid HTML by default in the way I'm describing, but all three (and all PHP level template engines) suffer from being far far slower than either PHP parse times or echo with string concatenation times. The only way to get the speeds we want for this is to have the parser in the PHP core, or in a bundled extension.
You can get closer to core speeds if you compile your templates into string concatenation like phpx-compile does, but even that is:

1. Far slower than a parser in the core could be
2. Runs the risk of edge cases that either circumvent protection or prevent rendering all-together
3. Requires a compilation step that doesn't quite jive with the typical PHP ethos and isn't exactly easily readable

[Crell]

Nearly all user-space template systems have a compile step that produces generated classes whose contents are, basically, string concatenation. That part is a solved problem. What a core implementation would offer is a dedicated syntax that could be mixed in with PHP code; basically a way way more robust alternative to using heredoc strings to generate HTML. The tradeoff being that all the security checking et al is happening in C, which is harder to modify.

Whether that's a good tradeoff or not is an open question.

[KorvinSzanto]

I'd imagine building the strings and sanitizing in the Core would still beat string concatenation and htmlspecialchars calls, but I don't really know for sure