4 ms·

The user agent is... well, the user's agent. It runs code fetched from a trustworthy origin (your server), so it is not enemy territory. It holds the session k

The user agent is... well, the user's agent. It runs code fetched from a trustworthy origin (your server), so it is not enemy territory. It holds the session keys. It decides what can or cannot happen after the user clicks on a link with some funny URL in an e-mail. It displays and processes data entered by less trustworthy users. If anyone can just make it insert random HTTP headers, this could be a problem. Yes, the server must assume that enemy agents also exist. But it should better not deliver one to all users.

aeorgnoieang 5y ago
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 5y ago
  Executing an action against the user's will is a security issue, even if that action is allowed according to the user's credentials.
  - jaffathecake 5y ago
    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 5y ago
      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.
  - rendall 5y ago
    > 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 5y ago
      > 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.
  - aeorgnoieang 5y ago
    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 5y ago
      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.

aeorgnoieang 5y ago

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 5y ago
Executing an action against the user's will is a security issue, even if that action is allowed according to the user's credentials.
- jaffathecake 5y ago
  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 5y ago
    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.
- rendall 5y ago
  > 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 5y ago
    > 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.
- aeorgnoieang 5y ago
  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 5y ago
    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.