Security + performance questions

[Sinmok]

Hello all,

Once again, just want to comment on how good I truly believe PW to be.

I do have a few questions about security though - more specifically about the systems way of handling XSS. I've not really found anything on PW's security practices and exploit prevention precautions.

1. Is page content filtered client side on submit? I noticed disabling javascript on the admin pages meant that script tags could make it thorough.
2. What is the practice for cleaning harmful code on output? I've noticed there's a sanitizer API. Is there a way to enable the sanitizer for all fields by default, so I don't have to keep calling it in the templates for every field?
3. Is it safe to assume that input on fields are automatically escaped to prevent SQL injection?
4. Are admin functions protected from CSRF attacks?

I am aware of the HTMLPurifer plugin but this appears to be an optional plugin.

Finally, a quick question about performance. I've enabled debugging and found that there are 47 queries running on an (admin) page load. Is this going to cause problems for upwards scaling in the future?

If these questions have been answered elsewhere, please point in the direction of the answers.

Cheers and thanks again.

Edit: I can't find any reference of XSS cleaning functionality at all. Not even the sanitizer seems to have this functionality. Is everything really done on the client by TinyMCE? Looks like the sanitizer class does indeed have some cleaning functionality.

[Luis]

My quick answer for scaling: http://processwire.com/talk/topic/3358-managing-large-sets-of-pages/#entry33156

[kongondo]

Hi Madmax555,

Welcome to PW!

About SQL injections in PW, see the answer by Ryan (main developer) in this thread - they are a non-issue with respect to PW API

ProcessWire's API doesn't use SQL queries -- it uses selectors. SQL injection is a non-issue in ProcessWire.

These will also be useful

http://processwire.com/talk/topic/1380-duplicate-entries-registration-form/?p=12369

http://processwire.com/talk/topic/314-idea-create-calendar-events/?p=2183

XSS in a giant can of worms and you want to keep it closed. You need to make sure that any input from the user is routed through htmlentities() or htmlspecialchars() before it is output, unless you have specifically typecast it as something (like an integer). This includes $_SERVER['PHP_SELF'] which can be considered tainted, and needs to be sanitized in the same way. Though you probably don't need to use PHP_SELF at all, so I would just avoid using it. 

To protect against SQL query injection, you need to sanitize and validate your data. If you are expecting something to be an integer, then typecast it to an integer as soon as you get it from GPC......

http://processwire.com/talk/topic/1380-duplicate-entries-registration-form/

http://processwire.com/talk/topic/2038-distinct-selector-in-processwire/?p=19268

http://processwire.com/talk/topic/2385-custom-string-in-names-of-database-tables/

[ryan]

I do have a few questions about security though - more specifically about the systems way of handling XSS.

You have to consider XSS anywhere that the [untrusted] user can enter content that will be saved and echoed back to other users. In a default ProcessWire installation with no 3rd party modules, there aren't many places to consider this. The admin is designed for trusted users only. The comments module is the only thing that accepts and stores untrusted user input. It won't store markup in comments. It filters by stripping markup before storing a comment, and by entity encoding output when displaying a comment. 

Also consider that ProcessWire is designed to let you do what you want to do. If you want to create a text/textarea field that lets you enter script tags, then ProcessWire won't stop you. There are plenty of legitimate uses for such things. There simply isn't anywhere that an untrusted user can enter markup. But HTMLPurifier might have a place in your individual installation. If you are dealing with untrusted user input and allowing markup (HTML) then HTMLPurifier is essential. We have an HTMLPurifier module, ready to use. 

Is page content filtered client side on submit? I noticed disabling javascript on the admin pages meant that script tags could make it thorough.

Content is validated and sanitized server-side, not client side. Though on text-based fields entered in the admin, we make no assumptions about what you are using them for. Even scripts are a legitimate use case (consider video embedding, etc.). Some Inputfields may have client-side validation built-in to do one thing or another (TinyMCE is an example). Though ProcessWire doesn't care about client side validation. What sanitization/validation takes place depends entirely upon the Fieldtype. From the admin side, the text-based fieldtypes are designed to contain any text, including any kind of markup. This is one reason why ProcessWire's admin is focused on trusted users only. While I don't recommend using PW's admin with untrusted users, there may be situations where you have "mostly" trusted users. In such cases, you may want to avoid things like rich text fields and focus on LML-based text formatters (safe ones, like Textile Restricted or BBCode) or even HTML Purifier. Our new CKEditor module actually does use the HTML Purifier for inline mode, since inline mode markup is not entity-encoded when presented in the admin. 

What is the practice for cleaning harmful code on output? I've noticed there's a sanitizer API. Is there a way to enable the sanitizer for all fields by default, so I don't have to keep calling it in the templates for every field?

This is a consideration for any text fields that you don't want to support markup. Such fields might include your 'title' and 'summary' fields, but would exclude something like your 'body' field, which is designed specifically to contain markup. ProcessWire uses a type of modules called Textformatters. For any field that you want to have runtime output formatting, you can add an HTML Entities (or other types) Textformatter from Setup > Fields > [your field] > Details. This is only applicable to text-based fields. 

For entity encoding output yourself, use $sanitizer->entities($str). Generally you wouldn't ever use this on your managed content stored in PW. Instead, you would use it when echoing back something that the user entered, like search query:

$q = $input->get->q; 
if($q) {
  $results = $pages->find("body%=" . $sanitizer->selectorValue($q)); 
  echo "<h2>You searched for: " . $sanitizer->entities($q) . "</h2>";
  if(count($results)) echo $results->render(); 
    else echo "<p>Sorry, no results were found.</p>";
}

Is it safe to assume that input on fields are automatically escaped to prevent SQL injection?

ProcessWire's API does not use SQL queries, unless you choose to use the $db variable. So if you want to execute SQL queries, then you should follow best practices towards avoiding SQL injection. However, there are very few scenarios where any of us use SQL in developing websites or apps in ProcessWire, so it's generally a non-issue. What you do have to consider instead is selector injection, even if it's not nearly as potentially dangerous as SQL injection. So that's why we have the $sanitizer->selectorValue(); function. Note the use of it in the code segment above. 

Are admin functions protected from CSRF attacks?

Yes, all ProcessWire forms are CSRF protected. 

[ryan]

Finally, a quick question about performance. I've enabled debugging and found that there are 47 queries running on an (admin) page load. Is this going to cause problems for upwards scaling in the future?

No. MySQL can execute hundreds of well optimized queries faster than one unoptimized one. And MySQL can often execute lots of simple queries faster than 1 complex one. ProcessWire takes advantage of this where it can. Query counting isn't useful anymore (if it ever was). 

[Sinmok]

Brilliant answers. My only other comment would be to suggest copying the information you posted above on to the official docs so that it's easier to find for all!

Thanks again.