On Wednesday, February 6, 2019 at 12:35:11 PM UTC+8, Philip McGrath wrote: > > > Why is this significant in practice? Realistically, I don't expect > programmers would write functions like `corrupt-serialized` in an attempt > to deliberately exploit some library's invariant, and the chance of someone > doing so accidentally seems fairly remote. What worries me much more is > that I read serializable structs in over the network, stick them in > databases, and write them to disk. In the absence of a contract, any struct > that has ever been deserialized may be silently corrupt. Some bits could > have been flipped or some other process could have mangled a file on disk. > An attacker could have intentionally manipulated a value sent over the > network as part of some potential exploit. Perhaps most likely, the could > have been a backwards-incompatible change (perhaps an unintentional one) to > the contract on some field of the struct. >
> A contract couldn't protect me from encountering a malformed serialized > representation, but it would let me detect the error as soon as I try to > deserialize the bad value, rather than delaying the error until I actually > attempt to access a bad field. As things stand, if I usually just pass the > value around and move it in and out of storage, I might be unknowingly > passing around bad data indefinitely. > Even if you run the contract checks at de-serialization time, the contract system cannot protect you from a corrupt packet, as a bit flip might change a number into another, so a contract such as `integer?` would still pass, or it might corrupt the data such that de-serialization would fail altogether. To protect against network or disk corruption you will need to add check-sums to the serialized data, and if you are worried that a malicious party might modify the data, you need to add cryptographic signatures to the data in the database or use SSL for the network. ... this of course is not a good reason not to check contracts when data is de-serialized. Alex. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
