Security

The subject security is not to be imagined as not existing in a time of the free availability of data, countless bot networks and SPAM dispatch from web applications any more. On this occasion, not only the juridical background plays a big role, but also the security and stability of the hosting systems is dependent directly from the security and the stability of the applications. That's why it is essential that the used tools or frameworks already are secury and stable by design.

The following list indicates features of the APF which already provide out-of-the-box security:

  • Ein- und Ausgabe-Filter
    Seit dem 1.5er Release besitzt das Framework allgemeingültige Ein- und Ausgabe-Filter, die beim Start des Page- oder FrontControllers die Benutzer-Eingaben (GET und POST) filtern. Dies erzeugt bereits eine Grundsicherheit und erhöht die Sicherheit einer Anwendung gegenüber anderen Tools deutlich.
    Seit dem 1.9er-Branch ist es zudem möglich diese zu beeinflussen und eigene Filter für Ein- und Ausgabe einzuklinken, die einen speziellen Anwendungsfall noch besser schützen können, als die allgemeingültigen Filter.

  • Formular-Filter
    Seit dem 1.9er-Branch ist es zudem möglich, Text-Eingabefelder mit einem Filter zu belegen. Das ermöglicht es dem Entwickler, an definierten Stellen (z.B. Login-Formular) für zusätzliche Sicherheit zu sorgen und SQL-Injections durch Filterung von problematischen Escape-Zeichen gänzlich zu vermeiden.

  • Configuration:
    Configuration duties are strictly done by the configurationManager. This component uses no parametres from the REQUEST and is used only by the application itself. Thus, XSS attacks are not taking place by design!

  • URL layout:
    The URL layout must correspond to a defined schema. Hence, possible XSS gaps strike by use of the LinkHandler and FrontcontrollerLinkHandler components by the fact that a URL cannot be parsed and the called components indicate an error.

  • Templates:
    The page controller processes templates not as PHP scripts like many other frameworks do. The PHP code which may be smuggled into the code by XSS holes - if the software built on the framework has such security holes - hence, is not executed, but is brought to display as is.

  • Bootstrap architecture:
    Because of the bootstrap architecture (=every request is handled by a single php file) requests like /content.php?seite=http://casts.150m.com/expo/expo1? cannot affect the operation of the application.

  • URL parameters:
    Parameters in urls that directly influence templates including functionalities do not reach the file system directly and uncontrollably, due to the fact, that they are validated and are only legal in a dedicated namespace. If a template is not found, an application error is thrown, so that the readout of system files is not possible. URL parameters in front controller actions are abstracted, by a configuration and do not access file system resources directly.


Further reading on XSS and security can be obtained in the article (German) or in the German language forum under http://forum.adventure-php-fra...p?f=5&t=21. The website http://phpsec.org also contains very interesting stuff on PHP security.


Comments

Do you want to add a comment to the article above, or do you want to post additional hints? So please click here. Comments already posted can be found below.
There are no comments belonging to this article.