-1

When developing web apps it's often common practice to inject variables into, and reference them from, a current POST request - for example, Laravel's merge() helper exists to do exactly this - and it's easier to do this and pass the variables through with the response than to do so separately.

If I inject data into my HTTPS POST requests/responses in this way and then pass that response back to the view, can these variables be considered secure, or are they able to be seen on the client-side?

I'm questioning this right now because I recently read somewhere that HTTPS requests are only encrypted in transit (as opposed to end-to-end) in order to prevent MITM attacks, which seems to imply that they are unencrypted on the ends themselves. If this is true, it would mean that the user is able to see them on the client-side, making data sent to them insecure.

Hashim Aziz
  • 4,074
  • 5
  • 38
  • 68
  • 17
    Any data the user sends you is visible to the user, and any data you send to the user is visible to the user. If there is data that you don't want the user to have, don't include it in any response that you send to the user. – David Feb 22 '22 at 20:56
  • 1
    never trust data coming from a request – medilies Feb 22 '22 at 21:49
  • 1
    The question is discussed on [Meta](https://meta.stackoverflow.com/q/416177/11407695). Please avoid excessive voting in the meantime – Oleg Valter is with Ukraine Feb 23 '22 at 21:26
  • Does this answer your question? [How does HTTPS provide security?](https://stackoverflow.com/questions/3968095/how-does-https-provide-security) – yivi Feb 24 '22 at 05:13
  • @yivi No, it suffers from the same problems as most other questions and write-ups on the topic, which is that it's a high-level theoretical overview of the mechanics without discussing any of the practicals that developers building things need to actually know. It doesn't answer either my primary question of client-side security nor whether HTTPS is E2E-encrypted or just encrypted in transit. – Hashim Aziz Feb 24 '22 at 14:40
  • 1
    There is not such a thing as "just encrypted in transit", that's simply a confusion from you. You are confused about how HTTPs works, which is the reason for this question and its many misconceptions. The linked q&a is far from "theoretical". It deals precisely on the practical things a developer dealing with these things **should** know. Good luck in the future :) – yivi Feb 24 '22 at 14:42
  • 1
    @yivi Yes, I was confused before the question was answered, that was the purpose of my asking the question. As I said in Meta, an asker cannot know what they don't know and expecting them to is one of the worst parts of the SE network. It's in the interests of anyone who cares about security for security questions containing bad assumptions to be answered rather than closed, because it's likely that many in the same position have those assumptions. Day-to-day developers don't have the time or inclination to read theoretical write-ups, expecting them to is bad for security. – Hashim Aziz Feb 24 '22 at 15:10
  • It seems you assume I am not a "day-to-day" developer, but some kind of ivory tower theoretician? How funny. In my experience, "day-to-day" developers better get acquainted with the tools of their trade. I was pointing you to the dupe to help you mispel your misconceptions. I'm very sorry I couldn't help you. Wish you all the best. Bye! – yivi Feb 24 '22 at 15:15
  • @yivi The "dupe" you linked to answers nothing that I actually asked, so I assumed you were doing what the SE network tends to do when they've made a decision to close a question by taking any second-guessing personally, and clutching at any and all potential duplicates regardless of whether their content actually answers the question asked. You too. – Hashim Aziz Feb 24 '22 at 15:23
  • Again, good luck and good bye! – yivi Feb 24 '22 at 15:25
  • `seems to imply that they are unencrypted on the ends themselves.` **Yes** `If this is true, it would mean that the user is able to see them on the client-side, making data sent to them insecure.` **It's true, it's insecure on the web app server side too** That's why session cookie stealing is possible. – Nathan Goings Feb 26 '22 at 06:13

1 Answers1

2

Reacting to modified question:

**If I inject data into my HTTPS POST requests in this way and then pass the request to a view, can this data be considered secure, or is it able to be seen on the client-side?

If you're injecting data into an incoming request and then passing that data to a view, the data itself is on the server so it's as safe as anything is on your server. It is not accessible to the client unless you include it in the view and thus the rendered response that you send to the client. Once you send it to the client, it's wide open to the client.

If you only use the injected information as something your server temporarily uses to help build the view (like perhaps a client credential or client identifier) and the injected information itself is not present in what you send to the client, then that injected information is not accessible to the client.

Said, another way, the injected information is only available to the client if you send it to the client as part of the http response. The client has no access to data being used internally on the server.

FYI, all of this above has nothing to do with encryption. An https response going back to a client gets encrypted by the https transport the moment you hand it off to your https library (before it leaves your server process) and it stays encrypted until it arrives in the client process at the other end of the http connection. Once inside the client, the data is no longer encrypted (so it can be used by the client).

Original answer based on original content/understanding of the question:

If I inject data into my HTTPS POST requests in this way and then pass the request to a view, can this data be considered secure?

It is pretty much as secure as any client-side data can be. It's secure from outsiders, but not secure from the client themselves and not being secure from the client itself is fundamental to the client/server architecture.

Data that a client should not be able to see should never be sent to the client in the first place. It should be kept on the server and perhaps connected with the client request via a server-side session or some technique like that.

I recently read somewhere that HTTPS requests are only encrypted in transit (as opposed to end-to-end) in order to prevent MITM attacks, which seems to imply that they are unencrypted on the ends themselves.

HTTPS is encrypted from the point at which the data leaves the client code all the way to where the data enters the server code (or vice versa). That's end-to-end where the ends are from the client's code to the server's code (or vice versa depending upon which way you're sending data). Thus, it is also encrypted in transit between those ends.

So, the question is very confused about this.

If this is true, it would mean that the user is able to see them on the client-side, making data sent to them insecure.

Then, this is also confused. All data that exists on the client-side is potentially viewable by the user (with a small amount of coding skill). The entire client-side is insecure from the client itself. That is just a truism of the client-server architecture. So, the notion that you could merge in some data with your client-side code and that data could never be viewable by the client is just misguided.

In your client, the data sits in some user-visible form in plain text. Then, the user carries out some action to submit the data to the server. Your client-side code receives the data in plain text, merges in some more data in plain text and then calls some function to initiate the https request. Up to now all the data is being managed by your client-side code and it's all in plain text. A coder of moderate skill with access to the client could follow what was happening.

When the function is called to make an https request, the underlying code established the https connection to the server and this includes negotiating encryption mechanisms. The data is then encrypted (before it leaves your client-side process) and the data is sent over TCP to the server fully encrypted.

It's not viewable by anyone on the network or even in the local OS because it is end-to-end encrypted.

But, while the data was being assembled in the client (before the https request was sent), it was viewable by anyone with access to your client and some coding/hacking skills.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • Thank you for being the only person to answer the question. To be clear, this question was referring to merging the data into the response (lack of accurate terminology on my part) on the server-side using something like the PHP/Laravel `merge()` function, and then sending that back to the client. For clarification, does the same apply in this case? Is the data insecure as soon as it touches the client? – Hashim Aziz Feb 23 '22 at 23:55
  • 1
    @HashimAziz - Anything you send to the client is potentially viewable by the client. If you don't want the client to see it, don't send it to the client. I wouldn't say data you send to the client is inherently insecure - it's still subject to whatever security restrictions the client itself implements. For example, it should be secure from other processes on the system that don't share the client's privileges. But, if you send it to the client, it is not secure from the client itself. – jfriend00 Feb 23 '22 at 23:56
  • "*HTTPS is end-to-end encrypted*" - this is too bold of a claim, at least without specifying what the ends are. Usually, "end-to-end" means "user-to-user". See also [the OPs follow-up question](https://security.stackexchange.com/q/259903/8749) on security.SE – Bergi Feb 25 '22 at 02:24
  • @Bergi - The very next sentence says: "It's encrypted from when it leaves the client to when it is delivered to the server's code (that's end-to-end). " which is defining the ends. Is that not enough? – jfriend00 Feb 25 '22 at 02:25
  • I think it should say "*if we treat the client and the server as ends*", not "*the client and the server are the ends*". HTTPS can be used in many scenarios that are not considered end-to-end encryption, where the server is not an end that we care about. – Bergi Feb 25 '22 at 02:27
  • 1
    @Bergi - OK, I don't think anyone would have been confused based on the previous wording, but I revised it a bit to be clear what I'm calling the ends and that the encryption is end-to-end between those specific ends. This is a client-to-server transmission (or vice versa) so nobody thinks this question involves user-to-user. End-to-end in this context means between the two ends of the transmission. The question is specifically about an https request, nothing more than that is mentioned. Let's please stay within the context of the question – jfriend00 Feb 25 '22 at 02:56
  • I think this answer misunderstands the question - and the OP may not really be understanding the situation. The Laravel merge function that the OP proposes to use is only adding data into the **server side representation** of the request, within the PHP app. It happens after the request is received. – bdsl Feb 26 '22 at 15:43
  • 1
    @bdsl - Yes, this was covered with the OP in a follow-on question. The question here is less than clear, but the answer supplied ended up covering what the OP wanted to know. As the question here has now been closed (for the 2nd time) and the OP has moved on, neither of us is spending more time here. – jfriend00 Feb 26 '22 at 17:43
  • 1
    @bdsl I have a feeling you're one of the few people to get past my confused usage of the terminology to fully understand what I was asking and that many of the downvoters didn't really understand the question and/or didn't bother to look at how the linked function worked. – Hashim Aziz Feb 27 '22 at 19:47