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.
Re:It’s time to kill the web app
by dgoldstein on Saturday September 23, 2017 @05:44PM
(#15321925)
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.
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-obj...
Re:It’s time to kill the web app
by mike_hearn on Sunday September 24, 2017 @08:34AM
(#15324443)
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.
Re:It’s time to kill the web app
by mwcampbell on Sunday September 24, 2017 @02:32PM
(#15325849)
> protobufs over TCP
I guess it would have to be protobufs over TLS, and abuse port 443, to get through firewalls from hell.
Re:It’s time to kill the web app
by an_account on Saturday September 23, 2017 @05:22PM
(#15321795)
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.
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.
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?