Let's have this discussion on "devel" list :)

On Mon, Jul 23, 2012 at 5:29 AM, rm4dillo D <rm4dillo@gmail.com> wrote:
Hello Breno,

There's still an issue. Suppose, that "ruleUpdateTargetById" action is clumsily called after the rule it's trying to modify; the "restore_targets" will be set to 2 after the first matching request, then even if the second request does not match the exception condition it will be set to 1 by the "rule->restore_targets--" decrementaion and the targets will not be restored before applying rules.

I tried moving the restore targets loop to the end of the "modsecurity_process_phase" function in "modsecurity.c" and it fixed this issue. In addition to this, I think it's cleaner as you will simply have to set "restore_targets" to 1 instead of 2 and set it to 0 after restore and you can remove the "restore_targets" decrementation.

What do you think of that?


On Fri, Jul 20, 2012 at 6:24 PM, Breno Silva <breno.silva@gmail.com> wrote:
If anybody else is available to test it (included into new 2.6.7)  please let me know. I will send the tarball.



On Fri, Jul 20, 2012 at 3:23 AM, rm4dillo D <rm4dillo@gmail.com> wrote:
Of course. I'll be glad to test it.

Applying the changes and then reverting them is a good idea and it might be easier if the rules are modified just before they are used somewhere in "msre_ruleset_process_phase" and reverted just after?

Somewhat like this:

... msre_ruleset_process_phase() {
rule_modify(rule, msr->exception_target_modification_list[rule->actionset->id]);
use rule...
rule_revert(rule, msr->exception_target_modification_list[rule->actionset->id]);

On Thu, Jul 19, 2012 at 11:47 PM, Breno Silva <breno.silva@gmail.com> wrote:

I have a patch for this. Can i send you a tarball for testing ?



On Thu, Jul 19, 2012 at 12:49 PM, Breno Silva <breno.silva@gmail.com> wrote:
I'm already using it in 2.7.0 but this will not change the behavior. Because i need to change the ruleset. I think the only way we could do that is store the ctl:ruleUpdateTargetById fields somewhere and revert the changes in ruleset structure.

Any idea ?

On Thu, Jul 19, 2012 at 12:18 PM, rm4dillo D <rm4dillo@gmail.com> wrote:
Thanks! This is a good idea but I still think that it's not that clean specially when the documentation says :

"You could also do the same by using the ctl action. This is useful if you want to only update the targets for a particular URL"

SecRule REQUEST_FILENAME "@streq /path/to/file.php" "phase:1,t:none,nolog,pass,ctl:ruleUpdateTargetById=958895;!ARGS:email"

By the way, I also tried to use the Location directive and it worked with SecRuleRemoveById but not with SecRuleUpdateTargetById.

Are you planning to make ctl:ruleUpdateTargetById use an exception_rule like structure instead of modifying the ruleset?

On Thu, Jul 19, 2012 at 6:52 PM, Breno Silva <breno.silva@gmail.com> wrote:
> Maybe you could add two ctl:ruleUpdateTargetById ?
> #Add it for each transaction
> SecRule REQUEST_FILENAME "[a-zA-Z0-0]" "t:none,nolog,pass,ctl:ruleUpdateTargetById=973331;ARGS:id"
> #Remove it during a specific transaction
> SecRule REQUEST_FILENAME "@streq /not_vulnerable.cgi" "t:none,nolog,pass,ctl:ruleUpdateTargetById=973331;!ARGS:id"
> On Thu, Jul 19, 2012 at 11:44 AM, Breno Silva <breno.silva@gmail.com> wrote:
>> Hello,
>> Yes. This is how SecUpdateTargetById works, changing the rule structure that is created using a different memory pool that the one per-transaction.
>> On Thu, Jul 19, 2012 at 11:21 AM, rm4dillo D <rm4dillo@gmail.com> wrote:
>>> Hi,
>>> I've been trying to implement some exceptions using conditional targets appending with the "ruleUpdateTargetById" action but after the first match, the exception is applied to all the following requests, just like the "SecRuleUpdateTargetById" directive.
>>> Example:
>>> With this configuration:
>>> SecRule REQUEST_FILENAME "@streq /not_vulnerable.cgi" "t:none,nolog,pass,ctl:ruleUpdateTargetById=973331;!ARGS:id"
>>> As expected, "GET /vulnerable.cgi?id=<script>..." matches rule 973331
>>> and "GET /not_vulnerable.cgi?id=<script>..." does not match rule 973331
>>> but when we try this "GET /vulnerable.cgi?id=<script>..." again, the request does not match rule 973331 because it's target list has changed.
>>> I think that this happens because the "ruleUpdateTargetById" directly modifies the current process' "msre_ruleset" structure while the "ruleRemoveById" action which works correctly creates a "rule_exception" structure for the current request only without modify the ruleset.
>>> P.S.: it's easier to reproduce this "bug?" by settings MaxClients to 1. This should force Apache to have only one process.
>>> Thank you for your help.
>>> Rm4dillo
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> mod-security-users mailing list
>>> mod-security-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>>> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
>>> http://www.modsecurity.org/projects/commercial/rules/
>>> http://www.modsecurity.org/projects/commercial/support/