6 ms·

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 c

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.
    - rendall 5y ago
      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/ https://content-security-policy.com/ Even more basic, everyone should be serving over https:// 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/ https://letsencrypt.org/
- 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.

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.
  - rendall 5y ago
    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/ https://content-security-policy.com/ Even more basic, everyone should be serving over https:// 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/ https://letsencrypt.org/
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.