Security/Validation on c# property change N-Tier

Question

I have a class that keeps track of Property Changes

public class Property
        {
            object _OriginalValue;
            object _ProposedValue;
            DateTime _ProposedDateTime;
            List<Property> _History = new List<Property>();
            public object OriginalValue
            {
                get
                {
                    return _OriginalValue;
                }

                set
                {
                    _OriginalValue = value;
                }
            }
            public object ProposedValue
            {
                get
                {
                    return _ProposedValue;
                }

                set
                {
                    _ProposedDateTime = DateTime.Now;
                    _ProposedValue = value;
                }
            }
            public bool IsDirty
            {
                get
                {

                    if (OriginalValue != ProposedValue)
                    {
                        return true;
                    }
                    else
                    {
                        return false;
                    }
                }
            }
        }

This property can be used by classes like

 public class Customer
        {
            protected Property _FirstName = new Property();
            public string FirstName
            {
                get
                {
                    return (string)_FirstName.ProposedValue;
                }

                set
                {
                    _FirstName.ProposedValue = value;
                }
            }

            public object GetOriginalValue(Property Property)
            {
                return Property.OriginalValue;
            }

        }

The question is, is there a way to secure the original value when passing this to a client in an N-Tier architecture?

When a client passes a Customer back into the Service Boundary - by default you can't trust the client. You need to either reload the original values from the database or validate that the original values are untampered. Of course I'm assuming we're going to use business logic based on the current values in the customer to reject or allow an update operation.

Example:

User inserts record with Name Bob.

User fetches record with Name Bob and changes name to Ted. Original Value is Bob, proposed Value is Ted.

User sends Customer to Service to Update Customer.

Everything is good.

*A business rule is now coded into the service that says if the customer's name is Ted - allow the update else throw "unable to update" exception. *

User fetches record with name Ted. User changes name to Darren. User changes name back to Ted - system throws exception. User fetches Ted. User cheats and uses a tool to change the OriginalPropertyValue on the client. The server doesn't refetch the OriginalValue from the database and simply reads the OriginalValue coming from the client.

User bypasses business rule.

Answer 1

Actually there're more issues with your approach than just checking if original value hasn't been tampered. For example, I suspect that's a multi-user environment where more than an user would be able to edit the same object. That is, the original value mightn't be tampered, but changed before other has already saved a new original value in the database.

I guess you're already applying some kind of optimistic or pessimistic locking on your data...

About your actual concern, probably you need to sign your original value, and whenever you're going to store those objects back in the database, your application layer should check that original value hasn't been tampered (from Wikipedia):

Digital signatures are a standard element of most cryptographic protocol suites, and are commonly used for software distribution, financial transactions, contract management software, and in other cases where it is important to detect forgery or tampering.