Preventing Data Corruption Due to User Interface Bugs
Jul 24

Preventing Data Corruption Due to User Interface Bugs

There’s a standard way of handling object updates via HTML forms. Generally speaking, when the user selects an object to edit, you populate an HTML form with all the data from the object, post all these fields when the user presses Submit, then update all the fields of the record with the data in the HTTP request.

So, if I’m going to edit an article, the HTML form contains all the article properties, and — even if I just change one — the SQL that results after I press Submit rewrites ALL the fields with what it receives in the request.

This has always made me just a little nervous because is assumes that the request is perfectly accurate — that it accurately represents what we want the object to become. But is this always the case?

by Deane   July 24, 2004 12:03 AM    |   Follow Gadgetopia on Twitter

Comments

by Kippy,   July 24, 2004 1:31 AM  

I did this very thing, I just had hidden field with MD5's for each string, when it got back to the server, I rechecked the MD5's and updated only the strings that changed (via dynamtic SQL). MD5's are not perfect (1 in 100,000,000), but good enough for my needs. If you had to be 100% sure, just dup the string in a hidden field. Compare when it gets back to the server.

by Jonathan Hollin,   July 26, 2004 7:52 AM  

I tend to read the columns of the record to be changed into a hash (I use Perl), then use a simple "eq" comparison to identify the changes and prepare a dynamic "UPDATE" command before issuing that UPDATE to the DB. It's quick, efficient and very reliable.

by Deane,   July 26, 2004 12:46 PM  

Yes, that addresses the efficiency issue, but what about the problems caused by UI bugs? If you compare the existing object with what's in the request, you still don't find problems caused by a malfunctioning UI.

by Jonathan Hollin,   July 26, 2004 8:06 PM  

"What about the problems caused by UI bugs?"

With all due respect Deane, this shouldn't be an issue at all. The back-end application SHOULD have sufficient integrity checks, input validation, taint checking and error-handling to cope with any failing of the UI.

If this isn't the case, then you have bigger problems to consider: for example, the user (or script) that deliberately submits data that can compromise the database!

Add Comment