Silly Example of a Deserialisation Attack

I'm trying to understand a deserialisation attack, so I have thought of this example, if you could correct me if I have misunderstood something, that would be helpful.

I have this fiction class.

public class Player{
    String name;
    int attackStrength;

    public Player(String name){
        this.name = name;
        this.attackStrength = Random.nextInt(10);
    }   
}

If I serialised this class It would provide me with a byte array that represented the object instance and its internal values (name, attackStrength).

This fiction class randomly creates an attack strength with a max value of 10.

If I edited the byte array and read back in. I could modify the bytes that represent attackStrength to 50! and then DeSerialise the array and I now have a hacked character.

Is this the idea behind this form of attack.

Answers


Assuming that Player implemented java.io.Serializable, then deserialisation would bypass the constructor providing it is in an environment where an adversary can supply raw data. This is dealt with in Guideline 8-3 of Secure Coding Guidelines for the Java Programming Language, Version 4.0.


Honestly I've not heard the term "deserialization attack", but yes you are right that would be a security vulnerability.

Any case where you store a file somewhere can edit it then the vulnerability exists. If they are just running on their local machine (single player) then it's not worth worrying about. You can't stop them hacking if they want to.

For multi-player the only way is to make the server authoritative and have it validate everything the player does. You would never let the client tell you their attack strength, you would tell the client.


Need Your Help

Designing a Scala DSL for maven-poms

scala maven dsl

I am thinking about a DSL / domain design to analyse a big bunch of maven dependencies.