False positives

[Martin Hinks]

Hi all,

I decided that the other thread was becoming too massive to include
false positives as well and so am starting this thread!

To get the ball rolling:

An interesting problem with the rule that "finds attribute breaking
injections including obfuscated attributes":

This rule will be triggered by:

x = true;
y = false;

but not by:

x = true;y = false;

M

[thornmaker]

Good idea Martin. Also, I don't know how much trouble it would be,
but it would be nice if the rules were numbered... that would make it
a lot easier to discuss them, no?

[Mario Heiderich]

<fixed>

x = true;
y = false;

x = true;y = false;

</fixed>

Thanks!

[thornmaker]

# ([':;,])?\s*[)}\]](?(1)).+[=;:{[]
# finds closing JavaScript breaker including whitespace attacks

I have a few things to mention about this filter in the hope of making
it better. (please pardon me if I am misunderstanding anything here)

1) the first part doesn't add anything to the regex really. Having
optional matching parts at the beginning or end of the regex are
useless because they are not ever needed to make a match. In
particular, the ([':;,])? part is optional so it can be done a way
with. Same for the following \s* . In other words, String X will
match this filter if and only if it matches [)}\]](?(1)).+[=;:{[] .

2) the (?(1)) looks like the conditional notation you (.mario) were
telling me about. if so, is this doing what you intended it to do? I
see that you are using the conditional notation in other patterns now,
so what's going on here?

3) assuming 1 and 2 are correct, then this pattern boils down to [)}
\]].+[=;:{[] which would seem to trigger a lot of false positives.

I'm not for sure what specific attacks this filter was originally
created for, so I don't want to speculate on how I would improve it.

On Sep 18, 2:57 pm, Mario Heiderich <Mario.Heider...@googlemail.com>
wrote:

[Mario Heiderich]

Hi David!

Nope - assumption 1) is not exactly correct - although the rule has flaws indeed. The plan was to catch optional quotes and delimiters in a group, then the parenthesis and then a check if the first group has matched. If not there would have been other characters required to make the string a possible JS breaker. Anyway the last part of the rule is faulty and after reading your mail I think we don't need a conditional regex in this place.

The filter was originally created to detect JS breaking attempts - like ");alert(1) or ']; - it was one of the very first rules and it's questionable if we still need it at all.

What do you think of this approach - or should we better take that out for reducing false alerts sake?
(?:"?[)\]}][^;:,=]*[;:,=])

Greetings,
.mario

"Having optional matching parts at the beginning or end of the regex are
useless because they are not ever needed to make a match."

That's of course right but not in this case. The regex is working like this:
If there's a quote at the beginning

2007/9/22, thornmaker < thorn...@gmail.com>: