Development

SecuringDevFrontend (diff)

You must first sign up to be able to contribute.

Changes between Version 6 and Version 7 of SecuringDevFrontend

Show
Ignore:
Author:
rickb (IP: 195.80.10.42)
Timestamp:
01/28/08 13:42:21 (9 years ago)
Comment:

Grammar, spelling, punctuation only

Legend:

Unmodified
Added
Removed
Modified
  • SecuringDevFrontend

    v6 v7  
    33One of the nice features of symfony is the ability to use different "loaders" for symfony that activate certain aspects of symfony. The main use of this is the development frontend, which greatly eases development by adding a little panel inside the output of HTML pages with debug information. However symfony requires these frontends to all reside inside the main web directory which obviously poses security issues. As a result these alternate frontends should not be put on production machines in the default location. 
    44 
    5 There are a number of solutions to solve this security risk, while still being able to leverage these frontends during development and even on the production machines. The below list was compiled from a [http://groups.google.com/group/symfony-devs/tree/browse_frm/thread/7fba23a5d36a6047/d647379e6c64aa00?rnum=1&_done=%2Fgroup%2Fsymfony-devs%2Fbrowse_frm%2Fthread%2F7fba23a5d36a6047%3F#doc_d647379e6c64aa00 thread] on the developers list. Each approach has its own strength's and weaknesses, so the listing is not made in any particular order. 
     5There are a number of solutions to solve this security risk, while still being able to leverage these frontends during development and even on the production machines. The below list was compiled from a [http://groups.google.com/group/symfony-devs/tree/browse_frm/thread/7fba23a5d36a6047/d647379e6c64aa00?rnum=1&_done=%2Fgroup%2Fsymfony-devs%2Fbrowse_frm%2Fthread%2F7fba23a5d36a6047%3F#doc_d647379e6c64aa00 thread] on the developers list. Each approach has its own strengths and weaknesses, so the suggestions are not made in any particular order. 
    66 
    7 == Symlink on demand == 
     7== Suggestion 1: Symlink on demand == 
     8Move the development frontends into a separate directory and symlink them into the web directory as needed. When using this approach on production machines, you should at the very list use a non-standard name in the symlink. However, this is obviously "security through obscurity" (so not very secure). In case any automatic rsyncing solutions are used, additional precautions should be taken to prevent automatic propagation of these files to other servers. 
    89 
    9 Move the development frontends into a separate directory and symlink them into the web directory on a need basis. When using this approach on production machines one should at the very list use a non standard name in the symlink. However this is obviously security through obscurity. In case any automatic rsyncing solutions are used, additional precautions should be taken to prevent automatic propagation of these files to other servers. 
    10  
    11 == Set variables in vhost == 
    12 Using a vhost one can set the application, environment and debugging mode. The frontend code would need to be modified as follows: 
     10== Suggestion 2: Set variables in vhost == 
     11By using a virtual host ("vhost"), you can set the application, environment and debugging mode. The frontend code would need to be modified as follows: 
    1312{{{ 
    1413#!php 
    5352</VirtualHost> 
    5453}}} 
     54Note the three `SetEnv` lines and the corresponding `$_SERVER[]` expressions. 
    5555 
    56 == Limit access using SSL certificates == 
    57 One can can limit access to specific URLs in the vhost, so frontend_dev.php could only be accessible to users presenting a client SSL certificate. You can find information on how to set this up over [http://blogs.ittoolbox.com/security/investigator/archives/howto-securing-a-website-with-client-ssl-certificates-11500 here]. 
     56== Suggestion 3: Limit access using SSL certificates == 
     57You can can limit access to specific URLs in the vhost, so frontend_dev.php could only be accessible to users presenting a client SSL certificate. You can find information on how to set this up over [http://blogs.ittoolbox.com/security/investigator/archives/howto-securing-a-website-with-client-ssl-certificates-11500 here]. 
    5858 
    59 == Adapt url/asset helper url generation == 
    60 You can make it possible to place the development frontends into a different directory, which can then be secured/exposed on a per need basis. This approach however requires a fair amount of hacks until symfony 1.1 comes along which should make it easier to change behavior in the url and asset helpers. 
     59== Suggestion 4: Adapt url/asset helper url generation == 
     60You can make it possible to place the development frontends into a different directory, which can then be secured/exposed as required. Unfortunately, in Symfony 1.0.x this approach requires a fair number of hacks. Symfony 1.1 will make it easier to change behavior in the url and asset helpers. 
    6161 
    62621) Add a constant in the given front controllers that enables the host rewriting: 
    121121}}} 
    122122 
    123 Remember that you can have different configuration settings per environment and per server (following the above guidelines). There is a problem with this solution however if the no_script_tag feature is disabled, since in that case the url helpers will use the $request->getRelativeUrlRoot() to construct the url. In that case you also need to do some further hacking: 
     123Remember that you can have different configuration settings per environment and per server (following the above guidelines). However, there is a problem with this solution if the `no_script_tag` feature is disabled, because in that case the url helpers will use the `$request->getRelativeUrlRoot()` to construct the url. In that case you also need to do some further hacking: 
    124124 
    125 4) First you need to store the original relative url root in a constant before modifying the value in your filter. Then you need to open up and store lib/symfony/controller/sfWebController.class.php in your application lib directory and modify the genUrl() method. Look for the call to getRelativeUrlRoot() and change the section of the code as follows: 
     1254) First you need to store the original relative url root in a constant before modifying the value in your filter. Then you need to open up and store `lib/symfony/controller/sfWebController.class.php` in your application lib directory and modify the `genUrl()` method. Look for the call to `getRelativeUrlRoot()` and change the section of the code as follows: 
    126126 
    127127{{{