This forum is in READ-ONLY mode.
You can look around, but if you want to ask a new question, please use the new forum.
Home » support » General discussion » Symfony Security issue - XSS attack on form helpers
icon4.gif  Symfony Security issue - XSS attack on form helpers [message #3872] Mon, 13 March 2006 23:19 Go to next message
pookey  is currently offline pookey
Messages: 173
Registered: January 2006
Location: Epsom, Surrey, UK
Senior Member

Synopsis
--------

Symfony's input_tag form helper is vulnerable to cross site scripting attacks.

Affected Versions
-----------------

0.6, latest beta.
Possibly older versions too.

Description
-----------

The input_tag will display a value received in the request without sanitising it's content. More information on XSS can be found here - http://en.wikipedia.org/wiki/Cross_site_scripting.
A ticket for this bug has been opened on trac.

Impact
------

By exploiting the cross-site scripting vulnerabilities, an attacker can execute arbitrary scripts running in the context of the victim's browser. The severity of this issue will vary on a site to site basis.

Workaround
----------

Currently there is work arround.

Example
-------

http://www.askeet.com/search?search=test%22%3E%3Cscript%3Eal ert('XSS');%3C%2Fscript%3E%3Ci

[Updated on: Mon, 13 March 2006 23:43]


http://shurl.net - the only URL shortening service written with symfony!
Re: Symfony Security issue - XSS attack on form helpers [message #3894 is a reply to message #3872 ] Tue, 14 March 2006 12:34 Go to previous messageGo to next message
b4pro2
Messages: 56
Registered: December 2005
Member
which ticket are you referring to? I was not able to find it...

cheers

Kai
Re: Symfony Security issue - XSS attack on form helpers [message #3896 is a reply to message #3872 ] Tue, 14 March 2006 13:46 Go to previous messageGo to next message
simonbun  is currently offline simonbun
Messages: 205
Registered: October 2005
Faithful Member
Every default form element is open to xss attacks. Thats why you have to validate and strip any malicious content.

If this should be done automatically by symfony is another discussion though. Personally i think this is the responsability of the developer.
Re: Symfony Security issue - XSS attack on form helpers [message #3900 is a reply to message #3872 ] Tue, 14 March 2006 14:22 Go to previous messageGo to next message
pookey  is currently offline pookey
Messages: 173
Registered: January 2006
Location: Epsom, Surrey, UK
Senior Member

this is not a validation issue - even if you fail validation on a form element for invalid content the value can still be injected via the URL.
This *is* s security issue in symfony and every application written in it that uses the form helpers.


http://shurl.net - the only URL shortening service written with symfony!
Re: Symfony Security issue - XSS attack on form helpers [message #3901 is a reply to message #3900 ] Tue, 14 March 2006 15:43 Go to previous messageGo to next message
jgchristopher  is currently offline jgchristopher
Messages: 71
Registered: October 2005
Location: Omaha, NE
Member

This is not specific to symfony. If you create an html form and don't check the input before using it, this hack will be present.

Symfony form helpers don't do anything more than help to create a quick and easy way to create form elements with prepopulated data. It is up to the developer to check the input data of a submitted form before allowing it to pass through.

John
Re: Symfony Security issue - XSS attack on form helpers [message #3902 is a reply to message #3901 ] Tue, 14 March 2006 16:49 Go to previous messageGo to next message
pookey  is currently offline pookey
Messages: 173
Registered: January 2006
Location: Epsom, Surrey, UK
Senior Member

By default, the form helpers repopulate from request variables. By default these are not escaped, therefore, by default, these fields can be attacked in the way I showed.

I've proven this attack on more then just the askeet site.

The problem here is the form helpers default behaviour can, and will lead to XSS issues on websites written in symfony.


http://shurl.net - the only URL shortening service written with symfony!
Re: Symfony Security issue - XSS attack on form helpers [message #3903 is a reply to message #3872 ] Tue, 14 March 2006 16:58 Go to previous messageGo to next message
pookey  is currently offline pookey
Messages: 173
Registered: January 2006
Location: Epsom, Surrey, UK
Senior Member

Here are 3 more examples.....

http://snowlion.com/member?username="><script>alert('xss'); <%2Fscript><m

http://www.mymapspace.com?username="><script>alert('xss'); <%2Fscript><m

http://gbiker.com/carwatch?name="><script>alert('xss');<%2Fscript ><m


http://shurl.net - the only URL shortening service written with symfony!
Re: Symfony Security issue - XSS attack on form helpers [message #3904 is a reply to message #3903 ] Tue, 14 March 2006 17:13 Go to previous messageGo to next message
jgchristopher  is currently offline jgchristopher
Messages: 71
Registered: October 2005
Location: Omaha, NE
Member

I get you now Smile. I tried this on my on site. If Fabien doesn't beat me to it, I will remove all of the repopulation from the helpers. A new stable release should probably be set up as well.

Things could be re written to santize the values before repopulating but I think the consensus is to remove the repopulation altogether.

John
Re: Symfony Security issue - XSS attack on form helpers [message #3907 is a reply to message #3904 ] Tue, 14 March 2006 18:25 Go to previous messageGo to next message
webdev
Messages: 19
Registered: October 2005
Junior Member
Hello,

I don't believe the answer is to remove the form repopulation, but rather to add a set of filters to the helpers.

I have been using PEAR::Quickform for many years, before I moved to Symfony.
http://pear.php.net/manual/en/package.html.html-quickform.ph p

Quickform utilizes a series of filters to take care of such issues:

"QuickForm can also make use of filters for data import into the form or for data processing once the form has been submitted. Filters work the same way as rules except that you don't need to register them. You write your filter functions and call them in your script. You can call any php function (ie. trim, addslashes, htmlentities, etc.) and have them applied recursively to your element values."

It is as simple as::
$this->form->applyFilter('__ALL__', 'trim');
$this->form->applyFilter('__ALL__', 'strip_tags');

I recommend adding a set of filters in, that can be used either on the entire POST/GET
$this->form->applyFilter('__ALL__', 'strip_tags');

or individually on a single form element like
$this->form->applyFilter('first_name', 'strip_tags');

Paul
Re: Symfony Security issue - XSS attack on form helpers [message #3910 is a reply to message #3907 ] Tue, 14 March 2006 18:53 Go to previous messageGo to next message
webdev
Messages: 19
Registered: October 2005
Junior Member
Also,

For those following the recent release of the ZendFramework, here is the start of their solution.

http://framework.zend.com/manual/zend.inputfilter.html

Paul
Re: Symfony Security issue - XSS attack on form helpers [message #3912 is a reply to message #3872 ] Tue, 14 March 2006 19:31 Go to previous messageGo to next message
simonbun  is currently offline simonbun
Messages: 205
Registered: October 2005
Faithful Member
Well i think the automatic repopulating will be gone pretty soon then Wink.

Before running my normal validators i strip out the malicious content and overwrite the original value though. Though you can never be secure enough ofcourse.

Re: Symfony Security issue - XSS attack on form helpers [message #3913 is a reply to message #3912 ] Tue, 14 March 2006 19:56 Go to previous messageGo to next message
jgchristopher  is currently offline jgchristopher
Messages: 71
Registered: October 2005
Location: Omaha, NE
Member

http://symfony.pastebin.com/602046

This change to the symfony code, fixes the XSS hack and the problem with URL paramters overriding form fields.

This limits form re-population after validation errors for forms submitted via a POST only though. If you are submitting forms via a GET it won't re-populate the form with request vars if a validation error occurs.
Re: Symfony Security issue - XSS attack on form helpers [message #3914 is a reply to message #3872 ] Tue, 14 March 2006 21:12 Go to previous messageGo to next message
b4pro2
Messages: 56
Registered: December 2005
Member
my 2 cents about it:

Disabling the auto-population for GET is surely a good idea but it does not solve the problem. I would vote for a filter system like Quickform or the Zend Frameworks have.

And it would be cool to have a Tutorial about "secure Form population after Validation" Wink

cheers

Kai
Re: Symfony Security issue - XSS attack on form helpers [message #3923 is a reply to message #3914 ] Wed, 15 March 2006 05:03 Go to previous messageGo to next message
tamcy  is currently offline tamcy
Messages: 222
Registered: February 2006
Location: Hong Kong
Faithful Member
And people can just put
"<script>alert('Hello');</script>"

into the askeet search box, click "search it", and welcome the dialog box, although I think it's not that big deal..
Re: Symfony Security issue - XSS attack on form helpers [message #3945 is a reply to message #3923 ] Wed, 15 March 2006 13:07 Go to previous messageGo to next message
pookey  is currently offline pookey
Messages: 173
Registered: January 2006
Location: Epsom, Surrey, UK
Senior Member

if you don't think it's a big deal you really should go learn about XSS problems. Read the wikipeadia page.



http://shurl.net - the only URL shortening service written with symfony!
Re: Symfony Security issue - XSS attack on form helpers [message #3948 is a reply to message #3945 ] Wed, 15 March 2006 13:23 Go to previous messageGo to next message
tamcy  is currently offline tamcy
Messages: 222
Registered: February 2006
Location: Hong Kong
Faithful Member
I said "not a big deal" is kind of comparison with data passed by GET -- I think it's somewhat more difficult to fake with a POST than GET. Of course I may overlooked something, I did read the page and I should admit that I'm not 100% clear about what such script can do to harm the clien, but afterall I agree it should be fixed, and I know it IS problem.

[edit: I'm now reading the MSN Hotmail case and is amazed Twisted Evil]

[Updated on: Wed, 15 March 2006 13:35]

Re: Symfony Security issue - XSS attack on form helpers [message #3953 is a reply to message #3948 ] Wed, 15 March 2006 14:08 Go to previous messageGo to next message
simonbun  is currently offline simonbun
Messages: 205
Registered: October 2005
Faithful Member
actually faking POST is just as easy as GET. If you do it manually then you'd have a 2 minute setback compared to attacking via GET, but there area ways to do it automatically as well.
Re: Symfony Security issue - XSS attack on form helpers [message #3954 is a reply to message #3953 ] Wed, 15 March 2006 14:21 Go to previous messageGo to next message
pookey  is currently offline pookey
Messages: 173
Registered: January 2006
Location: Epsom, Surrey, UK
Senior Member

infact, you could use GET to inject JS that then submits things via 'AJAX' as a post.


http://shurl.net - the only URL shortening service written with symfony!
Re: Symfony Security issue - XSS attack on form helpers [message #4029 is a reply to message #3872 ] Fri, 17 March 2006 19:13 Go to previous messageGo to next message
scott  is currently offline scott
Messages: 5
Registered: March 2006
Location: Vancouver
Junior Member
I'm wondering if there's a fix in the works for this problem? We're currently building an application using Symfony and this XSS hole could be a big issue.
Re: Symfony Security issue - XSS attack on form helpers [message #4030 is a reply to message #4029 ] Fri, 17 March 2006 19:29 Go to previous messageGo to next message
tamcy  is currently offline tamcy
Messages: 222
Registered: February 2006
Location: Hong Kong
Faithful Member
A quick fix would be :
Open symfony_library_dir/helper/FormHelper.php,
find function input_tag which should look like this:

function input_tag($name, $value = null, $options = array())
{
  if ($value === null && isset($options['type']) && $options['type'] == 'password')
  {
    $value = null;
  }
  else if (($reqvalue = _get_request_value($name)) !== null)
  {
    $value = $reqvalue;
  }

  return tag('input', array_merge(array('type' => 'text', 'name' => $name, 'id' => $name, 'value' => $value), _convert_options($options)));
}



change
    $value = $reqvalue;


to

    $value = htmlspecialchars($reqvalue);


This is meant to fix the double quote issue, but should also fix XSS problem.
Re: Symfony Security issue - XSS attack on form helpers [message #4031 is a reply to message #4030 ] Fri, 17 March 2006 19:51 Go to previous messageGo to next message
tamcy  is currently offline tamcy
Messages: 222
Registered: February 2006
Location: Hong Kong
Faithful Member
I would prefer a way that we can define our own sanitizer in factories.yml or otherwise the defaiult sfInputSanitizer will be executed. The only problem is it seems to heavy to get a new instance for every field.
Re: Symfony Security issue - XSS attack on form helpers [message #4034 is a reply to message #3872 ] Fri, 17 March 2006 21:29 Go to previous messageGo to next message
RoVeRT  is currently offline RoVeRT
Messages: 146
Registered: October 2005
Senior Member
proper place would be in _tag_options of TagHelper.php where it did exist for a time when i added it and was removed by fabien shortly afterwards
Re: Symfony Security issue - XSS attack on form helpers [message #4056 is a reply to message #4034 ] Sat, 18 March 2006 22:26 Go to previous messageGo to next message
debea  is currently offline debea
Messages: 10
Registered: December 2005
Location: Freiburg, Germany
Junior Member
I looked at this in trac (Changeset 505).

The problem with htmlentities is that if the character set is not specified, Latin1 is used. And if someone enters non-english characters (like german &auml; รค), these may not be re-entered correctly in the re-populated form. (See this comment in the manual).

I'd suggest to use htmlspecialchars instead:
function _tag_options($options = array())
{
  $options = _parse_attributes($options);

  $html = '';
  foreach ($options as $key => $value)
  {
//    $html .= ' '.$key.'="'.$value.'"';
//    $html .= ' '.$key.'="'.htmlentities($value).'"';
    $html .= ' '.$key.'="'.htmlspecialchars($value).'"';
  }

  return $html;
}
Re: Symfony Security issue - XSS attack on form helpers [message #8769 is a reply to message #4030 ] Thu, 13 July 2006 14:58 Go to previous message
gucky  is currently offline gucky
Messages: 10
Registered: June 2006
Junior Member

Hi!

I've installed 0.6.3 and used the "input_hidden_tag" helper.

I was astonished, that symfony doesn't takes care that there are no '"' in my value. IMHO thats one reason why I use a framework. If the helper generates the complete HTML tag, than it's the job of the helper to create a *valid* HTML!

Do I realy have to put the "htmlspecialchars()" around every value or will it in the next version of all form helpers?

Thanks,
Gucky.
Previous Topic:JSON - multiple ajax calls - revisited
Next Topic:[resolved] Using .htaccess password with myUser class
Goto Forum:
  

powered by FUDforum - copyright ©2001-2004 FUD Forum Bulletin Board Software