Monday, March 26, 2012

Protecting javascript based on role

To set up what i am going to ask, allow me to explain the page:

I've got a page that shows reports with a popup panel that has all sorts of options on it.... when i first load the page, i show/hide/fill these options based on Roles

The page does not do any post backs, just javascript calls to webservices and i show the report data based onthis blog post by Scott Guthrie (using a page instance, a user control and generating/grabbing the HTML)....

In the aspx markup of the page is hundreds of lines of javascript i have written over the past week, and what i am realizing is that all the script is there for the world to see regardless of role....

So where i may say: $get('drpManager') , that is a control that is only available to certain role (i set visible and enabled to false if the user isn't allowed to see it), but just seeing that in the code, a malicious user may be able to figure out how to do something that they shouldn't be allowed to...

So what I am asking/wondering is maybe some ideas to package the javascript, broken up into role specific functionality, into the page execution and spit it out (this cried out WebResource and ScriptManager.RegisterScript) based on role

Any thoughts on this or pointers?

Unfortunately ( and I hope someone with greater knowledge than I will lambast me for saying something inaccurate)... is no - there is no such thing as security when it comes to scripts. This is the only primary reason I handle everything from the server side when it comes to security specific issues...You can however authenticate using the profile feature of Ajax...but even if you use any of the number of javascript encryptors available (most will not work with Ajax anyways). You will be exposing your logic to those whom realize that you are doing something sensistive..

Naturally you could could create seperate javascripts depending on the role it would be more secure - but if you are using anything Ajax in a security related enviroment - it is my recomended best practice handle it serverside and not clientside... the less the client knows what is going on means the less a hacker knows what is going on... Ajax is afterall just a tool... and security wise - its is the the subject of numerous related security articles because there really is no framework to protect against plain text script... but I would not rely on a global and executing based upon parameters sent to the client on the client...if you must and refuse to do the stuff server side and take the perf hit while maintaining the ajax ui glitz for the customer... then send only the scripts to the client that are related for the role they have...


jodywbcb:

then send only the scripts to the client that are related for the role they have...

Apparently you missed the whole entire point of my topic and the question i asked at the very end, as the above line by you that i quoted is exactly what i was asking for ideas onhow to do...

I wasn't asking for page architecture advice... the page is big and it's fast as hell and getting/updated/refreshing sections of the report piece by piece via AJAX, which absolutely is the best way for this page to serve it's existance, now i am just asking about steps, even if it's just a little step, on keeping code out that a lesser role doesn't need

No comments:

Post a Comment