3 ms·

"Most injection attacks are due to this; if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately." How s

"Most injection attacks are due to this; if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately." How so? If you allow the user to send arbitrary data, and your handling of that data is where the problem lies, it isn't going to matter whether the client sends a length-prefixed piece of data. You still have to sanitize that data. HTML, and whether it uses closing tags or not, is pretty much irrelevant to the way injection attacks work, as far as I can tell. Maybe I'm missing something...do you have an example or a reference to how this could solve injection attacks?

an_account 9y ago
If you can say, “the next 450 characters are plain text and should be rendered as such”, then even if the text includes script tags (or whatever), they won’t be parsed or executed.
- SwellJoe 9y ago
  This seems like an argument for strong types. Which is reasonable. But, one could do that with closing tags, too. We already know that relying on a programmer to specify the length of data is prone to bugs (C/C++). And, you can't trust the client to specify the length of data. I feel like this is conflating two different problems and potential solutions. I'm not saying injection attacks aren't real. I'm saying that whether HTML uses closing tags or not is orthogonal to the solution. But, again, maybe I'm missing something obvious here. I just don't see how what you're suggesting can be done without types and I don't see how types require prefixing data size in order to work.
- zaroth 9y ago
  There is a .innerText property which works perfectly fine for this if you want to ship your content inside JSON and then plug it in...
sp332 9y ago
If the length is not pre-defined, the input has to be parsed to look for the closing tag. That makes your code vulnerable if the input tricks it into finding the wrong closing tag. But if the length is fixed, you don't have to parse it at all. That would avoid a whole class of vulnerabilities.
- dgoldstein 9y ago
  True, assuming that programmers don't compute code (HTML,SQL, etc) from user input and miscompute the length of a fragment. It would be interesting to see if this idea could work in practice.
  - DCoder 9y ago
    A simple example could be the Twitter API's handling for references (URLs/hashtags/at-user mentions) in a tweet [0]. The tweet text is returned in one field, and all references are listed in a different field together with first/last character index within the tweet where that reference was found. You don't need to parse the tweet text yourself, just display it as plain text and insert links where the references say you should. [0]: https://dev.twitter.com/overview/api/entities-in-twitter-objects#the-urls-entity https://dev.twitter.com/overview/api/entities-in-twitter-obj...
  - mike_hearn 9y ago
    This isn't some theoretical design. Any native application that uses a binary protocol framework like protobufs over TCP to communicate with the backend will benefit from this approach.
    - mwcampbell 9y ago
      > protobufs over TCP I guess it would have to be protobufs over TLS, and abuse port 443, to get through firewalls from hell.

an_account 9y ago

If you can say, “the next 450 characters are plain text and should be rendered as such”, then even if the text includes script tags (or whatever), they won’t be parsed or executed.

SwellJoe 9y ago
This seems like an argument for strong types. Which is reasonable. But, one could do that with closing tags, too. We already know that relying on a programmer to specify the length of data is prone to bugs (C/C++). And, you can't trust the client to specify the length of data. I feel like this is conflating two different problems and potential solutions. I'm not saying injection attacks aren't real. I'm saying that whether HTML uses closing tags or not is orthogonal to the solution. But, again, maybe I'm missing something obvious here. I just don't see how what you're suggesting can be done without types and I don't see how types require prefixing data size in order to work.
zaroth 9y ago
There is a .innerText property which works perfectly fine for this if you want to ship your content inside JSON and then plug it in...

sp332 9y ago

If the length is not pre-defined, the input has to be parsed to look for the closing tag. That makes your code vulnerable if the input tricks it into finding the wrong closing tag. But if the length is fixed, you don't have to parse it at all. That would avoid a whole class of vulnerabilities.

dgoldstein 9y ago
True, assuming that programmers don't compute code (HTML,SQL, etc) from user input and miscompute the length of a fragment. It would be interesting to see if this idea could work in practice.
- DCoder 9y ago
  A simple example could be the Twitter API's handling for references (URLs/hashtags/at-user mentions) in a tweet [0]. The tweet text is returned in one field, and all references are listed in a different field together with first/last character index within the tweet where that reference was found. You don't need to parse the tweet text yourself, just display it as plain text and insert links where the references say you should. [0]: https://dev.twitter.com/overview/api/entities-in-twitter-objects#the-urls-entity https://dev.twitter.com/overview/api/entities-in-twitter-obj...
- mike_hearn 9y ago
  This isn't some theoretical design. Any native application that uses a binary protocol framework like protobufs over TCP to communicate with the backend will benefit from this approach.
  - mwcampbell 9y ago
    > protobufs over TCP I guess it would have to be protobufs over TLS, and abuse port 443, to get through firewalls from hell.