It absolutely baffles me to think that anyone would encourage default encoding. I know not everyone here has worked in PHP, but that language is a unorganized mess because of features such as "Magic_Escape_Strings" and "strip_Slashes" etc. The lesson learned?
Leave the encoding to be done by the developer, not the framework implementation.
We are all professionals here right? There is no need for hand holding.
It is incredibly easy to miss or forget with alternate syntax, especially if you also maintain ASP.NET which won't have the new syntax. If you could rely on everybody being professional you wouldn't have this problem - the fact is you can't rely on that.
As for hand-holding the fact is the majority of the time <%= %> is used to output simple text not HTML building.
I believe that the only responsibility of Microsoft is to provide the means to encode and decode HTML. The responsibility to use it is placed at the feet of the developer.
Sure, ignorance leads to crappy, vulnerable sites....But that is not Microsoft's fault, and that is not really their problem. As you can see from the PHP community, default features such as this only provide a false sense of security and enable the crappy
developer to continue to develop crappy sites. It does not magically turn them into good developers. Would you tell the ADO.NET team to only allow parameterized queries? Every decent developer knows better than using string concatenation to build a query,
but you will never be able to convince the ADO.NET team that removing the ability to do queries that way is a good idea.
I want a framework, not a set of training wheels without a bike.
I think then you are missing the point of .NET with it's sandboxed VM, code access security, type safety, bounds checking, pointerless operations, garbage collection, trust levels...
I think then you are missing the point of .NET with it's sandboxed VM, code access security, type safety, bounds checking, pointerless operations, garbage collection, trust levels...
[)amien
Your right, lets just add Html Encoding at the CLR level. Encode all strings!
I'm all in favour of trying to eliminate all those poorly developed sites. And if we can take a huge bite out of them by html encoding on input then it's possibly not such a bad idea.
However, I'm developing a WinForms interface which accesses the same database so encoding on input is obviously not an option.
The question then is "which to do by default?".
Well, if encode on input is OFF by default, will a novice turn it on? I'm not so sure that they would. If they are lazy enough not to bother about security they aren't even going to care that such an option exists.
If it's ON by default, will we turn if off? Of course we will. We'll check the comments of our web.config and turn it off. All we need is good documentation!
To be honest I'm not too concerned about which way they implement it as long as its extensible, overridable, configurable, and most of all it should be obvious what it's doing.
I presume you mean encode on output - I'd agree with the sentiments.
Encode on input is so very very wrong it's hard to put it into words. You would be forcing developers to do the wrong thing on input, and the wrong thing on output (no encoding) which means they'll be used to no encoding and when they pick up content that
hasn't processed through your input encoder is wide open for attack again.
Great thread. Nice to see how this discussion was brought back from a down spiral.
I'd like to add that although security is a cross-cutting concern,
it needs to be dealt in each component at the component's context. By that I mean, if the UI needs to be secure (it does) then UI security measures need to be taken in the UI code (HtmlEncode in the outputs for example), never let UI concerns happen at
the controller level (if you see any HtmlEncode calls in the controller code, think about it a little more.) And, please, no UI encoded stuff in my database, OK? :)
An example of security concern that could be dealt at the controller level would be to inspect the user input before assigning it to the models and later to the database. In practical terms a good example of that is making sure only the fields you expect
to be in the Response.Form gets populated in the model, so be careful on how you use myModel.UpdateFrom(Request.Form) so that you don't allow hand-crafted form posts to update sensitive properties.
All in all, I think we are all getting to the same page now.
Jonathan Hol...
Member
41 Points
11 Posts
Re: UpdateFrom and Encoding
Dec 20, 2007 09:18 PM|LINK
It absolutely baffles me to think that anyone would encourage default encoding. I know not everyone here has worked in PHP, but that language is a unorganized mess because of features such as "Magic_Escape_Strings" and "strip_Slashes" etc. The lesson learned? Leave the encoding to be done by the developer, not the framework implementation.
We are all professionals here right? There is no need for hand holding.
damieng
Member
38 Points
16 Posts
Re: UpdateFrom and Encoding
Dec 20, 2007 09:40 PM|LINK
It is incredibly easy to miss or forget with alternate syntax, especially if you also maintain ASP.NET which won't have the new syntax. If you could rely on everybody being professional you wouldn't have this problem - the fact is you can't rely on that.
As for hand-holding the fact is the majority of the time <%= %> is used to output simple text not HTML building.
[)amien
Jonathan Hol...
Member
41 Points
11 Posts
Re: UpdateFrom and Encoding
Dec 20, 2007 09:44 PM|LINK
So if you must have default encoding, what is so hard about default being off, and just having a config section in web.config for it?
It seems like the convention over configuration concept is being taken too far, configuration files are not all that bad :)
damieng
Member
38 Points
16 Posts
Re: UpdateFrom and Encoding
Dec 20, 2007 09:48 PM|LINK
We can surely agree the root of the problem is ignorance?
In which case defaulting to off or alternate syntax achieves nothing.
They didn't know HttpUtility.HtmlEncode and now they won't know <page defaultOutput="Encoded" /> either.
[)amien
Jonathan Hol...
Member
41 Points
11 Posts
Re: UpdateFrom and Encoding
Dec 20, 2007 09:55 PM|LINK
I believe that the only responsibility of Microsoft is to provide the means to encode and decode HTML. The responsibility to use it is placed at the feet of the developer.
Sure, ignorance leads to crappy, vulnerable sites....But that is not Microsoft's fault, and that is not really their problem. As you can see from the PHP community, default features such as this only provide a false sense of security and enable the crappy developer to continue to develop crappy sites. It does not magically turn them into good developers. Would you tell the ADO.NET team to only allow parameterized queries? Every decent developer knows better than using string concatenation to build a query, but you will never be able to convince the ADO.NET team that removing the ability to do queries that way is a good idea.
I want a framework, not a set of training wheels without a bike.
damieng
Member
38 Points
16 Posts
Re: UpdateFrom and Encoding
Dec 20, 2007 10:25 PM|LINK
I think then you are missing the point of .NET with it's sandboxed VM, code access security, type safety, bounds checking, pointerless operations, garbage collection, trust levels...
[)amien
Jonathan Hol...
Member
41 Points
11 Posts
Re: UpdateFrom and Encoding
Dec 20, 2007 10:32 PM|LINK
Your right, lets just add Html Encoding at the CLR level. Encode all strings!
Apples to Oranges.
tgmdbm
Contributor
4392 Points
883 Posts
ASPInsiders
MVP
Re: UpdateFrom and Encoding
Dec 22, 2007 05:36 PM|LINK
I'm all in favour of trying to eliminate all those poorly developed sites. And if we can take a huge bite out of them by html encoding on input then it's possibly not such a bad idea.
However, I'm developing a WinForms interface which accesses the same database so encoding on input is obviously not an option.
The question then is "which to do by default?".
Well, if encode on input is OFF by default, will a novice turn it on? I'm not so sure that they would. If they are lazy enough not to bother about security they aren't even going to care that such an option exists.
If it's ON by default, will we turn if off? Of course we will. We'll check the comments of our web.config and turn it off. All we need is good documentation!
To be honest I'm not too concerned about which way they implement it as long as its extensible, overridable, configurable, and most of all it should be obvious what it's doing.
damieng
Member
38 Points
16 Posts
Re: UpdateFrom and Encoding
Dec 22, 2007 05:57 PM|LINK
I presume you mean encode on output - I'd agree with the sentiments.
Encode on input is so very very wrong it's hard to put it into words. You would be forcing developers to do the wrong thing on input, and the wrong thing on output (no encoding) which means they'll be used to no encoding and when they pick up content that hasn't processed through your input encoder is wide open for attack again.
[)amien
sergiopereir...
Member
227 Points
61 Posts
Re: UpdateFrom and Encoding
Dec 23, 2007 12:19 AM|LINK
Great thread. Nice to see how this discussion was brought back from a down spiral.
I'd like to add that although security is a cross-cutting concern, it needs to be dealt in each component at the component's context. By that I mean, if the UI needs to be secure (it does) then UI security measures need to be taken in the UI code (HtmlEncode in the outputs for example), never let UI concerns happen at the controller level (if you see any HtmlEncode calls in the controller code, think about it a little more.) And, please, no UI encoded stuff in my database, OK? :)
An example of security concern that could be dealt at the controller level would be to inspect the user input before assigning it to the models and later to the database. In practical terms a good example of that is making sure only the fields you expect to be in the Response.Form gets populated in the model, so be careful on how you use myModel.UpdateFrom(Request.Form) so that you don't allow hand-crafted form posts to update sensitive properties.
All in all, I think we are all getting to the same page now.
- sp
Sergio Pereira
http://devlicio.us/blogs/sergio_pereira/