4 ms·

Am I wrong in thinking this is similar to the below code? <?php include("https://otherdomain.com/somephpcode.txt https://otherdomain.com/somephpcode.txt"); ?>

Am I wrong in thinking this is similar to the below code? <?php include("https://otherdomain.com/somephpcode.txt https://otherdomain.com/somephpcode.txt"); ?> PHP got ridiculed for years for having this sort of stuff available (even if off by default eventually).

deleted 5y ago
[deleted]
markstos 5y ago
Sounds like it. These days, HTML is trusting JavaScript that's loaded from all over the place already. A "secure" database hosting service loads assets from 20 different domains on their login page. Loading code from remote domains can be abused and mis-used in any language. In this case, I think it's considered a "feature" because code was already being loaded remotely with NPM, who in turn got the code from the original author. Now you can load the code directly from the author. So instead of trusting both the author and NPM, you only need to trust the author. This could be considered a reduction in your attack surface area, and it's definitely helping with the NPM registry being a single-point-of-failure in the Node.js ecosystem.
- dangerface 5y ago
  Npm won't allow you to require remote code from a user touched variable like the below. myRemoteLib = require(userGeneratedVariable)
  - eyelidlessness 5y ago
    I don’t know where you got that idea. NPM doesn’t have any say in CJS (or ESM) module resolution other than that they conform to relevant aspects of it. Node and other implementers of those module systems absolutely do allow dynamic require/import.
nexuist 5y ago
PHP got ridiculed for years for doing all the things all the other popular frameworks are coming around to support now. Server side rendering is particularly hilarious because it's like: oh, you're compiling .jsx files to .html now? Cool....can't imagine anyone ever did that before...
- jchw 5y ago
  CGI script style languages like PHP are only superficially similar to SSR.
  - nexuist 5y ago
    Is it though? I remember injecting <php> tags in the middle of JS scripts to fill out variable values. I'm sure someone somewhere was using PHP to inject conditionally dependent JavaScript onto their page. Is that much different from Next rendering a React component on the backend, injecting it into HTML, and then injecting its corresponding component state into the JS bundle?
    - jchw 5y ago
      ...Yes? For one thing, PHP code runs inside the process of rendering HTML, but JS SSR runs under the process of a React JS app, running in Node. That alone is an absolutely massive difference. Not just on a technical level; React JSX also doesn't have nearly as much hazards surrounding HTML sanitization, for example, because JSX is a DSL that protects inputs with proper sanitization by default, among other practical differences. Another difference is that SSR is more flexible than for runtime environment; it is very often used as a static compilation technique, where it is run as a compilation step for a static site, but either way, it is not married to any specific runtime model, whereas PHP pretty much is (for now.) A closer analogue to what React does would be comparing XHP[1] to JSX, but even that misses the isomorphic aspect of a SPA with SSR, which is almost the entire value proposition, because it allows you to only need to write your component code once while reusing the same render cycle at browser runtime. It should be pretty evident that PHP-style CGI scripting is not ideal given that even early on many PHP apps moved to using template systems like Smarty and never actually embedding HTML directly into PHP code. [1]: https://github.com/phplang/xhp https://github.com/phplang/xhp
that_guy_iain 5y ago
This was literally my first thought, the return of Remote File Injections.

deleted 5y ago

[deleted]

markstos 5y ago

Sounds like it. These days, HTML is trusting JavaScript that's loaded from all over the place already. A "secure" database hosting service loads assets from 20 different domains on their login page. Loading code from remote domains can be abused and mis-used in any language. In this case, I think it's considered a "feature" because code was already being loaded remotely with NPM, who in turn got the code from the original author. Now you can load the code directly from the author. So instead of trusting both the author and NPM, you only need to trust the author. This could be considered a reduction in your attack surface area, and it's definitely helping with the NPM registry being a single-point-of-failure in the Node.js ecosystem.

dangerface 5y ago
Npm won't allow you to require remote code from a user touched variable like the below. myRemoteLib = require(userGeneratedVariable)
- eyelidlessness 5y ago
  I don’t know where you got that idea. NPM doesn’t have any say in CJS (or ESM) module resolution other than that they conform to relevant aspects of it. Node and other implementers of those module systems absolutely do allow dynamic require/import.

nexuist 5y ago

PHP got ridiculed for years for doing all the things all the other popular frameworks are coming around to support now. Server side rendering is particularly hilarious because it's like: oh, you're compiling .jsx files to .html now? Cool....can't imagine anyone ever did that before...

jchw 5y ago
CGI script style languages like PHP are only superficially similar to SSR.
- nexuist 5y ago
  Is it though? I remember injecting <php> tags in the middle of JS scripts to fill out variable values. I'm sure someone somewhere was using PHP to inject conditionally dependent JavaScript onto their page. Is that much different from Next rendering a React component on the backend, injecting it into HTML, and then injecting its corresponding component state into the JS bundle?
  - jchw 5y ago
    ...Yes? For one thing, PHP code runs inside the process of rendering HTML, but JS SSR runs under the process of a React JS app, running in Node. That alone is an absolutely massive difference. Not just on a technical level; React JSX also doesn't have nearly as much hazards surrounding HTML sanitization, for example, because JSX is a DSL that protects inputs with proper sanitization by default, among other practical differences. Another difference is that SSR is more flexible than for runtime environment; it is very often used as a static compilation technique, where it is run as a compilation step for a static site, but either way, it is not married to any specific runtime model, whereas PHP pretty much is (for now.) A closer analogue to what React does would be comparing XHP[1] to JSX, but even that misses the isomorphic aspect of a SPA with SSR, which is almost the entire value proposition, because it allows you to only need to write your component code once while reusing the same render cycle at browser runtime. It should be pretty evident that PHP-style CGI scripting is not ideal given that even early on many PHP apps moved to using template systems like Smarty and never actually embedding HTML directly into PHP code. [1]: https://github.com/phplang/xhp https://github.com/phplang/xhp

that_guy_iain 5y ago

This was literally my first thought, the return of Remote File Injections.