fix(934190): update regex assembly #4210
Conversation
|
📊 Quantitative test results for language: |
There was a problem hiding this comment.
Asking this question in a general sense: does this rule make sense?
How would a WAF detect a LaTeX injection attack? Specifically, in the context of HTTP, how would a CRS rule detect an injection attack inside of a LaTeX document file? We don't inspect file contents by default.
This sounds like it would be suitable as an anti-virus feature.
This is interesting work, I just don't see the application in the context of a WAF inspecting HTTP traffic.
If I'm missing an obvious use case here please do let me know.
|
@RedXanadu You're right, this rule needs to be modified to include only matches for specific LaTeX commands which can be considered dangerous, as suggested in the original PR where this feature was introduced. Any further suggestions are welcome. In case you missed the original PR, here is the reference link: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/LaTeX%20Injection |
|
The idea is that the code can be added to a latex file. E.g. there are web latex editors that could be targeted, when saving the file in a remote server. |
Co-authored-by: Max Leske <250711+theseion@users.noreply.github.com>
for more information, see https://pre-commit.ci
|
Since we are detecting payloads starting with a backslash( |
|
@fzipi @Xhoenix Thanks for the context. If we are targetting specifically web-based LaTeX compilers… that is such a tiny number of users, I don't think we can justify having this on by default for all CRS users at PL 1. It's similar to the discussion in #4208 over 'Edge Side Inclusion' rules. If it is only relevant to a tiny section of users, do we want this on by default. On the other hand, if I am one of those rare users who is hosting some interactive web LaTeX then I would want this rule enabled and probably at PL 1 or 2, so the easy solution of "let's just put this rule at a high PL" isn't necessarily a great idea. This seems like a problem that will be easier to solve when 'compiling the rule set' becomes a reality. I think this at least needs a wider group discussion. |
|
We could make this a plugin 🤔 ? |
|
A plugin could be a solution. The problem is making sure that someone who would benefit from this new LaTeX rule knows that it exists as a plugin. The good thing about having it in base CRS is that the rule is already there… But then, back to the problem of 'should this be enabled & executed by default when 99.9% of users won't benefit'. I think probably no? Unless it can go into PL 3 as a more exotic attack target? I've added this topic to the next agenda, maybe someone else has some better ideas or new arguments to suggest. |
|
I just found out that this rule also covers this bypass to some extent. Since that's a "Complete RCE Ruleset" bypass, we can modify this rule to cover that too? |
I wouldn't do that. While the syntax is similar, the targets are different and I wouldn't want to mix them. |
|
As discussed in the chat, we will remove the LaTex detection rule. Hence, I'll close this PR. |
Since LaTeX injection payloads start with a backslash, a forward slash could cause False Positives.