Many years ago I was shocked that ASP.net will deserialize arbitrary (potentially unsafe) objects from the client and relies on signatures to ensure that parameters sent by the client were in fact round-tripped via HTTP POST from the same server.
How is __VIEWSTATE not a horrible idea???
__VIEWSTATE should be as secure as JSON Web Tokens, unless you manage to leak the secret (or as in this case, you use a shared one for all customers.)
I don't know why exactly did they choose to (de)serialize executable code, instead of using an XML or similar format, but similar choices were made (and later changed) with frameworks/libraries for other languages, so they are not the only one.
An attacker just has to find one that (e.g.) accepts a url and a filepath in its constructor and saves the file to that location, and you've (usually) got code execution (by eg overwriting something that gets run frequently).
But the problem is there are some things that needed to be serialized for things like .NET remoting or firing stuff across appdomains. Things like Delegates.
Now, I -think- the intent, back in the day that ASP.NET was created, to use Code Access Security/Security Transparent Code (CAS/STC) to safely put a system like this together. But CAS/STC is pretty easy to do 'wrong' and a lot of people, rather than setting up the correct LinkDemands for individual items like Database, File IO, ETC on the specific endpoints, would just toss 'AllowPartiallyTrustedCallersAttribute' on the assembly and call it a day. This renders it CAS/STC almost worthless, to the point Microsoft half-killed this concept in Net 4.0 and in Core it's just about gone.
My understanding was that __ViewState was intended to be encrypted in production by setting something in machine.config[3].
[1]: https://en.wikipedia.org/wiki/Seaside_(software)
[3]: https://docs.microsoft.com/en-us/previous-versions/dotnet/ar...
Now, deserializing arbitrary objects which might contain code?... that's crazy town, but it was a different time.
Remember that the dataset is often going to be small, and frequently will contain known or easily guessed strings. Uncompressed, often at predicable locations.
There are whole classes of cryptographic vulnerabilities which might result from either not compressing (compression should in theory would normalize entropy over the stream) or using a compression algorithm that results in a predictable dictionary, length, or other value in the same location (if junk padding isn't used properly).
Also, sending the state from client to server might open replay attacks and all sorts of other horrid situations.
Security depends on doing everything correctly all the time; this context IMO just feels open to too many plausible and unknown (potentially introduced in the future) vulnerabilities.
Luckily neither .net WebForms, nor JSF are popular nowadays.
Oh boy do I have news for you!
[1]: https://devblogs.microsoft.com/aspnet/farewell-enableviewsta...
So in some sense I'm glad it's not just them, Microsoft gets to have a turn too.
For lots of SMBs their OWA (plus maybe a VPN server and a web site hosted elsewhere) is their only online presence.
With this, you phish or stuff one set of user creds and now you have all their mail spools (plus all third party accounts linked to those emails) and are in a great place to pivot to domain admin.
Probably small accounting firms will be worst hit but also countless other small manufacturing and services firms.
Most of the details I could supply by email but they were so worried that the emails could/would be modified that a lot of this had to be done via snail-mail, and phone-calls where I read out my banking details.
On the one hand very understandable, but on the other very frustrating.
