Updated "secure development" documentation

[Ingo Schommer]

Hello there,

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.

You can see the result at:
http://doc.silverstripe.org/doku.php?do=show&id=secure-development#xss_cross-site-scripting

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.

Ingo

-------
Ingo Schommer | Senior Developer
SilverStripe
http://silverstripe.com

Phone: +64 4 978 7330 ext 42
Skype: chillu23

[Normann]

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` =
Georg...@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:
> Hello there,
>
> 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.
>

> You can see the result at:http://doc.silverstripe.org/doku.php?do=show&id=secure-development#xs...

>
> 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.
>
> Ingo
>
> -------
> Ingo Schommer | Senior Developer

> SilverStripehttp://silverstripe.com

[dalesaurus]

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

[Martijn]

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?

http://doc.silverstripe.org/doku.php?do=show&id=secure-development#manual_escaping_in_php
:

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:

http://docs.joomla.org/Retrieving_data_from_GET_and_POST_requests

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

http://doc.silverstripe.org/doku.php?do=show&id=secure-development#don_t_allow_script-execution_in_assets

<LocationMatch assets/>
php_flag engine off
Options -ExecCGI -Includes -Indexes
</LocationMatch>

Why is this not in the htaccess by default?

So far my first pennies. Hope it is constructive.

Martijn

[Fred Condo]

In addition, the exact version of SilverStripe is divulged:
http://example.org/sapphire/silverstripe_version

It might be considered security through obscurity, but I can imagine
no point in revealing this to the world.

- Fred