http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Html-encoding on input is a an example of a badly-leaked abstraction that creates a variety of downstream problems. The leak itself is that you've allowed the fact that your resulting presentation is html-based to leak into the data captured in your database. If your presentation technology requires that application data be encoded for display, encode it only at the point of displaying it. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment18http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment18Fri, 21 Dec 2007 17:35:09 GMTI would love it if the default behaviour of <%= ... %> was to HTML-encode the result, since that's (a) safe and (b) what you want 90% of the time. Why should the default be to do a dangerous and unusual thing? Here's a quick mechanism for changing the <%= ... %> behaviour yourself: [http://blog.codeville.net/2007/12/19/aspnet-mvc-prevent-xss-with-automatic-html-encoding/](http://blog.codeville.net/2007/12/19/aspnet-mvc-prevent-xss-with-automatic-html-encoding/) The nice thing about the above method is that the developer doesn't even need to choose whether or not to encode the output the vast majority of times - the decision is made in terms of the parameter passed. Normal strings are encoded, but the output from HTML helper methods isn't. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment17http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment17Fri, 21 Dec 2007 15:06:24 GMTOk, it seems my conceptual problem is with levels of abstraction. I do not have to pass paramaters by hand, I would definitely pass parameters NHibernate or my own NIH framework. But the lowest level (ADO.NET, ASP.NET markup) should be as simple as a blackboard -- I do not want to configure and mess with it, I want to build on it. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment16http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment16Fri, 21 Dec 2007 13:26:25 GMTAndrey, Implementing simple security may be simple to implement, but it is _t_e_d_i_o_u_s_. Passing parameters to the DB is a good example of _very_ tedious coding. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment15http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment15Fri, 21 Dec 2007 07:43:33 GMT> 1/ I am using ASP.Net in web world for 99.9% of the time. All considerations for that should take this into account. I have no issue in making it harder to use if for other stuff is I get better results for the web. This is where I have no arguments but still would never agree. I can not think of a place in ASP.NET basic markup that is specifically made for HTML. I may like to generate CSS, I may even like to generate JS. They are Web as well, just with different mime types. > 2/ Saying that secure by default makes is "too easy to forget about more advanced steps that could cause the same breaches" means that you are now putting _all_ the burden on the developer. They will be so busy implementing the simple layer of security that they will never have time to the more advance scenarios. No, because I am saying that simple security should be also simple to implement and be the default best practice aproach (but not framework-enforced default). Like using SqlCommand arguments in ADO.NET is an easy best practice to prevent SQL Injection (which may occasionally teach developer on what the SQL Injection is). It is not too hard to write <%= H( unsafeHere ) %> each time you want to escape something, isn't it? You have worked with framework that likes to think for you and hide simple details -- that's ASP.NET Web Forms. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment14http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment14Fri, 21 Dec 2007 07:37:47 GMTBrain, Thanks, fixed. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment13http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment13Fri, 21 Dec 2007 01:12:30 GMTBut my security is already alerted to look for cross eyed scripts! http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment12http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment12Fri, 21 Dec 2007 01:10:31 GMTtypeo... XSS is cross-site scripting, not cross-side. :) http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment11http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment11Fri, 21 Dec 2007 01:07:36 GMTI agree with the proposition. How often do you have the opportunity to pick the safer approach by design.... @matei It would be simpler to add an extension method: public static string H(this Control control, string text){ return HttpUtility.HtmlEncode(text); } Then your pages/ascx: (provided the namespace was included in your pages or web.config) <%= H( unsafeHere ) %> http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment10http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment10Fri, 21 Dec 2007 01:07:33 GMTEncoding on input is totally unnecessary and causes confusion and problems trying to understand what to output. It's not just HTML but " ' <> etc. A lot of people have ' in their name and if people have written HTML 4 style entities such as <input value='<%=Something%>'> then something can easily break out without the encoding. [)amien http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment9http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment9Thu, 20 Dec 2007 23:10:11 GMTKiliman, Good point, and I agree. But I would rather have "dirty input" problem rather than security issues. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment8http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment8Thu, 20 Dec 2007 22:28:13 GMTAndrey, 1/ I am using ASP.Net in web world for 99.9% of the time. All considerations for that should take this into account. I have no issue in making it harder to use if for other stuff is I get better results for the web. 2/ Saying that secure by default makes is "too easy to forget about more advanced steps that could cause the same breaches" means that you are now putting _all_ the burden on the developer. They will be so busy implementing the simple layer of security that they will never have time to the more advance scenarios. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment7http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment7Thu, 20 Dec 2007 22:26:43 GMTMatei, That is possible, it is just six times as awkward as simple <%= %> http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment6http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment6Thu, 20 Dec 2007 22:18:05 GMTSorry, that should be AT&amp;amp;T But you get the point. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment5http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment5Thu, 20 Dec 2007 22:07:28 GMTSecure by default is an approach I tend to disagree with (though I like 'easily securable'). I see two problems with it. The first one is that framework should not do too much assumptions about my code. The ASP.NET likes to assume that < and > are dangerous, and it is extremelly annoying for users -- since they are not trusted to write a > b, and extremelly annoying for me, since I have to remember to turn it off. I had similar problem in PHP, where it required me to dig at least two arcane variables to turn off the automatic escaping of singe quotes. Another assumption is that I only do html or prefer html. I want to see ASP.NET view engine as a content-type-independent engine, and I always saw <%= %> as 'here be it'. Engine should not be unusable if I use text/plain instead of text/html and should not require workarounds to do it. The second problem is that secure by default gives a developer a belief in automatic security. But it is much easier for me to show someone that they should think about security when I can do it by SQL injection in their login form or by implanting alerts in their comment pages. But when all simple bases are automatically covered, it is too easy to forget about more advanced steps that could cause the same breaches. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment4http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment4Thu, 20 Dec 2007 22:07:25 GMTLet's say you have a text field for company name. User enters: AT&T Data is encoded in database as AT&amp;T User wants to edit so we encode on output and we have <input type="text" value="AT&amp;mp;T" /> which looks like: AT&amp;T (double-encoding :-O) Now database is stored as AT&amp;mp;T UGH! This is why I feel that encoding should be done on output only. P.S. I hope the example comes out right since there's no preview. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment3http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment3Thu, 20 Dec 2007 22:02:24 GMTTo address the <%= %> issue you could maybe build a custom ExpressionBuilder that would encode your output. <%$ Encode:myText %> I wonder if that would work. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment2http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment2Thu, 20 Dec 2007 21:16:21 GMTI agree with the latter part of your post completely. I couldn't quite understand what you were saying about encoding input data. I've always been of the mindset that you html decode input data and html encode user-generated output; otherwise you'll double encode input. > Text, normal text, text that can roundtrip through HTML encoding without modifications. People use the & entity more than I would've thought. http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment1http://ayende.com/3061/cross-site-scripting-and-letting-the-framework-deal-with-it#comment1Thu, 20 Dec 2007 20:33:22 GMT