we're always on the lookout on how to further secure SilverStripe, and seen a pattern of weak coding around controller/template interactions in the past, which lead to XSS holes.
I think its mainly a documentation issue ("where do I escape my content, and what is automatically escaped?"), so Sam and me sat together and worked out some examples and best practices.
This page is something every SilverStripe developer should encounter early on. Even developers with a general idea about XSS and countermeasures will find it helpful to see what the framework provides for them.
It is paramount that the examples and comments are as concise and understandable as possible, so we're looking for your feedback! What do you guys think?
As some of the responsibility will be with the template author (mainly in HTML attributes), it is important that less security-focused HTMLers understand it as well - do you think thats the case?
Note: The security API is unchanged, we've just clarified what's already there.
Yes, I think its simple enough to understandable. To be even more recognized by HTMLer what it secure for, an example might be helpful as well. like what if Hacker BadGuy input a string "Select CredentialInfo from Customer where `Email` = GeorgeWB...@whitehouse.govt.us'" or "Update Payment Set `Status` = 'Success` Where ID = 7" in a form/query string, etc.
On Jan 18, 2:08 pm, Ingo Schommer <i...@silverstripe.com> wrote:
> we're always on the lookout on how to further secure SilverStripe, > and seen a pattern of weak coding around controller/template > interactions in the past, which lead to XSS holes.
> I think its mainly a documentation issue > ("where do I escape my content, and what is automatically escaped?"), > so Sam and me sat together and worked out some examples and best practices.
> This page is something every SilverStripe developer should encounter early on. > Even developers with a general idea about XSS and countermeasures > will find it helpful to see what the framework provides for them.
> It is paramount that the examples and comments are as concise and understandable as possible, > so we're looking for your feedback! What do you guys think?
> As some of the responsibility will be with the template author (mainly in HTML attributes), it is important > that less security-focused HTMLers understand it as well - do you think thats the case?
> Note: The security API is unchanged, we've just clarified what's already there.
This is some great documentation that should go hand-in-hand with learning how to use the templating system and datatypes. It really clarifies some of the basics. Thanks boys!
> On Jan 18, 2:08 pm, Ingo Schommer <i...@silverstripe.com> wrote: > > This page is something every SilverStripe developer should encounter early on. > > Even developers with a general idea about XSS and countermeasures > > will find it helpful to see what the framework provides for them.
Thought I mailed it to the group, but replyed Ingo only instead...
Hi INgo,
I think this is indeed an important document. Definitly a sticky post for the forums...
The examples are clear, but when targetting 'less security-focused HTMLers', I think there could be a little more Why, When and What Else If You Don't.. And maybe a short hotlist, which sums ups some 'Always use this. not this...'
Like in Overriding default escaping in templates. When should I use $Value.XML or $Value.ATT?
I read this as I should always use Convert::raw2xml() and Convert::raw2att() . I would never browse the Convert class to search for buildin security methods.
I think 'less security-focused HTMLers' and people who start to use Silverstripe cause they need some Out-of-the-Box tool to create websites, will look for methods within Silverstripe when questioning security issues, instead of Googling secure PHP development (or maybe just expect Silverstripe will deal with insecure methods by default).
Maybe it is an idea idea to completely ban plain $_REQUEST, $_POST and $_GET functions, but offer a method to use build in getters that provide escaping methods, like Joomla does with:
could be something like Security/Controller::getVar('get/request/post/ session', $value, 'cast', $exeption);
Shure an (int) casting will do the job in some cases, but a more experienced developer, will know when it will be enough to cast a request like this and people who are exploring Silverstripe's default code for examples will always find getVar methods instead of plain $_GET methods (maybe the Page.phph file is a good place to add some of those methods for example, like the search method. ).
> This is some great documentation that should go hand-in-hand with > learning how to use the templating system and datatypes. It really > clarifies some of the basics. Thanks boys!
> -Dale
> > On Jan 18, 2:08 pm, Ingo Schommer <i...@silverstripe.com> wrote: > > > This page is something every SilverStripe developer should encounter early on. > > > Even developers with a general idea about XSS and countermeasures > > > will find it helpful to see what the framework provides for them.
On Thu, Jan 21, 2010 at 9:23 AM, Martijn <marva...@gmail.com> wrote: > Thought I mailed it to the group, but replyed Ingo only instead...
> Hi INgo,
> I think this is indeed an important document. Definitly a sticky post > for the forums...
> The examples are clear, but when targetting 'less security-focused > HTMLers', I think there could be a little more Why, When and What Else > If You Don't.. And maybe a short hotlist, which sums ups some 'Always > use this. not this...'
> Like in Overriding default escaping in templates. When should I use > $Value.XML or $Value.ATT?
> I read this as I should always use Convert::raw2xml() and > Convert::raw2att() . I would never browse the Convert class to search > for buildin security methods.
> I think 'less security-focused HTMLers' and people who start to use > Silverstripe cause they need some Out-of-the-Box tool to create > websites, will look for methods within Silverstripe when questioning > security issues, instead of Googling secure PHP development (or maybe > just expect Silverstripe will deal with insecure methods by default).
> Maybe it is an idea idea to completely ban plain $_REQUEST, $_POST and > $_GET functions, but offer a method to use build in getters that > provide escaping methods, like Joomla does with:
> could be something like Security/Controller::getVar('get/request/post/ > session', $value, 'cast', $exeption);
> Shure an (int) casting will do the job in some cases, but a more > experienced developer, will know when it will be enough to cast a > request like this and people who are exploring Silverstripe's default > code for examples will always find getVar methods instead of plain > $_GET methods (maybe the Page.phph file is a good place to add some of > those methods for example, like the search method. ).
