murrah
22 Dec 2007, 3:46 PM
Hi,
Like most Ext developers, I want to ensure that my application is as secure as possible. I would also like everyone else's applications to be secure so that there is a reduced possibility of some future popular Ext based web site allowing hackers to steal user's data with the consequence that the media goes into overdrive saying Ext is dangerous. This might cause us to lose users or at least make them nervous when they see the "Loading ..." message.
I stress that I recognise that there is nothing inherent in Ext that makes it more or less secure than any other client-side framework. It is just that we have chosen Ext as our environment so why not be proactive and educate Ext and non-Ext users as well?
As a new developer I have trawled through the net looking for info about making my site secure. I found some good info and some "bad" info and no detailed "advisory" that I could follow especially as it relates to Ajax etc. I think it is in all our interests to have such a document and it would add to Ext's already high standing if the considerable knowledge of the Ext developers and users was harnessed to create such a document for Ext and non-Ext users alike.
Perhaps such a document exists already - if so can someone point me at it please?
With that in mind, I wanted to start the discussion about such an advisory with the aim of collaboratively creating one. I imagine that it should be on the wiki but for now I thought a forum post was a good way to discuss it. The first step (in my mind) is to agree on the guiding principles. Once they are established, the document could provide some clear examples of how to implement the measures by providing some server-specific examples (Coldfusion, PHP, ASP, etc). Hopefully, this will reduce the number of insecure sites.
So, here is my start. Please suggest corrections and rewordings as appropriate. I am by no means an expert in this subject and that is why I want this information to be accurate.
-----------------------
Preamble:
As web developers we have a responsibility to protect our user's data. There are a number of potential security risks that you might create when writing a web site. The Ext Javascript framework is no more or less secure than any other client-side framework. The following information is provided in the belief that a better understanding of the potential security risks and the steps that can be taken to prevent exploitation of those risks will enhance the confidence of the general public when using web sites such as the ones that we create using Ext.
The risks:
The level of risk depends upon the kind of web site you are writing.
1. If your web site does not get any data from some kind of dynamic data store (eg a database or someother web server) and is not using a server side environment like Coldfusion or PHP or ASP, then you probably dont need any kind of security. (Is this a true statement?)
2. If your web site does get data from some kind of dynamic data store (eg a database or someother web server) you will want to take steps to protect that data store. For example, to stop someone corrupting or deleting the data. This is the case even if your web site does not have authenticated users - ie is open to anyone to use.
3. If your users do need to authenticate before using your web site then you will be using some kind of dynamic data store so see point 2 above. In addition, you will want to protect the data so that only legitimate users can access the data they are permissioned to see. Everyone else (including bots) should be "locked out".
Guiding principles:
These are the overall principles and are explained in more detail below.
Server-side:
1. Never trust data from a client (eg form variables or url parameters).
2. Always validate and clean incoming data before using the data (eg before committing to a database)
3. Make sure the data you send from your server is exactly what you intend to send.
Client-side:
1. Validate data as it is entered by the user. This will do nothing to make the site more secure since client-side validation can easily be circumvented but it will do two things:
a. enhance your user's experience of the site
b. if your client side validates that a field should be an integer (for example) and your server-side validation picks up a non-integer value for that field, either your validation failed or someone hacked around it. Either way, this is good information to know on your server-side.
2. If the data is not coming from your server, validate and clean before using it and especially before rendering it to avoid the risk of JS injection. If, for any reason, you cant trust your own server, you will need to treat your server as if it is a 3rd party provider and validate and clean that data before using it and especially before rendering it to avoid the risk of JS injection.
Suggested techniques:
To be written once the principles are agreed to. Possible headings are:
Using Ext to validate user input
Validating and cleaning data server side (examples/links for CF, PHP, ASP, etc)
Ensuring that server data is sent to legitimate users (examples/links for CF, PHP, ASP, etc)
User authentication and permissions (examples/links for CF, PHP, ASP, etc)
Using Ext to clean incoming data
etc...
Like most Ext developers, I want to ensure that my application is as secure as possible. I would also like everyone else's applications to be secure so that there is a reduced possibility of some future popular Ext based web site allowing hackers to steal user's data with the consequence that the media goes into overdrive saying Ext is dangerous. This might cause us to lose users or at least make them nervous when they see the "Loading ..." message.
I stress that I recognise that there is nothing inherent in Ext that makes it more or less secure than any other client-side framework. It is just that we have chosen Ext as our environment so why not be proactive and educate Ext and non-Ext users as well?
As a new developer I have trawled through the net looking for info about making my site secure. I found some good info and some "bad" info and no detailed "advisory" that I could follow especially as it relates to Ajax etc. I think it is in all our interests to have such a document and it would add to Ext's already high standing if the considerable knowledge of the Ext developers and users was harnessed to create such a document for Ext and non-Ext users alike.
Perhaps such a document exists already - if so can someone point me at it please?
With that in mind, I wanted to start the discussion about such an advisory with the aim of collaboratively creating one. I imagine that it should be on the wiki but for now I thought a forum post was a good way to discuss it. The first step (in my mind) is to agree on the guiding principles. Once they are established, the document could provide some clear examples of how to implement the measures by providing some server-specific examples (Coldfusion, PHP, ASP, etc). Hopefully, this will reduce the number of insecure sites.
So, here is my start. Please suggest corrections and rewordings as appropriate. I am by no means an expert in this subject and that is why I want this information to be accurate.
-----------------------
Preamble:
As web developers we have a responsibility to protect our user's data. There are a number of potential security risks that you might create when writing a web site. The Ext Javascript framework is no more or less secure than any other client-side framework. The following information is provided in the belief that a better understanding of the potential security risks and the steps that can be taken to prevent exploitation of those risks will enhance the confidence of the general public when using web sites such as the ones that we create using Ext.
The risks:
The level of risk depends upon the kind of web site you are writing.
1. If your web site does not get any data from some kind of dynamic data store (eg a database or someother web server) and is not using a server side environment like Coldfusion or PHP or ASP, then you probably dont need any kind of security. (Is this a true statement?)
2. If your web site does get data from some kind of dynamic data store (eg a database or someother web server) you will want to take steps to protect that data store. For example, to stop someone corrupting or deleting the data. This is the case even if your web site does not have authenticated users - ie is open to anyone to use.
3. If your users do need to authenticate before using your web site then you will be using some kind of dynamic data store so see point 2 above. In addition, you will want to protect the data so that only legitimate users can access the data they are permissioned to see. Everyone else (including bots) should be "locked out".
Guiding principles:
These are the overall principles and are explained in more detail below.
Server-side:
1. Never trust data from a client (eg form variables or url parameters).
2. Always validate and clean incoming data before using the data (eg before committing to a database)
3. Make sure the data you send from your server is exactly what you intend to send.
Client-side:
1. Validate data as it is entered by the user. This will do nothing to make the site more secure since client-side validation can easily be circumvented but it will do two things:
a. enhance your user's experience of the site
b. if your client side validates that a field should be an integer (for example) and your server-side validation picks up a non-integer value for that field, either your validation failed or someone hacked around it. Either way, this is good information to know on your server-side.
2. If the data is not coming from your server, validate and clean before using it and especially before rendering it to avoid the risk of JS injection. If, for any reason, you cant trust your own server, you will need to treat your server as if it is a 3rd party provider and validate and clean that data before using it and especially before rendering it to avoid the risk of JS injection.
Suggested techniques:
To be written once the principles are agreed to. Possible headings are:
Using Ext to validate user input
Validating and cleaning data server side (examples/links for CF, PHP, ASP, etc)
Ensuring that server data is sent to legitimate users (examples/links for CF, PHP, ASP, etc)
User authentication and permissions (examples/links for CF, PHP, ASP, etc)
Using Ext to clean incoming data
etc...