28 Nov 2013

A new batch of rules

A significant share of the SensioLabsInsight development effort is spent implementing new code checks - or "rules" as we call them. This week, we've just released 5 new rules.

Disabled Twig escaping

Disabling Twig escaping for an entire application is possible, but it's strongly discouraged. From now on, any Symfony application with such a huge XSS vulnerability in config.yml will raise a critical security violation.

    # ...
    autoescape: false

Use of raw filter or autoescape off in Twig templates

Another possible XSS vulnerability comes from abuse of the |raw filter. Whenever the data piped to this filter comes from a user input, a Cross-Site Scripting attack is possible. Therefore SensioLabsInsight raises a critial security violation each time |raw is used, or when a variable is output inside a {% autoescape off %} block.

{{ user.header|raw }}

{% autoescape off %}
{{ user.header }}
{% endautoescape %}

Injection of the request service for Symfony 2.4 applications

The soon-to-be-released Symfony 2.4 deprecates the injection of the request service in favor of the request_stack service, mush more adapted to sub-requests (read more about it in the Symfony blog).

    class: Foo\Bar
      - [setRequest, ['@request=']]

SensioLabsInsight can now detect, when you use Symfony 2.4, every occurrence of a request service injection. This will ease your upgrading process and give you no excuse to keep on using the flawed request service.

Unreachable code

Do you sometimes move a return statement up during a debugging session, and forget to remove it before committing? Yeah, that happens a lot. SensioLabsInsight can now detect unreachable code, blocked behind a return, a die(), a throw, a continue, or an exit. It's often a simple mistake, but it may cause a serious bug nevertheless.

class Foo
  public function computeStuff($value)
    // added for debugging

    if ($value > 0) {
      // actual stuff computing

Of course, SensioLabsInsight won't bug you with unreachable code used for consistency's sake, such as the break statements in the following snippet:

switch ($value) {
  case 'foo':
    return 0;
  case 'bar':
    return 1;
  case default:
    return null;    

PHP Syntax Error

One of the first rule we developed was actually disabled because of a forgotten return (that happens to everybody). Using Insight on Insight helped us track this unreachable code and reenable the rule.

This rule is very simple: it uses the php command to check the syntax of all committed PHP files in your projects. That way you can spot a syntax error even before you execute that code!

// can you spot the syntax error in the next line?
echo 'hello, world!";

False positives, tweaks and bugfixes

As always, we keep on tuning these rules for false positives. Don't hesitate to mention us any false positives on the new rules using the "Feedback" button!

This week, we've also removed false violations on the use of the $_GET superglobal, which should obviously be allowed on applications not using Symfony. We've also changed the "Commented out code" severity to minor, so that you can get a silver medal even with one or two lines of PHP code commented. And we've fixed a lot of small issues to make your quality analysis experience even better.

comments powered by Disqus