#SuperGoalingBros – OWASP Study – 8. Insecure Deserialisation

Insecure Deserialisaton is a new addition to the OWASP Top Ten and is pretty crafty.

When an object is stored or transported it is often translated or serialised into a format that can be moved more easily.

Once the serialised object has reached its destination it is then deserialised and translated back into its original format.

Hacker1

This works well if the serialisation/deserialisation process is secure and proper checks are in place to make sure that the file being deserialised is the same as it was when it was serialised in the first place.

The best analogy I can think of is when you get stopped at an airport security and they ask “did you pack your own bags?

You needed to transport your belongings from one place to another, so you placed them into a bag (serialisation). You know what you put into the bag and all of the items you added passed your checks.

However, if you didn’t have a lock on your bag what would stop someone slipping something in when you weren’t looking? Another shirt, an oversized/weight item, an explosive device, or a couple of kilos of cocaine?

Then when you or airport security open your bag (deserialisation) you could find yourself in trouble.

How did that get in there?


I’ve found a couple of good videos to explain here and here:


Example

According to this article, Hackers were able to take advantage of a deserialisation vulnerability in Jenkins servers which allowed them to install crypto-mining software into unknowing Windows users machines letting them haul in over USD$3million worth of Monero!


Ways to avoid suffering Insecure Deserialisation Attacks

  • Validate data being serialised and deserialised
  • Create a whitelist for trusted sources of serialised objects
  • Incorporate digital signatures or other integrity checks
  • Ensure that the serialised object is encrypted in transit and in storage
  • Add type constraints to the serialisation/deserialistaion process so any type that doesn’t match the criteria is rejected.
  • Use non-standard data formats
  • Patch regularly

Thanks for reading, my next post will be about OWASP item #9 Using Known Vulnerabilities

I have created an account to track my goals on Habitica, if you would like to find/add me my user id is: b2d1d942-f62b-4487-a77b-58c8a93baa9c


Disclaimer: My posts for this project reflect my own understanding of the topics, if I’ve missed the point completely please pull me up and correct me in the comments section and I’ll fix it up asap. Also, if you know of any examples of the vulnerability and how best to protect against it please share 🙂

Advertisements

2 thoughts on “#SuperGoalingBros – OWASP Study – 8. Insecure Deserialisation

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: