Reactgo: Secure / Encrypt Fetched-Data

[jrodl3r]

Seeking solution for securing/encrypting fetched-data.

even after enabling HTTPS, all fetched-data is still raw-accessible in the console as _{'human-readable': 'response-data'}_.

Ideally, fetched-JSON response would arrive via https protocol, encrypted to keep from peering eyes.

[choonkending]

Not an expert in this area, but definitely a fan of improving our security.

Do you want a

Encrypt in browser -> Decrypt in server

Encrypt in server -> Decrypt in browser

sort of model? I have 0% knowledge in this, but we could work to find out what a good way of doing this is.

On a side node
We should add helmet into our express to improve security.

References
Security best practices

[ZeroCho]

I'm running a blog based on reactGo, and I think we need to add data-encryption and prioritize it because initial data is shown to everyone who knows how to use browser console.

For example, my blog has a problem that members' emails are scraped by search engine and robots. This is not what my members want.

One more thing. I added helmet into my blog and it works well. Helmet protects from various threats and it's very simple to use.
app.use(helmet());

[choonkending]

Agree with both your points. We should priority security as well as performance.

• [x] https://github.com/reactGo/reactGo/issues/119 Do you wanna create helmet as a PR?
• [ ] Data encryption

I'm not sure what data encryption approaches we should take, do you have any ideas? I'll need to start researching on ways to handle this.

[ZeroCho]

@choonkending #429 here is PR

[jrodl3r]

Very cool @ZeroCho 👍

@choonkending We should definitely add the _option_ to [ Encrypt-on-Server » Decrypt-on-Client ]
However, I'm not sure if the async-POST-data is being encrypted as it's sent from the browser to the server... (will have to inspect this more and confirm). Whichever direction the data flows, we should make it easy to secure.

[choonkending]

Good work guys! I might have to handball this to @jrodl3r and @ZeroCho (and whoever is interested) as I'm focused on improving offline support and performance for this and next week!

[jrodl3r]

@ZeroCho experimenting with a few object encryption pkg's (ex: sehrope/node-simple-encryptor).

getting the response object data encrypted and sent back is a breeze, but the only problem is that there's nowhere to hook into that response and run decrypt() ...Fetch (promises) doesn't have _Success_ or _Failure_ handlers to hook into before the reducer gets called... Any ideas?

[ZeroCho]

@jrodl3r How about decrypting inside the reducer? Like const decryptedResult = decrypt(action.result);

[jrodl3r]

@ZeroCho is that really the right place to be doing that? I'm not 100% sure about that.

I tried it anyway, doesn't work on the client/browser, but it does on the server =(

[ZeroCho]

This is what I think we need to do for encryption.

• The data is stored encrypted on the server.
• It was encrypted using a public key.
• The server sends the encrypted to the client.
• The client needs to decrypt it using their local private key. (This should be done in reducer or promiseMiddleware where fetched data comes to the client first)

The thing is, how we can get local private key securely.

By the way, I think we need to encrypt and decrypt window.INITIAL_STATE only, because we already use SSL(https) and get/post requests are handled via https.

[jrodl3r]

that sounds pretty good. I would think process.ENV for the private key, eh? Heroku config on Prod, git-ignored local secret on Dev?

I completely agree about window.INITIAL_STATE ...weird seeing the app state hanging out in view-source =\

As for SSL, even when it's configured, enabled and accessed + confirmed via HTTPS:// ...the Fetched Object Data is unencrypted, totally raw. I'm not sure why, wondering if there is something in Express (enforce-ssl) that we are missing...

[ZeroCho]

We need to find the encryption & decryption package which can be used in both client and server.

[ZeroCho]

@jrodl3r CryptoJS seems suitable for both client and server.
I'll try to encrypt window.INITIAL_STATE first.

[jrodl3r]

I kept hitting the wall w/ CryptoJS errors, but if you can get it working that'd be dope ; )

[ZeroCho]

I almost made it, but one thing stops me.
How can I send process.env.DECRYPT_KEY from server to client.jsx?

[ZeroCho]

I concluded that I can't make perfectly secure data transfer process. We should rely on SSL. But I could make a temporary thing which blocks robots from scraping initial state, by encrypting with public key on the server and decrypting with public key on the client. Because this uses the PUBLIC key, it doesn't protect someone from decrypting manually, but no more raw initial state on html.

[ZeroCho]

Its encrypted like this.
But I'm not sure how much this will affect performance such as initial loading.

[jrodl3r]

@ZeroCho can definitely settle for "easily decrypt-able, but not human-readable" - can't wait to see what you came up with! 🍻

[ZeroCho]

I now have some time to make PR. I will make PR this weekend

[slavab89]

So my 2 cents on this and lets decide how to proceed with this.
Regarding sending data client -> server.
When using HTTPS, it would take care of the encryption for you.
When you are on the browser, there is no reason that you wont be able to see what you send in the developer tools, its you who are making the requests therefore there is no reason to hide this data.
If you would put a "sniffer" like fiddler or wireshark or something similar then you should not be able to see the data inside the request since its enrypted due to the HTTPS.

Regarding the initial fetched data being shown, is it that bad? I mean even if you encrypt it on the server and then decrypt it on the client, it is possibly accessible on the client side somehow (through the redux store and what not).
Moreover, if you just dont want it to be humanly readable then its possible to just do simple symmetric hashing. In case the data should really be encrypted then it should not be possible to decrypt it on the client side (also not really usable on the client side - similar to a session id cookie).

[choonkending]

Can you just delete it just once initialise your store? Maybe that way
might be slightly safer without the overhead of encrypting and decrypting

On Wed, 18 Oct 2017 03:59 slavab89 [e-mail] wrote:

So my 2 cents on this and lets decide how to proceed with this.
Regarding sending data client -> server.
When using HTTPS, it would take care of the encryption for you.
When you are on the browser, there is no reason that you wont be able to
see what you send in the developer tools, its you who are making the
requests therefore there is no reason to hide this data.
If you would put a "sniffer" like fiddler or wireshark or something
similar then you should not be able to see the data inside the request
since its enrypted due to the HTTPS.

Regarding the initial fetched data being shown, is it that bad? I mean
even if you encrypt it on the server and then decrypt it on the client, it
is possibly accessible on the client side somehow (through the redux store
and what not).
Moreover, if you just dont want it to be humanly readable then its
possible to just do simple symmetric hashing. In case the data should
really be encrypted then it should not be possible to decrypt it on the
client side (also not really usable on the client side - similar to a
session id cookie).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/reactGo/reactGo/issues/418#issuecomment-337285362,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADnMbQksmgBLNPYIkkTf2JPB2OS2-Sr0ks5stNz1gaJpZM4JdDLH
.

[GGAlanSmithee]

Generally, I tend to agree with @slavab89 on this topic. There really isn't any notion of secure data in the client. Just the same way you can inspect password field data etc. you can inspect any other "hidden" data in the dev console, such as cookies, local storage etc etc.

Any measure taken would IMO only provide a false sense of security, or end up creating a useless client, with non-readable data etc. It might be possible to do _something_ but I have a fealing it would come at a high cost.

I think @ZeroCho summarized it well

I concluded that I can't make perfectly secure data transfer process. We should rely on SSL. But I could make a temporary thing which blocks robots from scraping initial state, by encrypting with public key on the server and decrypting with public key on the client. Because this uses the PUBLIC key, it doesn't protect someone from decrypting manually, but no more raw initial state on html.

But, this is, IMO, worse than no protection, since it is in fact, no protection.

@choonkending don't we already do that?