447579 (3) [Avatar] Offline
#1
Perhaps it will be more clear later, but the XML example, isn't that an example of explicitly thinking about security and even being a security expert (at least know about the billion laughs attack)? Kind of the opposite to what the chapter is saying earlier?

I don't see a business reason not to allow XML entities or a design reason not to follow the Tolerant Reader Pattern, except with knowledge about this security problem in mind or at least having a strong security focus that will tell you it is a bad idea allocating any amount of memory based on external input unless there is a defined limit?

Without knowledge about the security problem, I don't see a reason against the common solution of deserializing into an object via some generic code and then validate the resulting object. It would also satisfy the business rules, it would be much faster to implement and less risks of errors (except the allocate all available memory security errors...).

Perhaps one can argue that the XML parsers' bad API designs caused the security vulnerability instead? It still takes some security focus to think about never allocating a possibly infinite amount of memory and from there come up with the need to let the user of the API limit the lengths somehow.

It is a fun attack though. I've played with bip2 compression in much the same way, <1KiB can expand into >1GiB!
Daniel Deogun (5) [Avatar] Offline
#2
Thank you very much for the feedback - we really appreciate it. Based on your comments, we believe our example didn't come out as intended and we'll update this in the next revision.

So to clarify, what we intended was to show how the design approach works in a complex situation where security weaknesses aren't explicit. Choosing XML and XML parsing felt like a good choice because the weakness lies in how it's parsed rather than how it's defined. Having this understanding certainly requires security awareness - instead, we suggest the design approach. We agree that choosing a strategy where input is validated on a structural level before parsing it isn't the first thing that comes to mind unless you know about the vulnerability. As it turns out, this only starts to make sense after reading about the validation pattern in chapter 4 - so it definitely needs some clarification.
perlundholm (3) [Avatar] Offline
#3
The XML examples of chapter 1 are not visible in the live book. You see only the entity besides two other characters.

]>


&lol9;