How do I encrypt the response from requests?
At the moment, if you go into the network, you can see the answer, there are all the data about the goods (price, category, etc.)
On the other side in this form (photo)
Is it somehow parsed at the front and it turns out in a normal form?
Perhaps somehow you can, for example, just encrypt an object on the back, and decrypt it at the front?
The best and most practical thing to do is use HTTPS protocol so data can't be intercepted when sent from backend to frondend. No need for encyption.
You can also fiter the data in the backend, if you have sensitive infomation like passwords and emails, before sending to the frontend.
Related
I have developed an app for Android/iOS which calculates a value based on the users input. If an event occurs, this calculated value will be sent to my Backend as normal HTTPS payload. My question is now, how can I make sure, that this value is really only calculated by the source code of my app? Is there a way to handle such a problem?
To make it clear: I want to avoid, that somebody is rooting his phone, extract the Auth-Token from the private storage of my app and sends a valid HTTPS-Payload to my Backend with fictitious payload, manually or by manipulating the source code.
From the view of the backend, it's difficult to evaluate the payload based on its values if it is valid or not.
Any suggestions appreciated!
----------EDIT-----------
For the sake of completeness: apart from the answers here, the following are also very interesting:
Where to keep static information securely in Android app?
How to secure an API REST for mobile app? (if sniffing requests gives you the "key")
You can’t trust data coming from the client. Period.
You should consider moving the calculation logic to the server and just sending the raw values needed to perform the calculation. You can easily get sub-second response times sending the data to the server, so the user won’t notice a lag.
If you need offline connectivity, then you’ll need to duplicate the business logic on both the client and the server.
Short of doing everything on the backend, you can't very easily.
I'd recommend some reading around CSRF (Plenty of articles floating around) as that's at least a good mitigation against bots outside of your app domain hitting your backend. The upshot is that your application requests a unique, random, identifier from your backend (which ideally would be tied to the user's auth token) before submitting any data. This data is then submitted with your app's data to perform the calculation on the backend. The backend would then check this against the random identifier it sent for that user earlier and if it doesn't match, then reject it with a 400 (Bad Request), or 404 if you're paranoid about information leakage.
We are doing lots of stuff to keep things secure when dealing with authentication, and I am still a beginner and trying to understand. What I don't understand at all, however, is why it is safe to just send form data to my node.js server (which, for example, then handles authentication).
When a user types in an email/password combination on my frontend, and i send it to the backend, wouldn't it be possible to intercept and read out this data?
Narrowing down from a broad topic, i have a specific question (maybe a little bit 'tin-foil hat').
This question is regarding the best practices of securing data transmitted in a post request between the client and server. The background is a web app I'm developing to learn more about node and express js.
Although the example i'm using is for login credentials it really could be about any information being transmitted in a post request from a form submit to an express server.
example:
client submits form data through a button click event on the client. I'm using vue for the front end, but this is a generic question. On the client page i'm also using (inside an async function):
const resp = await axios.post("http://someurl.com/login", {client:email, pw:pw});
in chrome developer tools on the network tab i can see the request payload. In the example it looks like:
{client:"some email address", pw:"some password"}
Would it be better to transmit the payload already encrypted / encoded? Then have it decrypted / de-encoded on the server?
For transmitting sensitive information, is it better to use a signed cookie?
The plan, should i ever get through all of this is to use let'sEncrypt for HTTPS.
Is it reasonable to only rely on HTTPS for protecting this type of payload?
For reference, on the express server, password gets hashed and compared with a hashed version from a database. I've read about Helmet, and csurf and intend to use them in the final product as well. There's a lot of great information in this answer. Which is incredibly awesome and talks about the importance of HTTPS over HTTP.
Any additional references / thoughts / practical considerations are appreciated.
Using HTTPS will encrypt your payload between your client and the server.
Any javascript handling on the front end can be circumvented by users with enough knowledge so all frontend is mainly there for is to facilitate a better user experience. Password confirmation checking, correct fields filled out etc.
Your main source of security will be your eventual LetsEncrypt HTTPS certificate and your hashing and salting applied at the server end. As you correctly surmised HTTP send passwords in clear text which is bad. As a warning though even HTTPS can be defeated if somebody wants it bad enough with a number of techniques to high jack Certificate Authorities (I believe Root CAs should be offline anyway) or modify trusted certificates on a users PC.
Although it does depend on the amount of effort required by the hacker vs potential return hence the more you are trying to protect the greater the security required before it becomes not worth the effort for any potential hacker to attempt to circumvent the security of a particular site. (Reputation hacks aside of course)
Hope this helps.
Were planning on implementing https / ssl for the first time on a project and in ancipiation i thought id dig a bit deeper into it.
I was looking at the data sent when loging into amazon.com using httpfox - the form sends a long POST string of which this is a subset (obviously email and password have been changed)
email=name%40example.co.uk&create=0&password=letmein
This seems to be sitting there in plain sight, if someone was running a packet sniffer would they be able to see this data, if not at which point does the encryption oc
The encryption between the browser and the server gets encrypted as a whole – not the POST data on its own, but the whole HTTP request.
What you are seeing in httpfox is only the client-side view of the data, before it is actually send. (Showing already encrypted HTTP request data would be of not much value for debugging; besides those kind of tools usually operate on a level so close to the browser front end, that encryption has not yet happened.)
The packet sniffer would only come into play when the whole request is already on its way from the client to the server, and there of course nothing is still “in plain”, so the attacker would only see the already encrypted data and therefor could not make any sense of it (unless he’s the NSA of course, as we all know since a few days).
I have form where I am entering all the data and on the submit button. I am sending the data for the processing. But what I noticed is that I can edit my post data using Tamper Data Add-on of Firefox and I think it is a Hack. So how can avoid this problem? What I have read is JSF uses default POST to send data, if so then why it is showing data in the Header? Is their any way by which I can control this and encode my post data?
That's just how HTTP works. How else would the client be able to send data to the server? Note that you shouldn't confuse request headers with request body. The POST data appears in the request body, not request headers.
But why would you like to avoid this? The only reasonable reason I can think of is that you're validating input data in the client side (using for example JS) instead of in the server side. You shouldn't be doing this. You should always validate in the server side. You should never trust user input. Utilize the JSF-provided validators such as required="true", <f:validateLongRange>, javax.faces.validator.Validator and so on as much as possible.
As long as you properly validate on the server side, the client can do whatever it want with the HTTP request and you don't need to worry about the safety (that is, when you trust JSF and your own code). JSF has already builtin prevention against XSS and also CSRF (to a certain degree, this has been improved in 2.1 and 2.2 respectively).
If your actual concern is actually the man-in-the-middle attacks, then you should take a look at SSL (HTTPS).