[aeorgnoieang]

A 'user' can do all of the things you mentioned, e.g. "insert random HTTP headers", given that they have access to all of the stuff your code does too, so any code, of yours, that runs outside of _your_ systems, _is_ in "enemy territory", as none of the code _inside_ your systems can trust anything from 'outside', even if it possibly came from your code.

[Matumio]

Executing an action against the user's will is a security issue, even if that action is allowed according to the user's credentials.

[aeorgnoieang]

Sure!

I'm guessing we have different 'threat models' in mind.

From my perspective, I know _I_ am a moral and ethical person and therefore won't "execute an action against the user's will".

But, also from my perspective, even if "that action is allowed according to the user's credentials", I can't tell, and thus my server-side code can't tell, that a 'user' is a real person or even a legitimate user of my site or app.

The comment I was replying to claimed that "The user agent is ... is not enemy territory.".

But what came to my mind on reading that was user agent's also (commonly) perform 'card testing' and 'credential stuffing' and, even if I trust that I can securely give them access to my front-end/client-side code, I have no way to know whether they're running that code. And, even if they're running my code, there's _still_ room for malicious or nefarious action on their part.

I was NOT disagreeing with this (in the comment to which I was replying):

> Yes, the server must assume that enemy agents also exist. But it should better not deliver one to all users.

[rendall]

I tried to get either of these two to be clear about how precisely this attack works but they reply only with word salad and non-sequiturs (true but irrelevant statements like "one should not deliver enemy agents to users"). I think neither can offer actual code that demonstrates the problem. Given their assertion that "the user agent is not enemy territory because it runs code from your server" I think they're maybe very young or new coders.

[rendall]

> It runs code fetched from a trustworthy origin (your server), so it is not enemy territory.

We should define terms before arguing. Enemy territory is anything you do not directly control. So, as a developer, you do not know if the user's agent is running your code from your server or something compromised. Assume the worst. Anything exiting the user's agent must be cleaned.

> Executing an action against the user's will is a security issue

Non-sequitur. Unless you're saying the `text` parameter could somehow execute code? It can't.

Considering the worst reasonable scenario, that this `text` parameter is sent directly from user input: so what? It may not be great practice, but it's not a security issue. Clean it server-side, which is what should be happening anyway, which the article fails to mention.

Considering the worst unreasonable scenario: the `text` parameter is compromised by a hacker somehow. Well, you're dealing with a far worse situation than could be handled by cleaning input client-side. Better to ensure input is secure... on the server side.

But, maybe I and others here are wrong. Assume many of us do have a worrying misunderstanding of the fundamentals. For the sake of the health of the internet, step us all through this scenario where a secure server side does not save the day, but these methods do.

[Matumio]

> Anything exiting the user's agent must be cleaned.

We all agree on that part. What's worrying here is the mentality that, once the server-side has been secured, the client can do whatever. It can be manipulated anyway, so it does not matter for security if it does validation or not.

This is wrong. As a user, I don't care if an attacker has manipulated my data on the client or on the server. As a site owner you are responsible for delivering a secure client.

Yes we should define our terms. The first term we need to define is "security". From the comments here, I'm starting to think people define it as "RCE on the server". That's a rather narrow view.

> step us all through this scenario where a secure server side does not save the day

Back to the example: maybe you're building a chat tool, and it has this sentiment-feature to help with moderation. At the very least, this bug could hide offensive content from a moderator. But you are calling POST to "/api/sentiment/" with untrusted text that can leak into other parts of the request. I haven't done the analysis, but maybe an additional form field could be set, say "learnAsPositive=true"? Or maybe you have some questionable "not a security problem" API design that re-uses the same POST endpoint for multiple things, and you could set "blockUser=true" and control the user name, or moderators can edit the message text. Or maybe it wasn't a sentiment endpoint but something more important, and the untrusted text could be the name of another user.

[rendall]

You say a lot of true things that aren't related to what I said and asked. No one said "the client can do whatever". No one reasonable says that.

> you are calling POST to "/api/sentiment/" with untrusted text that can leak into other parts of the request

Could you expand on this? What does 'leak into other parts of the request' mean?

> Or maybe you have some questionable "not a security problem" API design that re-uses the same POST endpoint for multiple things, and you could set "blockUser=true" and control the user name, or moderators can edit the message text.

Again, this sounds like a server-side problem and bad coding practices. If someone is allowing such things to happen, then the user has worse problems than the dev not formatting their data properly.

The OP's contention was that (pseudocode)

  fetch({body:stringFromOutsideTheFunction})

is inherently a security risk and that the methods outlined would protect against the security risk.

I don't need to flog this horse. OP probably got a lot more attention for this article than he's used to. I wish he would at least mention that security must be done on the server-side, but whatever.

I'd like to point out that the concerns you do specifically have, that bad client-side code could lead to the user being fooled in some way is definitely true. I don't see how the example can naturally lead to that, but as I said, I'll let this go. However, one thing you can do to protect your users is to make sure that the server that serves the javascript has a content-security-policy response header, which would prevent XSS attacks. This will prevent altered code from loading in the browser. Read more about it here: https://content-security-policy.com/

Even more basic, everyone should be serving over https://. Those certificates used to be expensive, but now they are free or low-cost. This will encrypt the request/response traffic between your server and the user. More details here: https://letsencrypt.org/

[Matumio]

The original code was attempting to set a single form field named "text", while actually allowing that text to control the whole form being submitted.

This is a security risk, because form requests can mix trusted with untrusted inputs. (Trusted: e.g. the action selected from a drop-down. Untrusted: e.g. another user's text or name, or an entity name decoded from the initial URL.)

So, sticking with the "moderation tool" example, you could make a moderator execute an unintended moderation action when they interact with your carefully-crafted username.

The article showed that a piece of vulnerable frontend code was generated. Most commenters instantly dismissed that as an irrelevant concern and instead talked about securing the backend. Yes, you need to secure the backend. You need to protect against XSS. Neither of those fixes the problem that was shown in the code.

[rendall]

> The article showed that a piece of vulnerable frontend code was generated.

The article didn't show anything. It just asserted it.

All right. This is over.

I'd be delighted if at least one of you two could present a coding example that, when run, demonstrates an actual problem that needs to be dealt with.

Declare victory if you must, but if your next response is anything other than example code that, when run, demonstrates the problem, it will be clear to everyone that you guys don't know what you're talking about.

Sorry to be so blunt but there's only so many ways to ask how it's a problem before it's clear there is no real answer.

TL;DR: coding example or GTFO

[jaffathecake]

Thank you for persevering with this. It's slightly worrying how so many folks here have such a narrow view of what security is and isn't.

[rendall]

You need to explain this better, not just be patronizing towards people who disagree with or misunderstand you. So far, your only explanation is that is possible to bypass "sentiment analysis", which doesn't make sense.

Is not a "narrow view" of security. Your example is not secure, period, which is fine, because that's not where security needs to happen.