Hi, I had a question about javascript. Since it is clientside can a user modify the contents of my scripts. For example I am using jquery's css() command to disable a button if a user is not logged in. Can a user access this and change it so the button is enebaled? thanks
security of javascript
Page 1 of 12 Replies - 265 Views - Last Post: 13 March 2012 - 02:38 AM
Replies To: security of javascript
#2
Re: security of javascript
Posted 10 March 2012 - 04:55 PM
Yes. Actually both Chrome and FireFox can use a plugin like Firebug to make on the fly edits to javascript.
Also keep in mind that a user can save your page (with its javascript), alter it locally and then use their version of your page to send stuff to your server.
In other words, Javascript should accent your page, not act as its security. In general you can validate client side but you always have to have the same security server side. Never rely on javascript as your only means of security.
Also keep in mind that a user can save your page (with its javascript), alter it locally and then use their version of your page to send stuff to your server.
In other words, Javascript should accent your page, not act as its security. In general you can validate client side but you always have to have the same security server side. Never rely on javascript as your only means of security.
This post has been edited by Martyr2: 10 March 2012 - 04:56 PM
#3
Re: security of javascript
Posted 13 March 2012 - 02:38 AM
Martyr2 is on the money here. Javascript and security are two words that don't mix. Javascript should only be used for the convenience of client-side user interface.
Good examples of the use of Javascript that don't require server-side support are:
More good examples that require server-side validation are:
In my application, there is only one way in which sensitive data is exposed to client-side, and that is when data needs to be delivered to the client for the return trip to the server. This data is always always encrypted heavily on server-side before making the round trip. I thought long and hard before doing this, and it took weeks of preparation and server-side securing before I was happy to incorporate this into my Javascript. The only reason I am comfortable doing this is because I use a very strong encryption algorithm which is further supported with an initialisation vector. I would not suggest doing this unless you are very confident with your approach to the problem.
Always rely on Javascript being insecure, and your users being malicious - that way you will protect yourself from dire outcomes.
Good examples of the use of Javascript that don't require server-side support are:
- Animating
- document.ready support to ensure elements are loaded before being made dynamic
- Displaying/hiding elements of the page
More good examples that require server-side validation are:
- Highlighting a form field before submission when it is a required field
- Validating a field of a form (e.g. - numbers/numerics only in a numeric field)
- Preparing meta-data into a JSON object to pass to serevr-side
In my application, there is only one way in which sensitive data is exposed to client-side, and that is when data needs to be delivered to the client for the return trip to the server. This data is always always encrypted heavily on server-side before making the round trip. I thought long and hard before doing this, and it took weeks of preparation and server-side securing before I was happy to incorporate this into my Javascript. The only reason I am comfortable doing this is because I use a very strong encryption algorithm which is further supported with an initialisation vector. I would not suggest doing this unless you are very confident with your approach to the problem.
Always rely on Javascript being insecure, and your users being malicious - that way you will protect yourself from dire outcomes.
Page 1 of 1
|
|

New Topic/Question
Reply



MultiQuote




|