3 ms·

Interesting approach, but doesn't using your product add another attack vector? Surely Enchanted's CDN will be a rich target for attackers. Full disclosure: I'

Interesting approach, but doesn't using your product add another attack vector? Surely Enchanted's CDN will be a rich target for attackers. Full disclosure: I'm in private beta with a product that periodically loads production sites and compares all executed JS to the last-known-good profile (usually from CI prior to deployment), and raises warnings if anything changes. We don't run in actual users' browsers, so we won't see malicious code as early as Enchanted, but you don't have to trust us.

jrpt 7y ago
For your first question, there's an optional hash you can add that locks the code to its known hash. Also, you can self-host everything if you like. The type of product it sounds like you're running is a scanner and scanners have a couple problems. First, there's cloaking: if the malware can detect that it's a scanner (usually pretty easily) then the malware doesn't activate. Second, the malware comes from trusted code that you already think is trusted, and that's a problem if you overlook something because it's trusted. By contrast, Enchanted Security would see it since it runs on every users' browser all the time.
- donaltroddyn 7y ago
  To be honest, if you can get clients to reliably use SRI, that's probably better protection than either of our products. Yeah, our product could be classed a scanner, but there's no (little) risk of cloaking, as the network request or JS loaded to work out whether we're a real user is enough by itself to raise the alarm. To pull it off, the attacker would have to compromise the host of a trusted resource, determine that we were a scanner from our network request alone, and serve to us the original resource. There's a few ways to help ensure that our network requests aren't easily recognised, which is part of our "secret sauce". Our approach does protect against the case where an attacker gets access to the client company's server and makes changes to the resources served, which can allow them to work around / selectively serve embedded snippets. The second problem you mention isn't an issue, as we don't trust hosts, only the hash of resources (the same idea as SRI).
  - jrpt 7y ago
    Depending on how the code is being served, cloaking is a big problem for scanners... if you think it's no risk you're probably overlooking the risk. Google put out a report on it and there's lots of papers on it and related topics like VM detection in browsers. You can use SRI for something like a specific version of jQuery, but not for most of the products people are relying on that have more dynamic functionality. SRI isn't practical for third party resources that are expected to change over time, which is actually a lot of third party resources. For example, a chat script like Intercom will change when someone from marketing makes a change that affects its frontend settings. This may be changing some text or coloring. So you can't pin it with SRI. In your case, if your product tells you that some marketing script you're using changed hashes, how would you know whether that was a valid change or whether an attacker introduced malware?
    - donaltroddyn 7y ago
      > Depending on how the code is being served, cloaking is a big problem for scanners... if you think it's no risk you're probably overlooking the risk. Google put out a report on it and there's lots of papers on it and related topics like VM detection in browsers. Almost all bot/automated test/scanner detection relies on JS in the browser, which is too late to avoid triggering an alert with our approach. The attacker would have to identify us from our network request to load the compromised resource alone, for which we have (so far) effective mitigations. > In your case, if your product tells you that some marketing script you're using changed hashes, how would you know whether that was a valid change or whether an attacker introduced malware? We'll alert the client company for any resource that's changed - you can't trust that any third party resource change is okay, especially if the reputational and legal cost of a breach can exceed 10's or 100's of millions. Most third party code from reputable companies, including tracking tagging, doesn't change that often, and client security/ops teams tend to be horrified by the ones that do. Each time some third party silently replaces code that they're serving, it introduces new opportunities for bugs, breakages, and attacks. I really disagree with you about SRI. SRI isn't sufficient to prevent all client-side attacks, but it is very effective, and when enterprise customers demand it, third-party services almost always find a way to support it.

jrpt 7y ago

For your first question, there's an optional hash you can add that locks the code to its known hash. Also, you can self-host everything if you like. The type of product it sounds like you're running is a scanner and scanners have a couple problems. First, there's cloaking: if the malware can detect that it's a scanner (usually pretty easily) then the malware doesn't activate. Second, the malware comes from trusted code that you already think is trusted, and that's a problem if you overlook something because it's trusted. By contrast, Enchanted Security would see it since it runs on every users' browser all the time.

donaltroddyn 7y ago
To be honest, if you can get clients to reliably use SRI, that's probably better protection than either of our products. Yeah, our product could be classed a scanner, but there's no (little) risk of cloaking, as the network request or JS loaded to work out whether we're a real user is enough by itself to raise the alarm. To pull it off, the attacker would have to compromise the host of a trusted resource, determine that we were a scanner from our network request alone, and serve to us the original resource. There's a few ways to help ensure that our network requests aren't easily recognised, which is part of our "secret sauce". Our approach does protect against the case where an attacker gets access to the client company's server and makes changes to the resources served, which can allow them to work around / selectively serve embedded snippets. The second problem you mention isn't an issue, as we don't trust hosts, only the hash of resources (the same idea as SRI).
- jrpt 7y ago
  Depending on how the code is being served, cloaking is a big problem for scanners... if you think it's no risk you're probably overlooking the risk. Google put out a report on it and there's lots of papers on it and related topics like VM detection in browsers. You can use SRI for something like a specific version of jQuery, but not for most of the products people are relying on that have more dynamic functionality. SRI isn't practical for third party resources that are expected to change over time, which is actually a lot of third party resources. For example, a chat script like Intercom will change when someone from marketing makes a change that affects its frontend settings. This may be changing some text or coloring. So you can't pin it with SRI. In your case, if your product tells you that some marketing script you're using changed hashes, how would you know whether that was a valid change or whether an attacker introduced malware?
  - donaltroddyn 7y ago
    > Depending on how the code is being served, cloaking is a big problem for scanners... if you think it's no risk you're probably overlooking the risk. Google put out a report on it and there's lots of papers on it and related topics like VM detection in browsers. Almost all bot/automated test/scanner detection relies on JS in the browser, which is too late to avoid triggering an alert with our approach. The attacker would have to identify us from our network request to load the compromised resource alone, for which we have (so far) effective mitigations. > In your case, if your product tells you that some marketing script you're using changed hashes, how would you know whether that was a valid change or whether an attacker introduced malware? We'll alert the client company for any resource that's changed - you can't trust that any third party resource change is okay, especially if the reputational and legal cost of a breach can exceed 10's or 100's of millions. Most third party code from reputable companies, including tracking tagging, doesn't change that often, and client security/ops teams tend to be horrified by the ones that do. Each time some third party silently replaces code that they're serving, it introduces new opportunities for bugs, breakages, and attacks. I really disagree with you about SRI. SRI isn't sufficient to prevent all client-side attacks, but it is very effective, and when enterprise customers demand it, third-party services almost always find a way to support it.