Re: [Mod-security-developers] [v3/master] shift in the numbering of the phases ?

[Frédéric G. <sup...@gm...>]

Hi Felipe,

Thank for your quick reply.

Is there really no incidence on the logic of treatment of the rules ?

Br.


On Fri, Dec 22, 2017 at 3:30 PM, Felipe Costa <FC...@tr...> wrote:

> Hi Fred,
>
>
> Indeed the enumerator has a number associated to each item, however this
> number is not the same number that we have on the SecRule. From the user
> perspective there is no change.
>
>
> The additional phases will be supported by SecRule language in further
> versions. Notice that there is no UriPhase on src/actions/phase.cc.
>
>
>
> Br.,
>
> *Felipe **“**Zimmerle” Costa   *
>
> Security Researcher, Lead Developer ModSecurity.
>
>
>
> *Trustwave* | SMART SECURITY ON DEMAND
>
> www.trustwave.com
>
>
> ------------------------------
> *From:* Frédéric Gicquel <sup...@gm...>
> *Sent:* Friday, December 22, 2017 10:46:19 AM
> *To:* mod...@li...
> *Subject:* [Mod-security-developers] [v3/master] shift in the numbering
> of the phases ?
>
> Hello,
>
> Adding the **UriPhase** phase into the enum Phases (see
> headers/modsecurity/modsecurity.h) seems to have introduced a shift in
> the numbering of the historical phases : RequestHeadersPhase is numbered 2
> (instead of 1) and so on (see src/actions/phase.cc).
>
> This has been tested with ModSecurity-3.0 (branch v3/master) in library
> mode and ModSecurity connector for nginx (branch master).
>
>
> Extract of headers/modsecurity/modsecurity.h file
>
> ```
> #ifdef __cplusplus
> #include <ctime>
> #include <iostream>
> #include <string>
> #include <memory>
> #endif
>
>
> #ifndef HEADERS_MODSECURITY_MODSECURITY_H_
> #define HEADERS_MODSECURITY_MODSECURITY_H_
>
>
> #ifndef __cplusplus
> typedef struct ModSecurity_t modsecurity;
> #else
> namespace modsecurity {
>     /**
>      *
>      * The Phases enumerator consists in mapping the different stages of a
>      * given request. ModSecurity is expected to inspect data based on
> those
>      * "phases". If your module/application use this in a different order,
> it
>      * will lead ModSecurity to act in an unexpected behavior.
>      *
>      * It is mandatory to call all the phases, even if you don't have this
>      * phases segmented in your end.
>      *
>      */
>     enum Phases {
>     /**
>      *
>      * The connection is the very first information that ModSecurity can
>      * inspect. It is expected to happens before the virtual host name be
>      * resolved. This phase is expected to happen immediately after a
>      * connection is established.
>      *
>      */
>      ConnectionPhase,
>     /**
>      *
>      * The "URI" phase happens just after the web server (or any other
>      * application that you may use with ModSecurity) have the
> acknowledgement
>      * of the full request URI.
>      *
>      */
>      UriPhase,
>     /**
>      *
>      * The "RequestHeaders" phase happens when the server has all the
>      * information about the headers. Notice however, that it is expected
> to
>      * happen prior to the reception of the request body (if any).
>      *
>      */
>      RequestHeadersPhase,
>      [...]
> ```
>
>
>
> Extract of src/actions/phase.cc file
>
> ```
> #include "src/actions/phase.h"
>
> #include <iostream>
> #include <string>
>
> #include "modsecurity/transaction.h"
> #include "modsecurity/rule.h"
> #include "modsecurity/modsecurity.h"
> #include "src/utils/string.h"
>
>
> namespace modsecurity {
> namespace actions {
>
> bool Phase::init(std::string *error) {
>     std::string a = utils::string::tolower(m_parser_payload);
>     m_phase = -1;
>
>     try {
>         m_phase = std::stoi(m_parser_payload);
>         if (m_phase == 0) {
>             m_phase = modsecurity::Phases::ConnectionPhase;
>             m_secRulesPhase = 0;
>         } else if (m_phase == 1) {
>             m_phase = modsecurity::Phases::RequestHeadersPhase;
>             m_secRulesPhase = 1;
>         } else if (m_phase == 2) {
>             m_phase = modsecurity::Phases::RequestBodyPhase;
>             m_secRulesPhase = 2;
>         } else if (m_phase == 3) {
>             m_phase = modsecurity::Phases::ResponseHeadersPhase;
>             m_secRulesPhase = 3;
>         } else if (m_phase == 4) {
>             m_phase = modsecurity::Phases::ResponseBodyPhase;
>             m_secRulesPhase = 4;
>         } else if (m_phase == 5) {
>             m_phase = modsecurity::Phases::LoggingPhase;
>             m_secRulesPhase = 5;
>         }
>     } catch (...) {
>         if (a == "request") {
>             m_phase = modsecurity::Phases::RequestBodyPhase;
>             m_secRulesPhase = 2;
>         } else if (a == "response") {
>             m_phase = modsecurity::Phases::ResponseBodyPhase;
>             m_secRulesPhase = 4;
>         } else if (a == "logging") {
>             m_phase = modsecurity::Phases::LoggingPhase;
>             m_secRulesPhase = 5;
>         }
>     }
> ```
>
> Br.
>
> --
> Fred
> sup...@gm...
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
>



-- 
Support Développement
sup...@gm...