1
$\begingroup$

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”?

Improve this question
$\endgroup$
2
  • 2
    $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Commented Mar 27, 2019 at 11:47
  • $\begingroup$ @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. $\endgroup$
    – Maarten Bodewes ♦
    Commented Mar 27, 2019 at 13:27

2 Answers 2

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • $\begingroup$ 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 . $\endgroup$
    – PDHide
    Commented Mar 28, 2019 at 9:04
0
$\begingroup$

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/

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.