Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-2479

[PHP] SQ/SC/SL understand the WordPress hooking system



    • Type: MMF
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Labels:



      WordPress is a PHP framework that runs on 63% of all websites, according to W3Tech. This spread is also due to the fact that the framework can be easily extended with templates and plugins. So that these extensions can work together with the framework and intervene in the normal process, WordPress provides so-called hooks. Hereby actions or filters can be registered or called.

      At the moment, the security analysis is not able to trace the control flows created by the hooks. This leads to the fact that no complete taint analysis can be executed. This in turn leads to FN, as well as FP in case of missing understanding of filter characteristics.

      Correct processing of the hooks and the resulting improved understanding of the connections can improve the precision of the analysis. This leads to WordPress developers being able to create secure plugins and frameworks.


      Hooks are a fundamental part of WordPress development. The main idea is, as the name might suggest, to hook callbacks to run at specific points in the code. Two types of hooks exist in WordPress: actions and filters. They are basically the same, except that the callbacks registered to a filter are expected to return a value.

      • To register a callback to an action, one uses add_action(), and to trigger the action, one uses do_action (do_action_ref_array is also possible)
      • To register a callback to a filter, one uses add_filter(), and to trigger the filter, one uses _apply_filters()

      Use Case

      // File 1
      function myFunction1($param) {
          echo sprintf("%d", $param);
      add_action( 'my_custom_action', "myFunction1");
      // File 2
      function myFunction2($param) {
         echo sprintf("%s", $param); // Should raise an XSS issue
      add_action( 'my_custom_action', "myFunction2");
      // File 3
      do_action( 'my_custom_action', $_GET['arg1'] );
      // myFunction1 and myFunction2 will run at this point with user input as argument.

      In this example, two callbacks are registered for the hook 'my_custom_action'. These are then called tainted user input. This leads to a vulnerability in the second callback.

      // File 1
      function myFunction1($param) {
          return sprintf("%d", $param);
      add_action( 'my_custom_filter', "myFunction1");
      // File 2
      echo apply_filters( 'my_custom_filter', $_GET['arg1'] );  // Safe due to sanitization in the custom filter callback

      In the second example, a filter callback is registered which returns a value. In this case, it is a sanitized tainted user input.

      The analysis should be able to correctly process add_action, do_action, do_action_ref_array, add_filter, and apply_filters.

      The challenge in this example is on the one hand, that the callbacks, as well as the call, are declared, respectively executed in different files. It is therefore necessary to have a complete overview of all registered callbacks for the respective hooks in order to include all relevant callbacks when analyzing the call.

      Acceptance Criteria
      On the one hand, the analysis of the hooks must not cause a significant drop in performance, especially when analyzing projects that are not based on WordPress. On the other hand, no FP should be generated by an incorrect connection of hooks and callbacks. Such a connection should only be established if the resolution is possible without any doubt.


      How is mainly described in SONARSEC-2630


          Issue Links



              Unassigned Unassigned
              alexandre.gigleux Alexandre Gigleux
              0 Vote for this issue
              1 Start watching this issue