Thread: [mod-security-users] Questions about STREAM_INPUT_BODY
Brought to you by:
victorhora,
zimmerletw
From: Ivan R. <iva...@gm...> - 2011-04-27 19:58:26
|
I have a couple of questions about STREAM_INPUT_BODY: - For STREAM_INPUT_BODY, the manual states that using @pm with it is better because the matching takes place before phase 2. But when I look at my debug logs, I see the @pm rule against STREAM_INPUT_BODY execute in phase 2, just as any other rule. - STREAM_INPUT_BODY contains the raw request body, no matter of content type -- is that correct? - What is the impact on memory consumption when SecStreamInBodyInspection is enabled? - Is the maximum size of the buffer still controlled with SecRequestBodyLimit? - Does that mean that when SecStreamInBodyInspection is enabled, it effectively breaks the safety provided by SecRequestBodyNoFilesLimit (meaning that large file uploads will be fully buffered in RAM)? -- Ivan Ristić |
From: Breno S. <bre...@gm...> - 2011-04-27 20:17:37
|
STREAM_* variables are similar to its pairs body buffers. It runs in the same phase and the limits should work the same. However STREAM_* are created to be reallocable buffer for more complex data modifications like rsub operators and others in the future. When you enable SecStream* directives you will consume more memory. On Wed, Apr 27, 2011 at 2:58 PM, Ivan Ristic <iva...@gm...> wrote: > I have a couple of questions about STREAM_INPUT_BODY: > > - For STREAM_INPUT_BODY, the manual states that using @pm with it is > better because the matching takes place before phase 2. But when I > look at my debug logs, I see the @pm rule against STREAM_INPUT_BODY > execute in phase 2, just as any other rule. > > - STREAM_INPUT_BODY contains the raw request body, no matter of > content type -- is that correct? > > - What is the impact on memory consumption when > SecStreamInBodyInspection is enabled? > > - Is the maximum size of the buffer still controlled with > SecRequestBodyLimit? > > - Does that mean that when SecStreamInBodyInspection is enabled, it > effectively breaks the safety provided by SecRequestBodyNoFilesLimit > (meaning that large file uploads will be fully buffered in RAM)? > > -- > Ivan Ristić > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > ModSecurity Services from Trustwave's SpiderLabs: > https://www.trustwave.com/spiderLabs.php > |
From: Ivan R. <iva...@gm...> - 2011-04-27 21:17:14
|
Looking at STREAM_OUTPUT_BODY now -- how is it different from RESPONSE_BODY? I see no difference, except that the memory consumption is buffered because response bodies are stored twice when SecStreamOutBodyInspection is enabled? Maybe I am not looking in the right places? On Wed, Apr 27, 2011 at 9:17 PM, Breno Silva <bre...@gm...> wrote: > STREAM_* variables are similar to its pairs body buffers. It runs in the > same phase and the limits should work the same. > However STREAM_* are created to be reallocable buffer for more complex data > modifications like rsub operators and others in the future. > > When you enable SecStream* directives you will consume more memory. > > On Wed, Apr 27, 2011 at 2:58 PM, Ivan Ristic <iva...@gm...> wrote: >> >> I have a couple of questions about STREAM_INPUT_BODY: >> >> - For STREAM_INPUT_BODY, the manual states that using @pm with it is >> better because the matching takes place before phase 2. But when I >> look at my debug logs, I see the @pm rule against STREAM_INPUT_BODY >> execute in phase 2, just as any other rule. >> >> - STREAM_INPUT_BODY contains the raw request body, no matter of >> content type -- is that correct? >> >> - What is the impact on memory consumption when >> SecStreamInBodyInspection is enabled? >> >> - Is the maximum size of the buffer still controlled with >> SecRequestBodyLimit? >> >> - Does that mean that when SecStreamInBodyInspection is enabled, it >> effectively breaks the safety provided by SecRequestBodyNoFilesLimit >> (meaning that large file uploads will be fully buffered in RAM)? >> >> -- >> Ivan Ristić >> >> >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> mod-security-users mailing list >> mod...@li... >> https://lists.sourceforge.net/lists/listinfo/mod-security-users >> ModSecurity Services from Trustwave's SpiderLabs: >> https://www.trustwave.com/spiderLabs.php > > -- Ivan Ristić |
From: Ivan R. <iva...@gm...> - 2011-04-27 21:14:35
|
I think you should have reused REQUEST_BODY, seeing that the only thing different about STREAM_INPUT_BODY is that it is always there (whereas REQUEST_BODY is only there for application/x-www-form-urlencoded C-T). The SecStreamInBodyInspection could have easily controlled the presence of REQUEST_BODY. On Wed, Apr 27, 2011 at 9:17 PM, Breno Silva <bre...@gm...> wrote: > STREAM_* variables are similar to its pairs body buffers. It runs in the > same phase and the limits should work the same. > However STREAM_* are created to be reallocable buffer for more complex data > modifications like rsub operators and others in the future. > > When you enable SecStream* directives you will consume more memory. > > On Wed, Apr 27, 2011 at 2:58 PM, Ivan Ristic <iva...@gm...> wrote: >> >> I have a couple of questions about STREAM_INPUT_BODY: >> >> - For STREAM_INPUT_BODY, the manual states that using @pm with it is >> better because the matching takes place before phase 2. But when I >> look at my debug logs, I see the @pm rule against STREAM_INPUT_BODY >> execute in phase 2, just as any other rule. >> >> - STREAM_INPUT_BODY contains the raw request body, no matter of >> content type -- is that correct? >> >> - What is the impact on memory consumption when >> SecStreamInBodyInspection is enabled? >> >> - Is the maximum size of the buffer still controlled with >> SecRequestBodyLimit? >> >> - Does that mean that when SecStreamInBodyInspection is enabled, it >> effectively breaks the safety provided by SecRequestBodyNoFilesLimit >> (meaning that large file uploads will be fully buffered in RAM)? >> >> -- >> Ivan Ristić >> >> >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> mod-security-users mailing list >> mod...@li... >> https://lists.sourceforge.net/lists/listinfo/mod-security-users >> ModSecurity Services from Trustwave's SpiderLabs: >> https://www.trustwave.com/spiderLabs.php > > -- Ivan Ristić |
From: Ryan B. <RBa...@tr...> - 2011-04-27 21:33:33
|
Breno has the details but the difference is that the STREAM_ variables can be swapped back into the live transaction for data modification. On Apr 27, 2011, at 5:17 PM, "Ivan Ristic" <iva...@gm...> wrote: > I think you should have reused REQUEST_BODY, seeing that the only > thing different about STREAM_INPUT_BODY is that it is always there > (whereas REQUEST_BODY is only there for > application/x-www-form-urlencoded C-T). The SecStreamInBodyInspection > could have easily controlled the presence of REQUEST_BODY. > > > On Wed, Apr 27, 2011 at 9:17 PM, Breno Silva <bre...@gm...> wrote: >> STREAM_* variables are similar to its pairs body buffers. It runs in the >> same phase and the limits should work the same. >> However STREAM_* are created to be reallocable buffer for more complex data >> modifications like rsub operators and others in the future. >> >> When you enable SecStream* directives you will consume more memory. >> >> On Wed, Apr 27, 2011 at 2:58 PM, Ivan Ristic <iva...@gm...> wrote: >>> >>> I have a couple of questions about STREAM_INPUT_BODY: >>> >>> - For STREAM_INPUT_BODY, the manual states that using @pm with it is >>> better because the matching takes place before phase 2. But when I >>> look at my debug logs, I see the @pm rule against STREAM_INPUT_BODY >>> execute in phase 2, just as any other rule. >>> >>> - STREAM_INPUT_BODY contains the raw request body, no matter of >>> content type -- is that correct? >>> >>> - What is the impact on memory consumption when >>> SecStreamInBodyInspection is enabled? >>> >>> - Is the maximum size of the buffer still controlled with >>> SecRequestBodyLimit? >>> >>> - Does that mean that when SecStreamInBodyInspection is enabled, it >>> effectively breaks the safety provided by SecRequestBodyNoFilesLimit >>> (meaning that large file uploads will be fully buffered in RAM)? >>> >>> -- >>> Ivan Ristić >>> >>> >>> ------------------------------------------------------------------------------ >>> WhatsUp Gold - Download Free Network Management Software >>> The most intuitive, comprehensive, and cost-effective network >>> management toolset available today. Delivers lowest initial >>> acquisition cost and overall TCO of any competing solution. >>> http://p.sf.net/sfu/whatsupgold-sd >>> _______________________________________________ >>> mod-security-users mailing list >>> mod...@li... >>> https://lists.sourceforge.net/lists/listinfo/mod-security-users >>> ModSecurity Services from Trustwave's SpiderLabs: >>> https://www.trustwave.com/spiderLabs.php >> >> > > > > -- > Ivan Ristić > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > ModSecurity Services from Trustwave's SpiderLabs: > https://www.trustwave.com/spiderLabs.php This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. |
From: Ivan R. <iva...@gm...> - 2011-04-28 18:33:26
|
Well that's the thing. I looked at the code, and there's practically no difference, and no reason why @rsub can't be made to work with REQUEST_BODY and RESPONSE_BODY. Also, the "stream" part of the name is very misleading, because there's no streaming going on. On Wed, Apr 27, 2011 at 10:32 PM, Ryan Barnett <RBa...@tr...> wrote: > Breno has the details but the difference is that the STREAM_ variables can be swapped back into the live transaction for data modification. > > On Apr 27, 2011, at 5:17 PM, "Ivan Ristic" <iva...@gm...> wrote: > >> I think you should have reused REQUEST_BODY, seeing that the only >> thing different about STREAM_INPUT_BODY is that it is always there >> (whereas REQUEST_BODY is only there for >> application/x-www-form-urlencoded C-T). The SecStreamInBodyInspection >> could have easily controlled the presence of REQUEST_BODY. >> >> >> On Wed, Apr 27, 2011 at 9:17 PM, Breno Silva <bre...@gm...> wrote: >>> STREAM_* variables are similar to its pairs body buffers. It runs in the >>> same phase and the limits should work the same. >>> However STREAM_* are created to be reallocable buffer for more complex data >>> modifications like rsub operators and others in the future. >>> >>> When you enable SecStream* directives you will consume more memory. >>> >>> On Wed, Apr 27, 2011 at 2:58 PM, Ivan Ristic <iva...@gm...> wrote: >>>> >>>> I have a couple of questions about STREAM_INPUT_BODY: >>>> >>>> - For STREAM_INPUT_BODY, the manual states that using @pm with it is >>>> better because the matching takes place before phase 2. But when I >>>> look at my debug logs, I see the @pm rule against STREAM_INPUT_BODY >>>> execute in phase 2, just as any other rule. >>>> >>>> - STREAM_INPUT_BODY contains the raw request body, no matter of >>>> content type -- is that correct? >>>> >>>> - What is the impact on memory consumption when >>>> SecStreamInBodyInspection is enabled? >>>> >>>> - Is the maximum size of the buffer still controlled with >>>> SecRequestBodyLimit? >>>> >>>> - Does that mean that when SecStreamInBodyInspection is enabled, it >>>> effectively breaks the safety provided by SecRequestBodyNoFilesLimit >>>> (meaning that large file uploads will be fully buffered in RAM)? >>>> >>>> -- >>>> Ivan Ristić >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> WhatsUp Gold - Download Free Network Management Software >>>> The most intuitive, comprehensive, and cost-effective network >>>> management toolset available today. Delivers lowest initial >>>> acquisition cost and overall TCO of any competing solution. >>>> http://p.sf.net/sfu/whatsupgold-sd >>>> _______________________________________________ >>>> mod-security-users mailing list >>>> mod...@li... >>>> https://lists.sourceforge.net/lists/listinfo/mod-security-users >>>> ModSecurity Services from Trustwave's SpiderLabs: >>>> https://www.trustwave.com/spiderLabs.php >>> >>> >> >> >> >> -- >> Ivan Ristić >> >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> mod-security-users mailing list >> mod...@li... >> https://lists.sourceforge.net/lists/listinfo/mod-security-users >> ModSecurity Services from Trustwave's SpiderLabs: >> https://www.trustwave.com/spiderLabs.php > > This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. > -- Ivan Ristić |
From: Breno S. <bre...@gm...> - 2011-04-28 19:26:43
|
stream* is there to be now reallocable buffers. it will be used in the future for connection level buffers. and i will not do that with reqbody_ and resbody_ data. Also .. resbody_data is using apr to alloc data which is much more faster that malloc. I don't think is a good idea try to realloc apr data and will make the management for difficult . Also input streams should have all kind of request body... reqbody buffer appears to not have data in some conten-types. On Thu, Apr 28, 2011 at 1:33 PM, Ivan Ristic <iva...@gm...> wrote: > Well that's the thing. I looked at the code, and there's practically > no difference, and no reason why @rsub can't be made to work with > REQUEST_BODY and RESPONSE_BODY. > > Also, the "stream" part of the name is very misleading, because > there's no streaming going on. > > > On Wed, Apr 27, 2011 at 10:32 PM, Ryan Barnett <RBa...@tr...> > wrote: > > Breno has the details but the difference is that the STREAM_ variables > can be swapped back into the live transaction for data modification. > > > > On Apr 27, 2011, at 5:17 PM, "Ivan Ristic" <iva...@gm...> > wrote: > > > >> I think you should have reused REQUEST_BODY, seeing that the only > >> thing different about STREAM_INPUT_BODY is that it is always there > >> (whereas REQUEST_BODY is only there for > >> application/x-www-form-urlencoded C-T). The SecStreamInBodyInspection > >> could have easily controlled the presence of REQUEST_BODY. > >> > >> > >> On Wed, Apr 27, 2011 at 9:17 PM, Breno Silva <bre...@gm...> > wrote: > >>> STREAM_* variables are similar to its pairs body buffers. It runs in > the > >>> same phase and the limits should work the same. > >>> However STREAM_* are created to be reallocable buffer for more complex > data > >>> modifications like rsub operators and others in the future. > >>> > >>> When you enable SecStream* directives you will consume more memory. > >>> > >>> On Wed, Apr 27, 2011 at 2:58 PM, Ivan Ristic <iva...@gm...> > wrote: > >>>> > >>>> I have a couple of questions about STREAM_INPUT_BODY: > >>>> > >>>> - For STREAM_INPUT_BODY, the manual states that using @pm with it is > >>>> better because the matching takes place before phase 2. But when I > >>>> look at my debug logs, I see the @pm rule against STREAM_INPUT_BODY > >>>> execute in phase 2, just as any other rule. > >>>> > >>>> - STREAM_INPUT_BODY contains the raw request body, no matter of > >>>> content type -- is that correct? > >>>> > >>>> - What is the impact on memory consumption when > >>>> SecStreamInBodyInspection is enabled? > >>>> > >>>> - Is the maximum size of the buffer still controlled with > >>>> SecRequestBodyLimit? > >>>> > >>>> - Does that mean that when SecStreamInBodyInspection is enabled, it > >>>> effectively breaks the safety provided by SecRequestBodyNoFilesLimit > >>>> (meaning that large file uploads will be fully buffered in RAM)? > >>>> > >>>> -- > >>>> Ivan Ristić > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> WhatsUp Gold - Download Free Network Management Software > >>>> The most intuitive, comprehensive, and cost-effective network > >>>> management toolset available today. Delivers lowest initial > >>>> acquisition cost and overall TCO of any competing solution. > >>>> http://p.sf.net/sfu/whatsupgold-sd > >>>> _______________________________________________ > >>>> mod-security-users mailing list > >>>> mod...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/mod-security-users > >>>> ModSecurity Services from Trustwave's SpiderLabs: > >>>> https://www.trustwave.com/spiderLabs.php > >>> > >>> > >> > >> > >> > >> -- > >> Ivan Ristić > >> > >> > ------------------------------------------------------------------------------ > >> WhatsUp Gold - Download Free Network Management Software > >> The most intuitive, comprehensive, and cost-effective network > >> management toolset available today. Delivers lowest initial > >> acquisition cost and overall TCO of any competing solution. > >> http://p.sf.net/sfu/whatsupgold-sd > >> _______________________________________________ > >> mod-security-users mailing list > >> mod...@li... > >> https://lists.sourceforge.net/lists/listinfo/mod-security-users > >> ModSecurity Services from Trustwave's SpiderLabs: > >> https://www.trustwave.com/spiderLabs.php > > > > This transmission may contain information that is privileged, > confidential, and/or exempt from disclosure under applicable law. If you are > not the intended recipient, you are hereby notified that any disclosure, > copying, distribution, or use of the information contained herein (including > any reliance thereon) is STRICTLY PROHIBITED. If you received this > transmission in error, please immediately contact the sender and destroy the > material in its entirety, whether in electronic or hard copy format. > > > > > > -- > Ivan Ristić > |
From: Breno S. <bre...@gm...> - 2011-04-28 19:29:44
|
Also .. i want to change the reqbody to be alloced by apr. On Thu, Apr 28, 2011 at 2:26 PM, Breno Silva <bre...@gm...> wrote: > stream* is there to be now reallocable buffers. it will be used in the > future for connection level buffers. and i will not do that with reqbody_ > and resbody_ data. > > Also .. resbody_data is using apr to alloc data which is much more faster > that malloc. I don't think is a good idea try to realloc apr data and will > make the management for difficult . Also input streams should have all kind > of request body... reqbody buffer appears to not have data in some > conten-types. > > > On Thu, Apr 28, 2011 at 1:33 PM, Ivan Ristic <iva...@gm...>wrote: > >> Well that's the thing. I looked at the code, and there's practically >> no difference, and no reason why @rsub can't be made to work with >> REQUEST_BODY and RESPONSE_BODY. >> >> Also, the "stream" part of the name is very misleading, because >> there's no streaming going on. >> >> >> On Wed, Apr 27, 2011 at 10:32 PM, Ryan Barnett <RBa...@tr...> >> wrote: >> > Breno has the details but the difference is that the STREAM_ variables >> can be swapped back into the live transaction for data modification. >> > >> > On Apr 27, 2011, at 5:17 PM, "Ivan Ristic" <iva...@gm...> >> wrote: >> > >> >> I think you should have reused REQUEST_BODY, seeing that the only >> >> thing different about STREAM_INPUT_BODY is that it is always there >> >> (whereas REQUEST_BODY is only there for >> >> application/x-www-form-urlencoded C-T). The SecStreamInBodyInspection >> >> could have easily controlled the presence of REQUEST_BODY. >> >> >> >> >> >> On Wed, Apr 27, 2011 at 9:17 PM, Breno Silva <bre...@gm...> >> wrote: >> >>> STREAM_* variables are similar to its pairs body buffers. It runs in >> the >> >>> same phase and the limits should work the same. >> >>> However STREAM_* are created to be reallocable buffer for more complex >> data >> >>> modifications like rsub operators and others in the future. >> >>> >> >>> When you enable SecStream* directives you will consume more memory. >> >>> >> >>> On Wed, Apr 27, 2011 at 2:58 PM, Ivan Ristic <iva...@gm...> >> wrote: >> >>>> >> >>>> I have a couple of questions about STREAM_INPUT_BODY: >> >>>> >> >>>> - For STREAM_INPUT_BODY, the manual states that using @pm with it is >> >>>> better because the matching takes place before phase 2. But when I >> >>>> look at my debug logs, I see the @pm rule against STREAM_INPUT_BODY >> >>>> execute in phase 2, just as any other rule. >> >>>> >> >>>> - STREAM_INPUT_BODY contains the raw request body, no matter of >> >>>> content type -- is that correct? >> >>>> >> >>>> - What is the impact on memory consumption when >> >>>> SecStreamInBodyInspection is enabled? >> >>>> >> >>>> - Is the maximum size of the buffer still controlled with >> >>>> SecRequestBodyLimit? >> >>>> >> >>>> - Does that mean that when SecStreamInBodyInspection is enabled, it >> >>>> effectively breaks the safety provided by SecRequestBodyNoFilesLimit >> >>>> (meaning that large file uploads will be fully buffered in RAM)? >> >>>> >> >>>> -- >> >>>> Ivan Ristić >> >>>> >> >>>> >> >>>> >> ------------------------------------------------------------------------------ >> >>>> WhatsUp Gold - Download Free Network Management Software >> >>>> The most intuitive, comprehensive, and cost-effective network >> >>>> management toolset available today. Delivers lowest initial >> >>>> acquisition cost and overall TCO of any competing solution. >> >>>> http://p.sf.net/sfu/whatsupgold-sd >> >>>> _______________________________________________ >> >>>> mod-security-users mailing list >> >>>> mod...@li... >> >>>> https://lists.sourceforge.net/lists/listinfo/mod-security-users >> >>>> ModSecurity Services from Trustwave's SpiderLabs: >> >>>> https://www.trustwave.com/spiderLabs.php >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Ivan Ristić >> >> >> >> >> ------------------------------------------------------------------------------ >> >> WhatsUp Gold - Download Free Network Management Software >> >> The most intuitive, comprehensive, and cost-effective network >> >> management toolset available today. Delivers lowest initial >> >> acquisition cost and overall TCO of any competing solution. >> >> http://p.sf.net/sfu/whatsupgold-sd >> >> _______________________________________________ >> >> mod-security-users mailing list >> >> mod...@li... >> >> https://lists.sourceforge.net/lists/listinfo/mod-security-users >> >> ModSecurity Services from Trustwave's SpiderLabs: >> >> https://www.trustwave.com/spiderLabs.php >> > >> > This transmission may contain information that is privileged, >> confidential, and/or exempt from disclosure under applicable law. If you are >> not the intended recipient, you are hereby notified that any disclosure, >> copying, distribution, or use of the information contained herein (including >> any reliance thereon) is STRICTLY PROHIBITED. If you received this >> transmission in error, please immediately contact the sender and destroy the >> material in its entirety, whether in electronic or hard copy format. >> > >> >> >> >> -- >> Ivan Ristić >> > > |
From: Breno S. <bre...@gm...> - 2011-04-28 20:59:38
|
Another reason... i still didn't to it .. but i'm thinking to deny transformations to be applied in stream* variables... since it can be reinjected and can break the data in the browser. So .. if i decided to use the current buffers i cannot do that. 2011/4/28 Breno Silva <bre...@gm...> > Also .. i want to change the reqbody to be alloced by apr. > > > On Thu, Apr 28, 2011 at 2:26 PM, Breno Silva <bre...@gm...>wrote: > >> stream* is there to be now reallocable buffers. it will be used in the >> future for connection level buffers. and i will not do that with reqbody_ >> and resbody_ data. >> >> Also .. resbody_data is using apr to alloc data which is much more faster >> that malloc. I don't think is a good idea try to realloc apr data and will >> make the management for difficult . Also input streams should have all kind >> of request body... reqbody buffer appears to not have data in some >> conten-types. >> >> >> On Thu, Apr 28, 2011 at 1:33 PM, Ivan Ristic <iva...@gm...>wrote: >> >>> Well that's the thing. I looked at the code, and there's practically >>> no difference, and no reason why @rsub can't be made to work with >>> REQUEST_BODY and RESPONSE_BODY. >>> >>> Also, the "stream" part of the name is very misleading, because >>> there's no streaming going on. >>> >>> >>> On Wed, Apr 27, 2011 at 10:32 PM, Ryan Barnett <RBa...@tr...> >>> wrote: >>> > Breno has the details but the difference is that the STREAM_ variables >>> can be swapped back into the live transaction for data modification. >>> > >>> > On Apr 27, 2011, at 5:17 PM, "Ivan Ristic" <iva...@gm...> >>> wrote: >>> > >>> >> I think you should have reused REQUEST_BODY, seeing that the only >>> >> thing different about STREAM_INPUT_BODY is that it is always there >>> >> (whereas REQUEST_BODY is only there for >>> >> application/x-www-form-urlencoded C-T). The SecStreamInBodyInspection >>> >> could have easily controlled the presence of REQUEST_BODY. >>> >> >>> >> >>> >> On Wed, Apr 27, 2011 at 9:17 PM, Breno Silva <bre...@gm...> >>> wrote: >>> >>> STREAM_* variables are similar to its pairs body buffers. It runs in >>> the >>> >>> same phase and the limits should work the same. >>> >>> However STREAM_* are created to be reallocable buffer for more >>> complex data >>> >>> modifications like rsub operators and others in the future. >>> >>> >>> >>> When you enable SecStream* directives you will consume more memory. >>> >>> >>> >>> On Wed, Apr 27, 2011 at 2:58 PM, Ivan Ristic <iva...@gm...> >>> wrote: >>> >>>> >>> >>>> I have a couple of questions about STREAM_INPUT_BODY: >>> >>>> >>> >>>> - For STREAM_INPUT_BODY, the manual states that using @pm with it is >>> >>>> better because the matching takes place before phase 2. But when I >>> >>>> look at my debug logs, I see the @pm rule against STREAM_INPUT_BODY >>> >>>> execute in phase 2, just as any other rule. >>> >>>> >>> >>>> - STREAM_INPUT_BODY contains the raw request body, no matter of >>> >>>> content type -- is that correct? >>> >>>> >>> >>>> - What is the impact on memory consumption when >>> >>>> SecStreamInBodyInspection is enabled? >>> >>>> >>> >>>> - Is the maximum size of the buffer still controlled with >>> >>>> SecRequestBodyLimit? >>> >>>> >>> >>>> - Does that mean that when SecStreamInBodyInspection is enabled, it >>> >>>> effectively breaks the safety provided by SecRequestBodyNoFilesLimit >>> >>>> (meaning that large file uploads will be fully buffered in RAM)? >>> >>>> >>> >>>> -- >>> >>>> Ivan Ristić >>> >>>> >>> >>>> >>> >>>> >>> ------------------------------------------------------------------------------ >>> >>>> WhatsUp Gold - Download Free Network Management Software >>> >>>> The most intuitive, comprehensive, and cost-effective network >>> >>>> management toolset available today. Delivers lowest initial >>> >>>> acquisition cost and overall TCO of any competing solution. >>> >>>> http://p.sf.net/sfu/whatsupgold-sd >>> >>>> _______________________________________________ >>> >>>> mod-security-users mailing list >>> >>>> mod...@li... >>> >>>> https://lists.sourceforge.net/lists/listinfo/mod-security-users >>> >>>> ModSecurity Services from Trustwave's SpiderLabs: >>> >>>> https://www.trustwave.com/spiderLabs.php >>> >>> >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Ivan Ristić >>> >> >>> >> >>> ------------------------------------------------------------------------------ >>> >> WhatsUp Gold - Download Free Network Management Software >>> >> The most intuitive, comprehensive, and cost-effective network >>> >> management toolset available today. Delivers lowest initial >>> >> acquisition cost and overall TCO of any competing solution. >>> >> http://p.sf.net/sfu/whatsupgold-sd >>> >> _______________________________________________ >>> >> mod-security-users mailing list >>> >> mod...@li... >>> >> https://lists.sourceforge.net/lists/listinfo/mod-security-users >>> >> ModSecurity Services from Trustwave's SpiderLabs: >>> >> https://www.trustwave.com/spiderLabs.php >>> > >>> > This transmission may contain information that is privileged, >>> confidential, and/or exempt from disclosure under applicable law. If you are >>> not the intended recipient, you are hereby notified that any disclosure, >>> copying, distribution, or use of the information contained herein (including >>> any reliance thereon) is STRICTLY PROHIBITED. If you received this >>> transmission in error, please immediately contact the sender and destroy the >>> material in its entirety, whether in electronic or hard copy format. >>> > >>> >>> >>> >>> -- >>> Ivan Ristić >>> >> >> > |
From: Ivan R. <iva...@gm...> - 2011-04-28 23:49:18
|
You missed my point, which is that users don't care and shouldn't need to be aware of implementation details. The task at hand (protecting applications) is difficult as it is. Come to think about it, I don't even care about the implementation details ;) 2011/4/28 Breno Silva <bre...@gm...>: > Another reason... i still didn't to it .. but i'm thinking to deny > transformations to be applied in stream* variables... since it can be > reinjected and can break the data in the browser. > So .. if i decided to use the current buffers i cannot do that. > > 2011/4/28 Breno Silva <bre...@gm...> >> >> Also .. i want to change the reqbody to be alloced by apr. >> >> On Thu, Apr 28, 2011 at 2:26 PM, Breno Silva <bre...@gm...> >> wrote: >>> >>> stream* is there to be now reallocable buffers. it will be used in the >>> future for connection level buffers. and i will not do that with reqbody_ >>> and resbody_ data. >>> >>> Also .. resbody_data is using apr to alloc data which is much more faster >>> that malloc. I don't think is a good idea try to realloc apr data and will >>> make the management for difficult . Also input streams should have all kind >>> of request body... reqbody buffer appears to not have data in some >>> conten-types. >>> >>> On Thu, Apr 28, 2011 at 1:33 PM, Ivan Ristic <iva...@gm...> >>> wrote: >>>> >>>> Well that's the thing. I looked at the code, and there's practically >>>> no difference, and no reason why @rsub can't be made to work with >>>> REQUEST_BODY and RESPONSE_BODY. >>>> >>>> Also, the "stream" part of the name is very misleading, because >>>> there's no streaming going on. >>>> >>>> >>>> On Wed, Apr 27, 2011 at 10:32 PM, Ryan Barnett <RBa...@tr...> >>>> wrote: >>>> > Breno has the details but the difference is that the STREAM_ variables >>>> > can be swapped back into the live transaction for data modification. >>>> > >>>> > On Apr 27, 2011, at 5:17 PM, "Ivan Ristic" <iva...@gm...> >>>> > wrote: >>>> > >>>> >> I think you should have reused REQUEST_BODY, seeing that the only >>>> >> thing different about STREAM_INPUT_BODY is that it is always there >>>> >> (whereas REQUEST_BODY is only there for >>>> >> application/x-www-form-urlencoded C-T). The SecStreamInBodyInspection >>>> >> could have easily controlled the presence of REQUEST_BODY. >>>> >> >>>> >> >>>> >> On Wed, Apr 27, 2011 at 9:17 PM, Breno Silva <bre...@gm...> >>>> >> wrote: >>>> >>> STREAM_* variables are similar to its pairs body buffers. It runs in >>>> >>> the >>>> >>> same phase and the limits should work the same. >>>> >>> However STREAM_* are created to be reallocable buffer for more >>>> >>> complex data >>>> >>> modifications like rsub operators and others in the future. >>>> >>> >>>> >>> When you enable SecStream* directives you will consume more memory. >>>> >>> >>>> >>> On Wed, Apr 27, 2011 at 2:58 PM, Ivan Ristic <iva...@gm...> >>>> >>> wrote: >>>> >>>> >>>> >>>> I have a couple of questions about STREAM_INPUT_BODY: >>>> >>>> >>>> >>>> - For STREAM_INPUT_BODY, the manual states that using @pm with it >>>> >>>> is >>>> >>>> better because the matching takes place before phase 2. But when I >>>> >>>> look at my debug logs, I see the @pm rule against STREAM_INPUT_BODY >>>> >>>> execute in phase 2, just as any other rule. >>>> >>>> >>>> >>>> - STREAM_INPUT_BODY contains the raw request body, no matter of >>>> >>>> content type -- is that correct? >>>> >>>> >>>> >>>> - What is the impact on memory consumption when >>>> >>>> SecStreamInBodyInspection is enabled? >>>> >>>> >>>> >>>> - Is the maximum size of the buffer still controlled with >>>> >>>> SecRequestBodyLimit? >>>> >>>> >>>> >>>> - Does that mean that when SecStreamInBodyInspection is enabled, it >>>> >>>> effectively breaks the safety provided by >>>> >>>> SecRequestBodyNoFilesLimit >>>> >>>> (meaning that large file uploads will be fully buffered in RAM)? >>>> >>>> >>>> >>>> -- >>>> >>>> Ivan Ristić >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> WhatsUp Gold - Download Free Network Management Software >>>> >>>> The most intuitive, comprehensive, and cost-effective network >>>> >>>> management toolset available today. Delivers lowest initial >>>> >>>> acquisition cost and overall TCO of any competing solution. >>>> >>>> http://p.sf.net/sfu/whatsupgold-sd >>>> >>>> _______________________________________________ >>>> >>>> mod-security-users mailing list >>>> >>>> mod...@li... >>>> >>>> https://lists.sourceforge.net/lists/listinfo/mod-security-users >>>> >>>> ModSecurity Services from Trustwave's SpiderLabs: >>>> >>>> https://www.trustwave.com/spiderLabs.php >>>> >>> >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Ivan Ristić >>>> >> >>>> >> >>>> >> ------------------------------------------------------------------------------ >>>> >> WhatsUp Gold - Download Free Network Management Software >>>> >> The most intuitive, comprehensive, and cost-effective network >>>> >> management toolset available today. Delivers lowest initial >>>> >> acquisition cost and overall TCO of any competing solution. >>>> >> http://p.sf.net/sfu/whatsupgold-sd >>>> >> _______________________________________________ >>>> >> mod-security-users mailing list >>>> >> mod...@li... >>>> >> https://lists.sourceforge.net/lists/listinfo/mod-security-users >>>> >> ModSecurity Services from Trustwave's SpiderLabs: >>>> >> https://www.trustwave.com/spiderLabs.php >>>> > >>>> > This transmission may contain information that is privileged, >>>> > confidential, and/or exempt from disclosure under applicable law. If you are >>>> > not the intended recipient, you are hereby notified that any disclosure, >>>> > copying, distribution, or use of the information contained herein (including >>>> > any reliance thereon) is STRICTLY PROHIBITED. If you received this >>>> > transmission in error, please immediately contact the sender and destroy the >>>> > material in its entirety, whether in electronic or hard copy format. >>>> > >>>> >>>> >>>> >>>> -- >>>> Ivan Ristić >>> >> > > -- Ivan Ristić |
From: Christian B. <ch...@jw...> - 2011-04-29 07:14:24
|
Am 29.04.2011 um 01:49 schrieb Ivan Ristic: > You missed my point, which is that users don't care and shouldn't need > to be aware of implementation details. The task at hand (protecting > applications) is difficult as it is. Thanks for pointing that out, Ivan. I believe this is what makes a lot of people struggle, just reminding of the phase-1-rules-inside-Location directives dilemma. Chris |
From: Breno S. <bre...@gm...> - 2011-04-29 13:09:46
|
Ivan, You asked about STREAM*. I answer that must be used to data substitution. You asked again why don't use the current buffers. And i gave you the details. I think it is clear. Please if you want more technical details. Please submit the questions to devel-list. There is no reason to discuss this details here. Thanks Breno On Fri, Apr 29, 2011 at 2:14 AM, Christian Bockermann <ch...@jw...>wrote: > > Am 29.04.2011 um 01:49 schrieb Ivan Ristic: > > > You missed my point, which is that users don't care and shouldn't need > > to be aware of implementation details. The task at hand (protecting > > applications) is difficult as it is. > > Thanks for pointing that out, Ivan. I believe this is what makes a lot of > people struggle, just reminding of the phase-1-rules-inside-Location > directives > dilemma. > > Chris > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > ModSecurity Services from Trustwave's SpiderLabs: > https://www.trustwave.com/spiderLabs.php > |