Javascript security

[Ryan Peters]

Our application uses JavaScript to show/hide buttons and div's that provide information for a user based on their security level. Their level is determined from a database query that is done in either .NET code behind or a web service.

Our concern is that a hacker could modify the JavaScript on their local machine to give them additional security or view additional information. Right now, the application only works with IE, but it will be supported under all browsers in the future.

A couple questions:
1. Is there any way to protect against someone modifying their local js file and then submitting a page?
2. Is this something we should really be concerned about from the js side or should we put more emphasis on validating data on the server side?

Thanks!

[Oralloy]

Ryan,

You should never send information that you don't want the user to see.

Period.

After all, they might just save a copy of the page and inspect the source. Then your "hidden" values would be freely available.

Sending the minimal data content is something which must be programmed into the server side of the application. Unfortunately this complicates your application to some extent.

The alternative is to leave yourself wide open to data theft. Imagine hiding credit card numbers this way?

Cheers.

[Ryan Peters]

Thanks for the reply.

Luckily the information we are displaying for the users is not private data. We are just hiding the data to organize the screen with collapsible panels or based on security level they cannot see some information, but it isn't private data that would relate to data theft.

I'm more concerned about us using AJAX calls to save data and someone manipulating the data and then posting the information back to the server. If we save payment information through an AJAX call and a person owes $100, they could manipulate the javascript and post a $500 payment resulting in a refund of $400. I know we need to do some validation in this example between the client and server, but I would like to try and prevent this somehow from the client if possible.

Thanks!

[Oralloy]

Ryan,

There's no problem with using client side validation to make the site easier to use and (apparently) more responsive to the user's inputs.

And yes, I know that having to validate on the server side is redundant.

In reality, though, it's not redundant. The real validation is server-side, and the client side JavaScript is there to make your application more responsive to the user and more comfortable to use. The JavaScript should be thought of as the redundant code, and not the other way around.

Yes, redundant code is wasteful.

Yes, redundant code can get out of synchronization .

No, you don't need customers just helping themselves to hundreds of dollars, as in your example.

So, write the basic application using server-side validation. Once that works, then implement the AJAX code as polish on top of the working application.

Finally, document the redundancy in your code in both places, so that any one who changes one part will know that they have to change the other as well. (I assume that they will read the documentation, however if there's no documentation, then there is no chance that they'll know to implement the validation in two places).

All that said, I don't know much about AJAX, but I need to learn some things - have you got a good on-line place to start?

Cheers!

[gits]

basically the things that was said are correct - but it was a bit too general, from my point of view. of course there could be some duplicate validation logic ... but there shouldn't. it should be a clear difference between 'business logic' and (UI-)application logic. while the business logic should never be propagated to the client with a JavaScript implementation the app-logic might be propagated. that way it could be avoided to have duplicate code. with ajax you could perform the business validation in the background without a page-reload - so there is no real need to propagate that logic to the client. such propagation would even publish that rules so that a medium skilled user could read that and would see how your business (rules, validation) works, and even could try to exploit it. simple UI checks would help the users - like checking field-types, date-relations or similar ... but a calculation for example should be done serverside. that is just a rule of thumb and the recommendation might vary on the type of the application - for example an intranet app might have different needs/requirements as a public web-app would have.

[Oralloy]

@gits,

Yep, you can use AJAX to invoke validations on the fly for the user. It really will help improve the general behaviour of the application, as well.

But, these are redundant checks, which is fine. They may invoke the same validation routines, but they still have supporting AJAX code to invoke those checks.

The server still needs to check all user inputs before doing any calculations or database updates. Ryan (the author) observed that some smark fellow might reverse engineer his page, bypass the checks, and send a page query with mallicious values.

And yes, you are right. The level of trust is critical. Intranet applications can (reasonably) be more trusting than applications published to the Internet.

Cheers

[gits]

my point was about having a solid business-logic check serverside - so we agree in the main point. having an ajax call to perform checks is far from redundant code ... its just a post of input-params to a serverside controller that exposes a part of the business logic checks. the javascript code just handles a true or false which could be centralized in a validation-class. the only thing that have to be taken into account would be to define clientside 'when' such a check should be performed.

checking basic things like field types etc. could even be centralized - and thus be generic. a datadictionary could be published to the client without risk like:

var dd = {
    fieldId1: 'fieldType',
    fieldId2: 'fieldType'
};

so when a user types something then such things might be checked without any additional code (since we could have a generic one) or doing a request.

so to summarize it: it is a matter of application design and architecture how much redundancy will be created. in some cases it is worth to think about that in others it is not or even useless since the size of the project wouldn't be appropriate enough ... so basically the next rule of thumb would be to handle such thing in a pragmatic way.

anyway: with good design and architecture of an app the clientside validation could be more a matter of configuration instead of programming. so redundancy would be encapsulated without any big drawbacks and when you could centralize it, such things remain in sync ... the only thing could be a missing validation for example ... but this wouldnt invalidate the logic since the final check would be always done serverside. suppose we would have a check like 'take the input of 5 specific fields, calculate something and give a response' - the validation service would process it and could say - 'error, field no.1 is wrong when you have foo in field 4' ... so the central JavaScript error handler would just need to apply the general handling like highlighting the fields and/or showing an error message or whatever - it doesn't implement any 'business rule logic' ... at least it shouldn't. so there is no real redundancy - except in performing the check at all - which is certainly not a big problem ... even when the code is undocumented - it is more a matter of correct requirements. the services itself just need to encapsulate the logic so that our '5 field-validator' would take the input and deliver a 'standardized' response.

as i said - everything rises and falls with the choosen application-architecture ... which is often missing due to trying to be 'agile' or 'extreme' or whatever - and thus such sync-issues or similar will appear since the code starts growing without following any pattern.

[Oralloy]

@gits,

I agree wholheartedly - application architecture makes the entire difference.

Applications that are designed for maintenence and robust behaviour generally achieve it. At, of course, the cost of the initial design cost. Which, I'll observe, is often recaptured during the implementation phase, as a lot of ad-hoc coding is eliminated.

As for Agile programming, it has a place. But if there's no strong, central pilar to build around, it has its limits. I'd hate to see what Linux would look like, done by a X-Programming team from the start.

That said, there's a balance that must be struck - I've seen projects founder because the design process never really completed. Designs usually never finish because of feature creep or management that refuses to decide. A good team has to change focus then and actually nail down the design and impose limits in that case.

Any way, we're diverging. Thank you for your input and insights. I'm starting to use AJAX and RESTful code under JIRA, so I'm rapidly climbing back up the Web tools tree. It's interesting seeing how the field has changed recently; my work is usually with embedded systems.