9 ms·

My main problem with this is that they punted the integrity check work down the line. If this had been implemented as something akin to the integrity HTML attr

My main problem with this is that they punted the integrity check work down the line. If this had been implemented as something akin to the integrity HTML attribute, e.g.: express = require( 'https://my_local_repo.tld/express/current/4.17.1', 'sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC' ) It would be vastly superior. I'd go so far as to require it without an additional --unsafe-import type flag. However, I think they did not do this because the import of dependencies then comes into question. IMO this feature should not have been added until developers could guarantee the expected integrity hash matches. We've seen time and again what will happen now is hundreds of blog posts talking about this new feature, none of which will mention the integrity hashing functionality (because it's not there). When it does eventually get added, those posts will be the most popular anyone can find, and thus new users will end up using those eventually-wrong posts and implementing things in a less-secure way. Huge disservice to the developer community.

sneak 5y ago
It's rubygems all over again. I think only Nix and Go are doing dependencies right (cryptographically verified) these days. One upside is that it's https-only, which does include authentication, provided that you trust the holder of the certificate for my_local_repo.tld (in your example) to serve you the right files.
- francislavoie 5y ago
  Don't forget about PHP. Composer is one of the best package managers around.
jdcaron 5y ago
Exactly, this kind if import without a hash validation is a big no for security reasons (unless you 100% trust your import source). This feature exists on the browser side with the script element: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- lukifer 5y ago
  > you 100% trust your import source This is a perfect circumstance for the adage "trust but verify".
zackmorris 5y ago
Came here to say the same thing. In fairness, this isn't specifically Node's fault. I feel that a mistake was made early in the SPA/mobile craze a decade ago, where the web should have used subresource integrity (SRI) everywhere: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... But instead went with less-secure Cross-Origin Resource Sharing (CORS): https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS These operate at different levels of abstraction. SRI is mathematically strong, whereas CORS requires a bunch of hoops and mostly just gets in the way. I could understand an argument for SRI+CORS, but using CORS alone sets off alarm bells in my head.
- spankalee 5y ago
  CORS and SRI are just completely different. CORS exists to allow requests that would be banned under the Same Origin Policy, most of which have dynamic responses and could not integrate with SRI at all.
  - horsawlarway 5y ago
    I agree - I'm not really sure what the parent poster is on about. CORS and SRI are orthogonal, and designed to solve entirely different problems. CORS is primarily focused on removing csrf (cross site request forgery) vulnerabilities. It doesn't really care at all about what resources you pass around (or their integrity) it only cares about ensuring that the request is coming from a known and allowed origin.
    - merb 5y ago
      > CORS is primarily focused on removing csrf (cross site request forgery) vulnerabilities basically CORS gives you zero defense against csrf. (ok, not zero, but also not much)
      - horsawlarway 5y ago
        This just isn't true. I don't consider request forgery to just be side-effect based (the classic example of a bank form post). I'm including any request that leaks data to a site based on cookies present only on the client (forged authenticated request). SOP/CORS was the foundation that allowed CSRF tokens to even work. (No SOP/CORS? Just request the form with the csrf token first, parse with js, append to next request) I guess you could say SOP is really the protecting force here, but CORS only exists because strict SOP broke a LOT of stuff. Enter trust zones in IE, and then CORS. SameSite now mostly tackles this by fixing the root issue with the cookie jar.
jeroenhd 5y ago
But what would be the point? Why would you load code over HTTPS if you're going to make it static anyway? If the code can't change dynamically, then you might as well put it next to the JS file on the filesystem. I think this is a terrible idea that can only end in misery but I can understand why they don't add integrity validation by default.
- calvin 5y ago
  It’s a feature that Deno has and that works on the web (ESM imports from URLs). People have use cases for it and they want it. That’s not to say it’s secure by default of course but the demand is there.
  - user-the-name 5y ago
    There's always demand for completely insecure features. That doesn't mean you should add them.
- BeefWellington 5y ago
  HTTPS doesn't magically protect you from the content of the package changing. They are different security mechanisms designed to defend against different threats. One answers the question: Was this the correct server I got this package from? The other answers the question: Does the package's hash match what I expect in my code? As to why you would want this, I've worked on several projects that take advantage of some things that pulling dependencies only from a local repository can give you. Take the recent Log4J vuln as an example. Immediately on seeing that vulnerability, I disable the JAR file, causing builds to fail wherever that dependency exists until the updated one is added as a dependency and used. From experience having to do dependency analysis on an old toothy codebase, it's sometimes simpler and more accurate to just let everything break and fix the breaking spots.
  - jeroenhd 5y ago
    I understand that HTTPS doesn't protect you, and that's the reason why you'd normally add a hash. If your goal is to make the build fail for vulnerable applications, you can run a local repository with upstream proxying functionality like Nexus Repository and kill the package there. This won't let you kill production (but why would you want to kill it this way?) but it'll give you the same benefit without risking remote code execution.
__s 5y ago
There's already syntax to implement it with imports through import assertions: https://v8.dev/features/import-assertions https://v8.dev/features/import-assertions
eyelidlessness 5y ago
I’m also concerned about resource integrity, and that was my immediate concern initially when I heard of Deno. But it’s important to also recognize that it’s quite a bit more complex than a hash for the requested module. Because of course that hash has nothing to say about the integrity of transitive imports. I’m willing to give Node the benefit of the doubt that this will remain experimental with appropriate warnings until resource integrity is addressed to some reasonable level of confidence. I’m also glad to see it being a first party concern, especially given that it’s historically been/still is a much higher risk factor as both: - delegated to their ESM loader API, which is incredibly difficult to get right, despite the API itself being deceptively simple - a hilariously insecure example in their docs for same

sneak 5y ago

It's rubygems all over again. I think only Nix and Go are doing dependencies right (cryptographically verified) these days. One upside is that it's https-only, which does include authentication, provided that you trust the holder of the certificate for my_local_repo.tld (in your example) to serve you the right files.

francislavoie 5y ago
Don't forget about PHP. Composer is one of the best package managers around.

jdcaron 5y ago

Exactly, this kind if import without a hash validation is a big no for security reasons (unless you 100% trust your import source). This feature exists on the browser side with the script element: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

lukifer 5y ago
> you 100% trust your import source This is a perfect circumstance for the adage "trust but verify".

zackmorris 5y ago

Came here to say the same thing. In fairness, this isn't specifically Node's fault. I feel that a mistake was made early in the SPA/mobile craze a decade ago, where the web should have used subresource integrity (SRI) everywhere: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... But instead went with less-secure Cross-Origin Resource Sharing (CORS): https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS These operate at different levels of abstraction. SRI is mathematically strong, whereas CORS requires a bunch of hoops and mostly just gets in the way. I could understand an argument for SRI+CORS, but using CORS alone sets off alarm bells in my head.

spankalee 5y ago
CORS and SRI are just completely different. CORS exists to allow requests that would be banned under the Same Origin Policy, most of which have dynamic responses and could not integrate with SRI at all.
- horsawlarway 5y ago
  I agree - I'm not really sure what the parent poster is on about. CORS and SRI are orthogonal, and designed to solve entirely different problems. CORS is primarily focused on removing csrf (cross site request forgery) vulnerabilities. It doesn't really care at all about what resources you pass around (or their integrity) it only cares about ensuring that the request is coming from a known and allowed origin.
  - merb 5y ago
    > CORS is primarily focused on removing csrf (cross site request forgery) vulnerabilities basically CORS gives you zero defense against csrf. (ok, not zero, but also not much)
    - horsawlarway 5y ago
      This just isn't true. I don't consider request forgery to just be side-effect based (the classic example of a bank form post). I'm including any request that leaks data to a site based on cookies present only on the client (forged authenticated request). SOP/CORS was the foundation that allowed CSRF tokens to even work. (No SOP/CORS? Just request the form with the csrf token first, parse with js, append to next request) I guess you could say SOP is really the protecting force here, but CORS only exists because strict SOP broke a LOT of stuff. Enter trust zones in IE, and then CORS. SameSite now mostly tackles this by fixing the root issue with the cookie jar.

jeroenhd 5y ago

But what would be the point? Why would you load code over HTTPS if you're going to make it static anyway? If the code can't change dynamically, then you might as well put it next to the JS file on the filesystem. I think this is a terrible idea that can only end in misery but I can understand why they don't add integrity validation by default.

calvin 5y ago
It’s a feature that Deno has and that works on the web (ESM imports from URLs). People have use cases for it and they want it. That’s not to say it’s secure by default of course but the demand is there.
- user-the-name 5y ago
  There's always demand for completely insecure features. That doesn't mean you should add them.
BeefWellington 5y ago
HTTPS doesn't magically protect you from the content of the package changing. They are different security mechanisms designed to defend against different threats. One answers the question: Was this the correct server I got this package from? The other answers the question: Does the package's hash match what I expect in my code? As to why you would want this, I've worked on several projects that take advantage of some things that pulling dependencies only from a local repository can give you. Take the recent Log4J vuln as an example. Immediately on seeing that vulnerability, I disable the JAR file, causing builds to fail wherever that dependency exists until the updated one is added as a dependency and used. From experience having to do dependency analysis on an old toothy codebase, it's sometimes simpler and more accurate to just let everything break and fix the breaking spots.
- jeroenhd 5y ago
  I understand that HTTPS doesn't protect you, and that's the reason why you'd normally add a hash. If your goal is to make the build fail for vulnerable applications, you can run a local repository with upstream proxying functionality like Nexus Repository and kill the package there. This won't let you kill production (but why would you want to kill it this way?) but it'll give you the same benefit without risking remote code execution.

__s 5y ago

There's already syntax to implement it with imports through import assertions: https://v8.dev/features/import-assertions https://v8.dev/features/import-assertions

eyelidlessness 5y ago

I’m also concerned about resource integrity, and that was my immediate concern initially when I heard of Deno. But it’s important to also recognize that it’s quite a bit more complex than a hash for the requested module. Because of course that hash has nothing to say about the integrity of transitive imports. I’m willing to give Node the benefit of the doubt that this will remain experimental with appropriate warnings until resource integrity is addressed to some reasonable level of confidence. I’m also glad to see it being a first party concern, especially given that it’s historically been/still is a much higher risk factor as both: - delegated to their ESM loader API, which is incredibly difficult to get right, despite the API itself being deceptively simple - a hilariously insecure example in their docs for same