How to prevent hacking if users change html/javascript variables on client side?_问答_开发者

Using a simple tool like FireBug, anyone can change javascript parameters on the client side. If anyone t开发者_运维技巧ake time and study your application for a while, they can learn how to change JS parameters resulting in hacking your site.

For example, a simple user can delete entities which they see but are not allowed to change. I know a good developer must check everything on server side, but this means more overhead, you must do checks with data from a DB first, in order to validate the request. This takes a lot of time, for every action someone must validate it, and can only do this by fetching the needed data from DB.

What would you do to minimize hacking in that case?

A more simple way to validate is to add another parameter for every javascript function, this parameter must be a signature between previous parameters and a secret key.

How good sounds the solution above to you?

Our team use teamworkpm.net to organize our work. I just discovered that I can edit someone else tasks by changing a javascript function (which initially edit my own tasks).

when every function call to server, in server side before you do the action , you need to check if this user is allowed to do this action.

It is necessary to build server-side permissions mechanism to prevent unwanted actions, you may want to define groups of users, not individual user level, it makes it easier.

Anything on the client side could be spoofed. If you use some type of secret key + parameter signature, your signature algorithm must be sufficiently random/secure that it cannot be reverse engineered.

The overhead created with adding client side complexity is better spent crafting proper server side validations.

What would you do to minimize hacking in that case ?

You can't work around using validation methods on the server side.

A more simple way to validate is to add another parameter for every javascript function, this parameter must be a signature between previous parameters and a secret key.
How good sounds the solution above to you ?

And how do you use the secret key without the client seeing it? As you self mentioned before, the user easily can manipulate your javascript, and also he can read everything in javascript, the secret key, too!

You can't hide anything in JavaScript, the only thing you can do is to obscure things in JavaScript, and hope nobody tries to find out what you try to hide.

This is why you must validate everything on the server. You can never guarantee that the user won't mess about with things on the client.

Everything, even your javascript source code is visible to the client and can be changed by them, theres no way around this.

There's really no way to do this completely client-side. If the person has a valid auth cookie, they can craft any sort of request they want regardless of the code on the page and send it to your server. You can do things with other, encrypted cookies that must sent back with the request and also must match the inputs on the page, but you still need to check this server-side. Server-side security is essential in protecting your application from unauthorized access and you must ensure, server-side, that every action being performed is one that the user is authorized to perform.

You certainly cannot hide anything client side, so there is little point in trying to do so.

If what you are saying is that you are sending something like a user ID and you want to ensure that the returned value has not been illicitly changed then the simplest way of doing so it probably to generate and send a UUID alongside it, and check on return that the value of the uuid matched that stored on the server for the userID before doing any further processing. The space for uuid's is so large that you can discount any false hits ever occurring.

As to actual server side processing vulnerabilities:- you should simply always build in your security/permissions as close to the database as you can, and defiantly not in the client. There's nothing different in the scenario you outline from any normal client-server design.

Peter from Teamworkpm.net here - I'm one of the main developers and was concerned to come across this report about a security problem. I checked into this and I am happy that is not possible to delete a task that you shouldn't have access to.

You get a message saying "You do not have permission to delete this task".

I think it is just the confusion between being a Project Administrator and being an overall Administrator that is the problem here :- You may not be a member of a project but as an overall administrator, you still have permission to delete any task within your Teamwork site. This is by design.

We take security very seriously and it's all implemented server side because as Jens F says, we can't reply on client side security.

If you do come across any issues in TeamworkPM that you would like to discuss, we'd encourage any of you to just hit the feedback link and you'll typically get an answer within a few hours.