# Top 10-2017 A8-Insecure Deserialization , why products does not implement encryption

On trying to understand Deserialization vulnerability, it was observed that serialization is the process of converting a complex object to a byte stream for sending it across networks and is deserialized on the receiver side.

On analysing OWASP TOP A8, it says the IT industry has an high prevalence of this feature being compromised for exploitation.

Question:

Why are products not encrypting the serialized data as discussed in the post below?

Which is better: “serialize and then encrypt” or “encrypt and then serialize”?

• Lack of knowledge, lack of time or money, lack about users, not considering it in the first place, estimating it would be too inefficient, considering enough security is already in place... the list goes on, but we don't know why this decision was (not) made to encrypt in all the various companies. The why question is always hard to answer, and unless somebody has a paper with statistical data, we won't be able to answer the question objectively. – Maarten Bodewes Mar 27 '19 at 11:47
• @PaulUszak I'm leaving it as is, as there may be papers out there that did some research on the subject, using questionnaires and such. But it is certainly in the gray area. – Maarten Bodewes Mar 27 '19 at 13:27

Why are products not encrypting the serialized data as discussed in [#30723]?

Because encryption by itself does not reliably prevent alteration of the data, which is the vulnerability here. As Maarten Bodewes comments in that very Q.

To prevent tampering in general you need -- as OWASP says -- an integrity check, like a MAC or signature. Not encryption. (Although if you have authenticated encryption, which does both encryption and MAC as a combined operation, and in recent years has become more popular and widely available, you might as well use it.)

Now, why don't/didn't people use a MAC or signature (or AE) on data which if altered can be dangerous? That's a good question. To which I don't have a good answer.

• Thanks for the time to reply , I was curious to know why key players like Jenkins , PayPal etc where vulnerable to this attack . Why didn't they use an signature to protect the content . – PDHide Mar 28 '19 at 9:04

Rather than in the top 10, you could say that it's ranked #3, although they do say that exploitation is difficult. There are some raw metrics on Git. OWASP TOP A8 actually refers to un-encrypted object streams, so the debate in "Which is better: “serialize and then encrypt” or “encrypt and then serialize”?" is not entirely on point.

Whilst there is a risk that answers might be opinionated, I'll try to use some concrete logic. And it really does come down to logic v semantics. A common paradigm in IT is:-

1. make it work,
2. make it right,
3. make it fast[*].

Imagine the development of a remote function F that requires serialisation. It adds two streamed parameters and returns the sum. So sum = F(a, b).

Now proceed with development using the above paradigm. Until point #1 is completed, the function does not work. No meeting, screaming or white boarding will help with that as it's a mathematical certainty.

As soon as F returns the correct values, it's working. Step #1 unequivocally complete. That's an easily (unit) tested logical argument. Steps #2 and #3 are therefore semantic arguments without the authority of pure logic. Who is to say what is "right" or "fast"? Throw in an Agile or DevOps mentality ("updated software can be deployed every few days, or even several times per day"[**]) and there is little reason to progress past step #1. Psychological conformism along the lines of Milgram and Zimbardo just means that people unconsciously "do what they are told" anyway. Like move onto the next job when #1 is achieved. Thus no encryption of the stream.

There are other reasons too numerous to mention.

[*] adapted from: ButlerLampson's "Hints for Computer System Design" (1983) http://research.microsoft.com/en-us/um/people/blampson/33-hints/webpage.html and Stephen C. Johnson and Brian W. Kernighan's "The C Language and Models for Systems Programming" in Byte magazine (August 1983).

[**] from https://devops.com/metrics-devops/