Monthly Chat Agenda April 2023 (2023-04-03 and 2022-04-17)

[RedXanadu]

This is the Agenda for the two Monthly CRS Chats.

The general chat is going to happen on https://owasp.slack.com in the channel #coreruleset on Monday, 2023-04-03, at 20:30 CET. That's the 1st Monday of the month. A separate issue chat is happening at the same location, same time on Monday, 2022-04-17. That's the 3rd Monday of the month. Please note that we have a CRS calendar (maintained by @fzipi).

Archived previous meetings and their decision are here.

What happened in the meantime since the chat last month

Outside development

• ☀️ Google Summer of Code (GSoC): We provided the same projects we did last year for GSoC 2023, we still need to add the ones we decide to do at Varese 2022. ⏳
• Following the open letter to the OWASP board by several OWASP project leaders and two board members, new board member (and former OWASP co-founder) Mark Curphey left the board concluding the concerns and demands in the open letter were not addressed fast enough or in a systematic way. He shared ideas of launching a new organization, probably tighter and better funded one. CRS is observing the situation. (https://www.linkedin.com/pulse/yesterdays-owasp-board-directors-meeting-i-resigned-my-mark-curphey)

Inside development

Rules

• PR's for FP's agains sh and fi in argument names and values (thanks to @Xhoenix, @emphazer)

CRS Sandbox

• The integration of the Coraza Playground has not started yet, but is right on top of the tasklist.

CRS Bug Bounty and Security

• See below under documentation
• Currently 4 security items open. Mostly solved.

Plugins

• Impressive work by contributor https://github.com/Xhoenix and @azurit on the Nextcloud rule exclusions plugin

Documentation and Public Relations

• 📼 CRS Community Summit videos now on YouTube (with the audio sync fixed): https://www.youtube.com/@owaspmodsecuritycoreruleset
• 📝 Rewriting the INSTALL document continues but is very slow and very tedious work.
• Grand Bug Bounty Blog post is almost done; a 3rd party reviewer asked for a rewrite of a paragraph

Project Administration and Sponsor relationships

• There was a call with OWASP HQ to make accounting easier for us.
• Two sponsors indicated they are not sure they can continue with sponsoring us in 2023. But a new one is getting serious. We'll be fine, but it takes work.

Tools

• rules-check.py script checks the commented SecRule and SecAction entries in crs-setup.conf.example by #3161. Explicit initialization of the TX variable is no longer necessary if it exists in crs-setup.conf.example, with comments.
• go-ftw release 0.4.9 with improvments to overrides and cloud mode

Testing incl. Seaweed and many future plans

• No news in this front.

Containers

• 🔼 Updated Apache because of CVE-2023-25690 fix: update apache because of CVE-2023-25690 modsecurity-crs-docker#132

CRS Status Page

• 🧪 One new test added this month (feat: Add status page test for rule 921150 #3158).

Project discussions and decisions

• curl User-Agent problem.
  Due to the recent ‘Unix command’ rule changes, if you use curl to access something through CRS then you get an anomaly score of 10 (5 at PL 2 + 5 at PL 3, 932236 PL2 and 932237 PL3) due to "curl" being detected in the User-Agent string. This seems like a significant change: compare this to CRS 3.3.x which does not penalise the use of curl at all.
  Question: Do we need to fix this? If so, who needs to do what to fix it?
• Discuss C9K-230327.
  Qs: We are in agreement on our approach? Who will implement this?
  Please be careful what we say on public channels about this at the present time.
• Referer header headache.
  The Referer header was recently added to several rules to combat a series of bypasses. Unfortunately, some legitimate Referer headers now cause false positives with rule 932200 (issue: Rule 932200, now inspecting Referer headers, matches any query string that contains spaces #3180).
  Q: It has been suggested to simply remove Referer from this rule because it is difficult to fix otherwise: are we happy with this?
• Report of possible transformation bypass.
  It has been reported (Base64 Transform being at the end allows false negatives #3182) that having t:base64Decode at the end of a transformation pipeline may allow for certain bypasses.
  I think they might be suggesting that we need to perform an additional round of t:urlDecodeUni,t:jsDecode,t:removeWhitespace after the Base64 decoding step?
  Qs: Do we:
  • a.) fully understand the reported issue (any further details required?), and
  • b.) agree with the reported issue?
  • Do we need to change all of our current (and future) rules to move t:base64Decode away from the end of all transformation pipelines?

Rules development, key project numbers

PRs that have been merged since the last meeting

• fix: properly publish nightly release #3185
• fix(ci): update nightly release version #3171
• fix: apply non-draft state to nightly release forcefully #3179
• chore: add source documentation and sync restricted-files.data #3177
• fix(feat): strip comments during the parsing of crs-setup.conf.example #3161
• chore: fix typos #3175
• fix(typo): Typo fix #3176
• fix: php-errors FP #3155
• fix(FP): PostgreSQL error messages #3169
• chore: Update tests to match changes in go-ftw #3166
• docs: Rewrite issue templates for false positives and false negatives #3135
• fix(config): format crs-setup.conf.example #3157
• docs: update plugin documentation URL #3153

We merged 13 PRs since the last monthly project chat.

Open PRs

Open PRs marked DRAFT or work in progress or needs action

• fix: require word boundary for sh in RCE rules #3186
• fix: match word boundary after fi #3187
• fix: change order of base64decode in NODEJS Attack #3184
• feat(config): Adds enable_default_collections flag to do not initialize collections by default #3141
• feat(windows): update windows commands list #3170
• chore: add enlighting comments to 980170 tests #3167
• feat: Add status page test for rule 921150 #3158
• feat: Split Node-Validator keywords functionally #2637
• Negative lookarounds for rule 941310 to stop matching Japanese word Company. #2666
• Update REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example #2878
• Util to find English words on .data #3029

Open issues and PRs

• As of Monday, we have 103 open issues.
• As of Monday, we have 20 open pull requests.

Separate 2nd Meeting (Monday, 2022-04-17)

• PR Update REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example #2878
• PR feat: Split Node-Validator keywords functionally #2637
• PR fix 933180 regex #2303
• PR fix: 933161 regex #2302
• PR fix: 933160 regex #2301
• PR Exclusion list fot RoundCube webmail #2217
• PR fix: exclude well known user agents from unix commands #3190 - about comments syntax between parts of a chained rule

How to get to our slack and join the meeting?

If you are not yet on the OWASP Slack, here is your invite: https://owasp.org/slack/invite .

Everybody is welcome to join our community chat.

[franbuehler]

Decisions 2023-04-03

• curl User-Agent problem.
  Due to the recent ‘Unix command’ rule changes, if you use curl to access something through CRS then you get an anomaly score of 10 (5 at PL 2 + 5 at PL 3, 932236 PL2 and 932237 PL3) due to "curl" being detected in the User-Agent string. This seems like a significant change: compare this to CRS 3.3.x which does not penalise the use of curl at all.
  Question: Do we need to fix this? If so, who needs to do what to fix it?
  Decision: @theseion volunteers to try and fix this. Thank you!
• Discuss C9K-230327.
  Qs: We are in agreement on our approach? Who will implement this?
  Decision: We agree to write back to the reporter that we will sort this out on our end (via a new new rule to detect this).
  Please be careful what we say on public channels about this at the present time.
• Referer header headache.
  The Referer header was recently added to several rules to combat a series of bypasses. Unfortunately, some legitimate Referer headers now cause false positives with rule 932200 (issue: Rule 932200, now inspecting Referer headers, matches any query string that contains spaces #3180).
  Q: It has been suggested to simply remove Referer from this rule because it is difficult to fix otherwise: are we happy with this?
  Decision: Thanks to @RedXanadu's analysis, it looks like it might be possible to tweak the regex to get rid of many of the FP's atPL2. @theseion will look into this. If it's not possible, we'll move the Referer check to a PL3 rule.
• Report of possible transformation bypass.
  It has been reported (Base64 Transform being at the end allows false negatives #3182) that having t:base64Decode at the end of a transformation pipeline may allow for certain bypasses.
  I think they might be suggesting that we need to perform an additional round of t:urlDecodeUni,t:jsDecode,t:removeWhitespace after the Base64 decoding step?
  Qs: Do we:
  • a.) fully understand the reported issue (any further details required?), and
  • b.) agree with the reported issue?
  • Do we need to change all of our current (and future) rules to move t:base64Decode away from the end of all transformation pipelines?
    Decision: @RedXanadu and @theseion will continue to solve this. They'll do jsDecode twice. This will solve the problem here and we keep "Development of clear guidelines for transformation use and order" on the task list for after CRSv4.