ASP.NET MVC

Re: UpdateFrom and Encoding

FCsteve — Tue, 25 Dec 2007 19:00:46 GMT

I'd like it to be overloaded.. but by default I would prefer not to encode..

I can kind of see the reason for the default to be encoded.. defaults targetting the most common scenario.. and I imagine you would love your 'product' to do as much as possible for you by default.. but stay highly custimizable and configurable..

Either way I wouldn't be too bothered what the default is as there is some option.. as otherwise it would just add to the code in .NET that becomes useless outside of its default scenario.. (disclaimer: most of the code in .NET I think it done great)..

My personal argument for the output encoding is that it should be handler by the output generators.. but it would be great if we had a simpler way to do primative output encoding (such as the <%!= idea).

Re: UpdateFrom and Encoding

robconery — Tue, 25 Dec 2007 06:23:22 GMT

damieng:
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.

One thing I'd like to reiterate at this point in the thread is that I completely agree with no encoded data in the DB. My point (and others who like the idea of encoding on input) is that you protect one of the main vectors of XSS attack - regurgitation of input to the screen (search results being one of the main culprits).

So, to be clear: no one is suggesting you must input encoded text into your Db. Especially me. This discussion started with regards to a method that binds an object from Request.Form and the decision to encode/decode being your or ours.

Re: UpdateFrom and Encoding

sergiopereira — Sun, 23 Dec 2007 01:19:24 GMT

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

Re: UpdateFrom and Encoding

damieng — Sat, 22 Dec 2007 18:57:54 GMT

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

Re: UpdateFrom and Encoding

tgmdbm — Sat, 22 Dec 2007 18:36:54 GMT

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.

Re: UpdateFrom and Encoding

Jonathan Holland — Thu, 20 Dec 2007 23:32:11 GMT

damieng:
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!

Apples to Oranges.

Re: UpdateFrom and Encoding

damieng — Thu, 20 Dec 2007 23:25:47 GMT

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

Re: UpdateFrom and Encoding

Jonathan Holland — Thu, 20 Dec 2007 22:55:35 GMT

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.

Re: UpdateFrom and Encoding

damieng — Thu, 20 Dec 2007 22:48:16 GMT

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

Re: UpdateFrom and Encoding

Jonathan Holland — Thu, 20 Dec 2007 22:44:08 GMT

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 :)

Re: UpdateFrom and Encoding

damieng — Thu, 20 Dec 2007 22:40:22 GMT

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

Re: UpdateFrom and Encoding

Jonathan Holland — Thu, 20 Dec 2007 22:18:09 GMT

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.

Re: UpdateFrom and Encoding

ghotiman — Thu, 20 Dec 2007 20:22:31 GMT

SteveSanderson1, I don't care to much what the syntax should be, just that it be different than the current <%= %>. If they change the behavoir of <%= %> then most of the developers who need to be educated on this will never know anything about it. Also, there will be the inconsistant behavior between forms and mvc, or old code will break. If there is a new syntax, it can serve as the talking point for XSS. The new syntax should be easy, I think everyone can agree on that. I just think it should be different.

Re: UpdateFrom and Encoding

SteveSanderson1 — Thu, 20 Dec 2007 18:15:04 GMT

Ghotiman, I certainly agree that education is important. I'd be sad if we force people to type a big trainwreck of punctuation (<%% ... %%>) just to get the behaviour they should "always use". If other developers are as lazy as me, they're just going to press the fewest number of keys needed to say their project is finished, which means <%= ... %> ("seems to work fine").

Re: UpdateFrom and Encoding

ghotiman — Thu, 20 Dec 2007 17:57:34 GMT

I'm not too fond of encoding the input by default for all the reasons already mentioned. I like the idea of adding to <%=%>, but not changing it. As others have said, that would cause some confusion. If something like <%% = %%> did HTML encoding by default it would not break the old model, and it would get used since it's easy. Also, it would be an opportunity to educate developers on XSS. Every one would say to always use <%% = %%> and when devs asked why they could learn about XSS. Education on the matter is probably more important than the framework handling everything.

I also like the idea of having extension methods to handle the different encodings for HTML, XML, and JavaScript. They are discoverable and easy to use.