XSLT is being exploited right now for security vulnerabilities, and there is no solution on the horizon.
The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators.
You imagine that XSLT is more secure but it’s not. It’s never been. Even pure XSLT is quite capable of Turing-complete tomfoolery, and from the beginning there were loopholes to introduce unsafe code.
As they say, security is not a product, it’s a process. The process we have for existing browser technologies is better. That process is better because more people use it.
But even if we were to try to consider the technologies in isolation, and imagine a timeline where things were different? I doubt whether XML+XSLT is the superior platform for security. If it had won, we’d just have a different nightmare of intermingled content and processing. Maybe more stuff being done client-side. I expect that browser and OS manufacturers would be warping content to insert their own ads.
>You imagine that XSLT is more secure but it’s not. It’s never been. Even pure XSLT is quite capable of Turing-complete tomfoolery, and from the beginning there were loopholes to introduce unsafe code.
> The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators.
Yes, they also have much more vulnerabilities, because browsers are JIT compiling JS to w+x memory pages. And JS continues to get more complex with time. This is just fundamentally not the case with XSLT.
We're comparing a few XSLT vulnerabilities to hundreds of JIT compiler exploits.
While JIT exploits represent a large share of vulnerabilities in JS engines, there are enough other classes of vulnerabilities that simply turning JIT off is not sufficient. (The same goes for simply turning JS off, the Web browser internal is complex enough even without JS.)
Turning off the JIT eliminates an entire class of vulnerabilities just by nature of how the JIT works.
Ironically, JIT JS is much more susceptible to buffer overflow exploits than even the C code that backs XSLT - because the C code doesn't use w+x memory pages!
Yeah, turning off the JS or Web eliminates an entire class of vulnerabilities just by nature of how the JS or Web works (running untrusted code or showing untrusted content in the local machine) as well. That's no surprise.
The problem with JS isn't running untrusted code. That's easy and solved, we've been doing that for decades.
The problem with the JIT is compiling instructions, writing them to memory pages, and then executing them. This means your memory MUST be w+x.
This is really, really bad. If you have any way to write to memory unsafely, you can write arbitrary code and then execute it. Not arbitrary JS code. Arbitrary instructions. In the browsers process.
Even C and C++ does not have this type of vulnerability. At best, you can overwrite the return pointer with a buffer overflow and execute some code somewhere. But it's not 1995 anymore. I can't just write shell code in the buffer and then naively jump back into the buffer.
The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators.
You imagine that XSLT is more secure but it’s not. It’s never been. Even pure XSLT is quite capable of Turing-complete tomfoolery, and from the beginning there were loopholes to introduce unsafe code.
As they say, security is not a product, it’s a process. The process we have for existing browser technologies is better. That process is better because more people use it.
But even if we were to try to consider the technologies in isolation, and imagine a timeline where things were different? I doubt whether XML+XSLT is the superior platform for security. If it had won, we’d just have a different nightmare of intermingled content and processing. Maybe more stuff being done client-side. I expect that browser and OS manufacturers would be warping content to insert their own ads.