14 ms·

Cryptography and how to deal with man-in-the-middle attacks in JavaScript

71 points by zlatkov 5y ago

vbezhenar 5y ago
As long as server can serve any JS to any client, you can’t protect the data from the server.
- metafunctor 5y ago
  How is that? Lots of sites server their code to any client, but the data contained within the service is still secure.
  - q3k 5y ago
    'Javascript crypgography considered harmful' by tptacek (2011): https://archive.is/cyk2R https://archive.is/cyk2R tl;dr: In most cases browser JS crypto offers no advantages if you're trying to protect yourself from a rogue/compromised backend (eg. do e2e crypto on keys stored within localstorage before passing that over to the backend). That is because if the backend is compromised it can likely serve backdoored JS code that will leak secrets. This is not always true (eg. if you have multiple tiers of server backends within separate security domains), but almost always true for typical web monoliths.
- austincheney 5y ago
  It’s more complicated than that. For the most part the browser is a secure environment due to same origin policy. JavaScript in the browser can only send and receive from the domain from which that JavaScript is served, which means the JavaScript must come from your own domain or from a third party you trust. That trust is all from the perspective of the web server, though, which is orthogonal to the concerns of the end user. https://en.m.wikipedia.org/wiki/Same-origin_policy https://en.m.wikipedia.org/wiki/Same-origin_policy Browser extensions can bypass that though, which can expose you to malicious third parties.
  - tyingq 5y ago
    "Third party you trust" is tricky though. Like what happened with Backblaze. I don't think they really intended to scarf private data and exfiltrate it. Probably just a marketing person not knowing the implications. https://news.ycombinator.com/item?id=26536019 https://news.ycombinator.com/item?id=26536019
vaylian 5y ago
Interesting article. The built-in crypto module was new to me. This is actually a web standard: W3C: https://www.w3.org/TR/WebCryptoAPI/#Crypto-attribute-subtle https://www.w3.org/TR/WebCryptoAPI/#Crypto-attribute-subtle Mozilla docs: https://developer.mozilla.org/en-US/docs/Web/API/Crypto/subtle https://developer.mozilla.org/en-US/docs/Web/API/Crypto/subt...
- deepstack 5y ago
  Yeah it is what spawned these wire proton mail guys to encrypt on the client side.
  - deleted 5y ago
    [deleted]
- Jiocus 5y ago
  That's right. SubtleCrypto implementations are also fast, and available on mobile browsers. SubtleCrypto has some design choices to avoid common mistakes to reduce risk of vulnerable implementations[1], and as such it's aimed at the general developer. In my opinion, more developers should familiarize themselves with the tools and start looking at how they could implement security for their users. Processing highly critical data, such as PII or financial data, is not a requirement to use cryptography. Starting out, on could well be served by trying it in personal projects or even public data. This way, uncovering a vulnerable design could mean uncovering data that was already meant to be seen. Some will always argue it's the wrong or the dangerous thing to do, and they will never ship security to their users, I guess. – [1]: For example, the ReactDOM manipulations breaks this security model because SubtleCrypto will only interface with the DOM. There are additional libs as workarounds for these issues tho.
  - bawolff 5y ago
    > and as such it's aimed at the general developer. Its literally named subtle to discourage the general developer. In the https web model, there are very few situations where using this api actually makes sense. (Seriously, i challenge you to name one in a typical server-client web app)
qpie 5y ago
Interesting article. Thanks For Sharing
austincheney 5y ago
I would be hesitant to trust any cryptographic implementation coming from browser JavaScript. It’s not that I doubt or don’t trust the implementations from the browser vendors. I don’t trust the JavaScript developers executing them. This will provide a false sense of security implemented by persons lacking the education, training, and experience in security. Most software developers generally are not formally trained in security as a separate domain of knowledge. If you think security is something that can be passively acquired by reading a few APIs you are wrong. This is why employers require certifications for security work that software development otherwise doesn’t require. Cryptography was one of the most challenging domains/chapters in preparation for the CISSP. This is because real world cryptography implementations comprise various different cryptographic functions doing different things, such as: certificates, encryption, signatures, hashing, and so forth. The different crypto functions serve different purposes because they have different pros and cons. There isn’t some encryption blanket solution.
- kenniskrag 5y ago
  Can you recommend resources to learn security? Passed 3 security modules at my university and it feels like I know not much about secure engineering.
  - austincheney 5y ago
    Study first for the Security+ exam. That is the entry level security certification. It is much harder now than it used to be. You can find a lot of books and study material about it online. The gold standard is still CISSP for the corporate world. It is more of a managerial standard. The best study guide is the official course book: https://www.amazon.com/Certified-Information-Security-Professional-Official-ebook/dp/B07CG86947/ref=mp_s_a_1_4?dchild=1&keywords=cissp+coursebook&qid=1619696728&sr=8-4 https://www.amazon.com/Certified-Information-Security-Profes... https://en.m.wikipedia.org/wiki/Certified_Information_Systems_Security_Professional https://en.m.wikipedia.org/wiki/Certified_Information_System... The standard most prized by government and security researchers is GIAC from Sans. https://en.m.wikipedia.org/wiki/Global_Information_Assurance_Certification https://en.m.wikipedia.org/wiki/Global_Information_Assurance... To take the CISSP you have to apply for the exam because there are prerequisite criteria and the exam costs $700. Even still it only has around a 60% pass rate. The GIAC tests are supposed to be much harder and are extremely expensive. I passed the CISSP but have never taken any of the GIAC tests.
upofadown 5y ago
The article doesn't really explain the reason that MITM attacks are possible and how to prevent them in the first place. That is too bad because that part is pretty much at the end of the article.
benmmurphy 5y ago
The irony is when running their product on your site you are opening yourself up to an MITM attack from them. https://docs.sessionstack.com/docs https://docs.sessionstack.com/docs To be fair most SAAS javascript products (google analytics, stripe payments, etc) are going to work like this and they also offer an on-premise solution that presumably doesn't have this issue.
Asmod4n 5y ago
The main issue I still see with JavaScript crypto in a Website session is how you can verify the Code running in the Browser isn’t tempered with. I got no issues with it inside a browser extension, because a Website cannot change the Code running there, correct? What I mean is, an advertisement could simply override the crypto API and do whatever it wants with it.
- deepstack 5y ago
  one of my big issue of placing google analytics or some kind of font js on your web site!
- ianpurton 5y ago
  You generally wouldn't put adverts on a site that's dealing with security. You should also add subresource integrity as a defence in depth. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
  - Asmod4n 5y ago
    Oh, that looks cool.
  - goalieca 5y ago
    There’s many security sites that load tons of external scripts. My bank is one such example. Even if those third party trackers and such are trustworthy there remains the whole supply chain attack consideration.
    - hanniabu 5y ago
      Banks are never a good example for security. I know mine, which is a big name, still doesn't support OTP 2FA.
      - goalieca 5y ago
        Banks, Enterprise management, ... these are all guarding extremely valuable assets so i considered them security websites (not sure what is more security relevant other than the master email account we all have). They are written in a way that is hard to secure through CSP, disabling javascript, etc.
unnouinceput 5y ago
What year is it? 1990? Quote: "As people communicate over the internet, there’s a possibility that others can eavesdrop or even hijack information before it gets to the other parties involved." Let me tell you something buddy, if someone can decrypt->modify->encrypt undetected your communications then JavaScript is the least of your worries.
euroclydon 5y ago
Nice overview of the crypto.subtle apis, but I'm not sure about some of the use cases. >Multi-factor Authentication >Sometimes, hackers can steal users’ passwords. So, even if these passwords are hashed or encrypted in the database, it can’t stop them from accessing a user’s account. To make sure that someone who’s accessing an account is the true owner, applications allow multi-factor authentication. >Rather than using transport-layer authentication, such as TLS client certificates application can use suitable client keys which may have been previously generated via the user agent like multifactor tokens. I could not follow this part. With FIDO, you have should have a Trusted Platform Module or Hardware Security Key to store the secret key, but I'm not sure what is being suggested here. In the section on "How to deal with man in the middle attacks", there is no mention of TLS 1.3, which would be the #1 thing on my list. I agree with others here, that JS Crypto is shaky because you still need to trust the server not to give you compromised JavaScript. TLS and the Same Origin Policy are designed to sort of bridge the security boundary of the server up into your browser page. In this scenario, just offload the crypto to the server.
pwlb 5y ago
Core mechanisms to prevent Man-in-the-Middle are missing in the article: PublicKey/certificate-Pinning or PKIs. Cryptography is best left to the experts, most of todays javascript developers are probably missing the knowledge to implement or use it in a correct way
- px43 5y ago
  Those are browser features, not JavaScript features. This is an article about JavaScript.
  - bawolff 5y ago
    No, those are crypto concepts. You can implement them in javascript or any other language you choose. (Doing so in client side js is probably a stupid idea, but so is pretty much everything in the article. Its definitely possible though)
    - px43 5y ago
      Can you explain to me how you think certificate pinning would work in JavaScript? That doesn't make any sense. Client-side crypto (even in JavaScript) has its place, but certificate pinning is specifically a TLS thing, and IMO not relevant to this discussion.
      - bawolff 5y ago
        You have funcs to make public/private key pairs. Funcs to sign things. You can make your own PKI in the usual manner. You could then pin on specific keys in your chain of signatures if you want. Why you would, i dont know. Its a terrible idea like most use cases for js client side crypto, but you could if you wanted to. Then again, cert pinning is a mostly terrible idea in the context of TLS too.
bawolff 5y ago
This article is silly and i would argue dangerous. One of the applications they suggested is MFA. If you're validating mfa on the client side you are doing it wrong. They give 3 ways to deal with MITM attack. PKI isn't mentioned as one of them. Who the hell tries to deal with MITM by looking at network timings? There's a reason that the api has subtle in the name, its because using it naively will shoot yourself in the foot. Unless you have a very specific usecase,leave the crypto to the tls layer.
- deleted 5y ago
  [deleted]
- game_the0ry 5y ago
  > One of the applications they suggested is MFA. If you're validating mfa on the client side you are doing it wrong. Agreed. > Unless you have a very specific usecase,leave the crypto to the tls layer. Agreed. Author should delete that blog post. Normally, I wouldn't suggest that, but since this is dealing with security, it should thoroughly scrutinized, especially since there are so many JS noobs just starting their careers and they might look at this post as best practices.
game_the0ry 5y ago
Just a sec, need to put on my tin foil hat... It looks like this post is from a person in Nigeria. Perhaps this is a scam where they create a blog post targeting JS noobs where they advocate for questionable security practices, making web security a little more vulnerable, therefore making it easier for scammers to exploit client side JS. If that's the case - bravo, that is some jedi level mind tricking. Obviously, that is unlikely, but would funny if even remotely true. EDIT - I take that back, looks like this is the blog of a legit company [1], though it looks Russian hmmmm [1] https://www.sessionstack.com/about https://www.sessionstack.com/about
- domano 5y ago
  Why did you jump to that conclusion? The only explanation i can find would be to brand you as a racist, but i'd rather not, that is why i am asking.
austincheney 5y ago
Sigh. Everybody in software believes they have some variable understanding of security but in most cases that confidence isn’t validated by anything. In most cases developers talking about security is Dunning-Kruger on full display. Essentially every software security related subject can be qualified by a single question: What industry trusted process validates your concern?

71 points by zlatkov 5y ago

vbezhenar 5y ago

As long as server can serve any JS to any client, you can’t protect the data from the server.

metafunctor 5y ago
How is that? Lots of sites server their code to any client, but the data contained within the service is still secure.
- q3k 5y ago
  'Javascript crypgography considered harmful' by tptacek (2011): https://archive.is/cyk2R https://archive.is/cyk2R tl;dr: In most cases browser JS crypto offers no advantages if you're trying to protect yourself from a rogue/compromised backend (eg. do e2e crypto on keys stored within localstorage before passing that over to the backend). That is because if the backend is compromised it can likely serve backdoored JS code that will leak secrets. This is not always true (eg. if you have multiple tiers of server backends within separate security domains), but almost always true for typical web monoliths.
austincheney 5y ago
It’s more complicated than that. For the most part the browser is a secure environment due to same origin policy. JavaScript in the browser can only send and receive from the domain from which that JavaScript is served, which means the JavaScript must come from your own domain or from a third party you trust. That trust is all from the perspective of the web server, though, which is orthogonal to the concerns of the end user. https://en.m.wikipedia.org/wiki/Same-origin_policy https://en.m.wikipedia.org/wiki/Same-origin_policy Browser extensions can bypass that though, which can expose you to malicious third parties.
- tyingq 5y ago
  "Third party you trust" is tricky though. Like what happened with Backblaze. I don't think they really intended to scarf private data and exfiltrate it. Probably just a marketing person not knowing the implications. https://news.ycombinator.com/item?id=26536019 https://news.ycombinator.com/item?id=26536019

vaylian 5y ago

Interesting article. The built-in crypto module was new to me. This is actually a web standard: W3C: https://www.w3.org/TR/WebCryptoAPI/#Crypto-attribute-subtle https://www.w3.org/TR/WebCryptoAPI/#Crypto-attribute-subtle Mozilla docs: https://developer.mozilla.org/en-US/docs/Web/API/Crypto/subtle https://developer.mozilla.org/en-US/docs/Web/API/Crypto/subt...

deepstack 5y ago
Yeah it is what spawned these wire proton mail guys to encrypt on the client side.
- deleted 5y ago
  [deleted]
Jiocus 5y ago
That's right. SubtleCrypto implementations are also fast, and available on mobile browsers. SubtleCrypto has some design choices to avoid common mistakes to reduce risk of vulnerable implementations[1], and as such it's aimed at the general developer. In my opinion, more developers should familiarize themselves with the tools and start looking at how they could implement security for their users. Processing highly critical data, such as PII or financial data, is not a requirement to use cryptography. Starting out, on could well be served by trying it in personal projects or even public data. This way, uncovering a vulnerable design could mean uncovering data that was already meant to be seen. Some will always argue it's the wrong or the dangerous thing to do, and they will never ship security to their users, I guess. – [1]: For example, the ReactDOM manipulations breaks this security model because SubtleCrypto will only interface with the DOM. There are additional libs as workarounds for these issues tho.
- bawolff 5y ago
  > and as such it's aimed at the general developer. Its literally named subtle to discourage the general developer. In the https web model, there are very few situations where using this api actually makes sense. (Seriously, i challenge you to name one in a typical server-client web app)

qpie 5y ago

Interesting article. Thanks For Sharing

austincheney 5y ago

I would be hesitant to trust any cryptographic implementation coming from browser JavaScript. It’s not that I doubt or don’t trust the implementations from the browser vendors. I don’t trust the JavaScript developers executing them. This will provide a false sense of security implemented by persons lacking the education, training, and experience in security. Most software developers generally are not formally trained in security as a separate domain of knowledge. If you think security is something that can be passively acquired by reading a few APIs you are wrong. This is why employers require certifications for security work that software development otherwise doesn’t require. Cryptography was one of the most challenging domains/chapters in preparation for the CISSP. This is because real world cryptography implementations comprise various different cryptographic functions doing different things, such as: certificates, encryption, signatures, hashing, and so forth. The different crypto functions serve different purposes because they have different pros and cons. There isn’t some encryption blanket solution.

kenniskrag 5y ago
Can you recommend resources to learn security? Passed 3 security modules at my university and it feels like I know not much about secure engineering.
- austincheney 5y ago
  Study first for the Security+ exam. That is the entry level security certification. It is much harder now than it used to be. You can find a lot of books and study material about it online. The gold standard is still CISSP for the corporate world. It is more of a managerial standard. The best study guide is the official course book: https://www.amazon.com/Certified-Information-Security-Professional-Official-ebook/dp/B07CG86947/ref=mp_s_a_1_4?dchild=1&keywords=cissp+coursebook&qid=1619696728&sr=8-4 https://www.amazon.com/Certified-Information-Security-Profes... https://en.m.wikipedia.org/wiki/Certified_Information_Systems_Security_Professional https://en.m.wikipedia.org/wiki/Certified_Information_System... The standard most prized by government and security researchers is GIAC from Sans. https://en.m.wikipedia.org/wiki/Global_Information_Assurance_Certification https://en.m.wikipedia.org/wiki/Global_Information_Assurance... To take the CISSP you have to apply for the exam because there are prerequisite criteria and the exam costs $700. Even still it only has around a 60% pass rate. The GIAC tests are supposed to be much harder and are extremely expensive. I passed the CISSP but have never taken any of the GIAC tests.

upofadown 5y ago

The article doesn't really explain the reason that MITM attacks are possible and how to prevent them in the first place. That is too bad because that part is pretty much at the end of the article.

benmmurphy 5y ago

The irony is when running their product on your site you are opening yourself up to an MITM attack from them. https://docs.sessionstack.com/docs https://docs.sessionstack.com/docs To be fair most SAAS javascript products (google analytics, stripe payments, etc) are going to work like this and they also offer an on-premise solution that presumably doesn't have this issue.

Asmod4n 5y ago

The main issue I still see with JavaScript crypto in a Website session is how you can verify the Code running in the Browser isn’t tempered with. I got no issues with it inside a browser extension, because a Website cannot change the Code running there, correct? What I mean is, an advertisement could simply override the crypto API and do whatever it wants with it.

deepstack 5y ago
one of my big issue of placing google analytics or some kind of font js on your web site!
ianpurton 5y ago
You generally wouldn't put adverts on a site that's dealing with security. You should also add subresource integrity as a defence in depth. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- Asmod4n 5y ago
  Oh, that looks cool.
- goalieca 5y ago
  There’s many security sites that load tons of external scripts. My bank is one such example. Even if those third party trackers and such are trustworthy there remains the whole supply chain attack consideration.
  - hanniabu 5y ago
    Banks are never a good example for security. I know mine, which is a big name, still doesn't support OTP 2FA.
    - goalieca 5y ago
      Banks, Enterprise management, ... these are all guarding extremely valuable assets so i considered them security websites (not sure what is more security relevant other than the master email account we all have). They are written in a way that is hard to secure through CSP, disabling javascript, etc.

unnouinceput 5y ago

What year is it? 1990? Quote: "As people communicate over the internet, there’s a possibility that others can eavesdrop or even hijack information before it gets to the other parties involved." Let me tell you something buddy, if someone can decrypt->modify->encrypt undetected your communications then JavaScript is the least of your worries.

euroclydon 5y ago

Nice overview of the crypto.subtle apis, but I'm not sure about some of the use cases. >Multi-factor Authentication >Sometimes, hackers can steal users’ passwords. So, even if these passwords are hashed or encrypted in the database, it can’t stop them from accessing a user’s account. To make sure that someone who’s accessing an account is the true owner, applications allow multi-factor authentication. >Rather than using transport-layer authentication, such as TLS client certificates application can use suitable client keys which may have been previously generated via the user agent like multifactor tokens. I could not follow this part. With FIDO, you have should have a Trusted Platform Module or Hardware Security Key to store the secret key, but I'm not sure what is being suggested here. In the section on "How to deal with man in the middle attacks", there is no mention of TLS 1.3, which would be the #1 thing on my list. I agree with others here, that JS Crypto is shaky because you still need to trust the server not to give you compromised JavaScript. TLS and the Same Origin Policy are designed to sort of bridge the security boundary of the server up into your browser page. In this scenario, just offload the crypto to the server.

pwlb 5y ago

Core mechanisms to prevent Man-in-the-Middle are missing in the article: PublicKey/certificate-Pinning or PKIs. Cryptography is best left to the experts, most of todays javascript developers are probably missing the knowledge to implement or use it in a correct way

px43 5y ago
Those are browser features, not JavaScript features. This is an article about JavaScript.
- bawolff 5y ago
  No, those are crypto concepts. You can implement them in javascript or any other language you choose. (Doing so in client side js is probably a stupid idea, but so is pretty much everything in the article. Its definitely possible though)
  - px43 5y ago
    Can you explain to me how you think certificate pinning would work in JavaScript? That doesn't make any sense. Client-side crypto (even in JavaScript) has its place, but certificate pinning is specifically a TLS thing, and IMO not relevant to this discussion.
    - bawolff 5y ago
      You have funcs to make public/private key pairs. Funcs to sign things. You can make your own PKI in the usual manner. You could then pin on specific keys in your chain of signatures if you want. Why you would, i dont know. Its a terrible idea like most use cases for js client side crypto, but you could if you wanted to. Then again, cert pinning is a mostly terrible idea in the context of TLS too.

bawolff 5y ago

This article is silly and i would argue dangerous. One of the applications they suggested is MFA. If you're validating mfa on the client side you are doing it wrong. They give 3 ways to deal with MITM attack. PKI isn't mentioned as one of them. Who the hell tries to deal with MITM by looking at network timings? There's a reason that the api has subtle in the name, its because using it naively will shoot yourself in the foot. Unless you have a very specific usecase,leave the crypto to the tls layer.

deleted 5y ago
[deleted]
game_the0ry 5y ago
> One of the applications they suggested is MFA. If you're validating mfa on the client side you are doing it wrong. Agreed. > Unless you have a very specific usecase,leave the crypto to the tls layer. Agreed. Author should delete that blog post. Normally, I wouldn't suggest that, but since this is dealing with security, it should thoroughly scrutinized, especially since there are so many JS noobs just starting their careers and they might look at this post as best practices.

game_the0ry 5y ago

Just a sec, need to put on my tin foil hat... It looks like this post is from a person in Nigeria. Perhaps this is a scam where they create a blog post targeting JS noobs where they advocate for questionable security practices, making web security a little more vulnerable, therefore making it easier for scammers to exploit client side JS. If that's the case - bravo, that is some jedi level mind tricking. Obviously, that is unlikely, but would funny if even remotely true. EDIT - I take that back, looks like this is the blog of a legit company [1], though it looks Russian hmmmm [1] https://www.sessionstack.com/about https://www.sessionstack.com/about

domano 5y ago
Why did you jump to that conclusion? The only explanation i can find would be to brand you as a racist, but i'd rather not, that is why i am asking.

austincheney 5y ago

Sigh. Everybody in software believes they have some variable understanding of security but in most cases that confidence isn’t validated by anything. In most cases developers talking about security is Dunning-Kruger on full display. Essentially every software security related subject can be qualified by a single question: What industry trusted process validates your concern?