Business Logic at the Client

I’m con­stantly amazed at how I can start search­ing for one thing on the web and end up in a totally dif­fer­ent area. This isn’t a giant leap, but it still got me think­ing. I started out search­ing for auto­mated ways of deob­fus­cat­ing javascript. In my role as an inci­dent han­dler, and as a gen­eral geek, I am noth­ing short of elated to see javascripts that con­tain eval fol­lowed by hun­dereds of hex, ascii, uni­code, or html encoded char­ac­ters. I believe that as a stu­dent of com­puter engi­neer­ing and com­puter secu­rity I’m nat­u­rally inclined to be inquis­i­tive. Cur­rently, when­ever I come across a script like this I write a cus­tom perl script to han­dle the source file under inspec­tion. I was think­ing that I should write a “mega” script to han­dle all types of cases that I’ve run into. The prob­lem with that of course is that it’s actual work. And if I were to release it, I’d have to make it mod­u­lar in such a way that it can eas­ily be expanded for addi­tional obfus­ca­tion techniques.

Long story short.… I ended up on a web devel­oper forum where the ques­tion was asked as to how a devel­oper can hide their busi­ness logic from the end user, since it’s in javascript.

Busi­ness logic does NOT belong on the client side!

First of all, any­thing sent to the client can be seen by the client. If the data is sent in a way such that Inter­net Explorer or Fire­fox can under­stand what to do with it, it can be seen and under­stood by a capa­ble ana­lyst. If this logic is your secret sauce, than you absolutely should not just give it away to every GET received on port 80.

Sec­ondly, the secu­rity impli­ca­tions could be huge if any of the data sent back to the server is trusted. Since this per­son is putting their logic in client side code, it would not sur­prise me to find out that the server side code trusts the data it receives from the busi­ness logic with­out check­ing for valid val­ues, length, etc. By using a sim­ple pro­gram such as Paros Proxy it is pos­si­ble for a mali­cious end user to inter­cept and mod­ify all val­ues both incom­ing and out­go­ing. A capa­ble user could set the results of the busi­ness logic to be what­ever value they wanted, skip­ping all of the client side data val­i­da­tion techniques.

Finally, the big pic­ture that is painted by this lit­tle exam­ple is that an appli­ca­tion, espe­cially a web appli­ca­tion, should never trust ANY input from the client. Client side val­i­da­tion is con­sid­er­ate for the end user, but does noth­ing in terms of secur­ing the site. All data to be processed by the appli­ca­tion needs to be val­i­dated and cleansed on the server side. This even goes so far as to val­i­date HTTP Header fields if they are to be used. There is noth­ing stop­ping a per­son from chang­ing any value in the HTTP sec­tion of the packet to any other arbi­trary value. As would hope­fully be the norm, always val­i­date against a whitelist when­ever pos­si­ble. It’s much safe to know exactly what type of infor­ma­tion you’re expect­ing rather than try­ing to guess to next mali­cious value the attack­ers will discover.

So remem­ber, don’t trust client data, and val­i­date, val­i­date, validate!