| Handling user input is tricky, and so is (de) serialization (I seem to recall most big frameworks from ruby, via php and python through Java - all doing some form of unsafe marshaling from both xml and json). For encrypted and signed data on the client, you get to add "crypto is hard" on top. You get things like clear signed data - that makes it easier to de-couple verifying signatures from marshaling contained data - perhaps without checking the signature... You get encrypted data that isn't using a proper authenticated encryption construct - and again open the door for manipulated data. Even with proper encryption, you get key revocation wrong (left out), and there's maybe no expiry on chiper texts either - so you happily accept data encrypted and signed by a compromised or expired key. And there's key management, like in this case, re-using a key that should be sigle client/single session. Oh,and re-play attacks due to missing serial numbers/nonce on transactions/messages... But yeah, sure. Like another comment mentions - in theory encrypted data managed by the client is sound.. Unfortunately in practice theory isn't always right. |