4 ms·

> Unescaped text is added into a format with defined encoding. Meh. This is only a problem if it's unknown text or from an external source like user input. If

> Unescaped text is added into a format with defined encoding. Meh. This is only a problem if it's unknown text or from an external source like user input. If it's from a known, trusted source, like internal code it's fine. The cleaning should be done on the server side, anyway, so this objection is moot. Anyone can send any kind of body. Your client is in "enemy territory". Treat everything coming from the client side as potentially dangerous. If you take this article's advice, you might think you're safe by just using these form data or url encoding. No. Not at all. This will not save you from SQL injection attacks or whatever. Only server-side cleaning will do that. I think this post was promoted only because it mentions copilot, to be honest. It's not good security

Matumio 5y ago
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.
jaffathecake 5y ago
See the existing thread about this https://news.ycombinator.com/item?id=27698345 https://news.ycombinator.com/item?id=27698345

Matumio 5y ago

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.

jaffathecake 5y ago

See the existing thread about this https://news.ycombinator.com/item?id=27698345 https://news.ycombinator.com/item?id=27698345