8000 Monthly Chat Agenda April 2023 (2023-04-03 and 2022-04-17) · Issue #3159 · coreruleset/coreruleset · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
RedXanadu opened this issue Mar 13, 2023 · 1 comment
Closed

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

RedXanadu opened this issue Mar 13, 2023 · 1 comment
Labels
🔖 Meeting Agenda

Comments

@RedXanadu
Copy link
Member
RedXanadu commented Mar 13, 2023 •
edited by airween
Loading

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

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

CRS Status Page

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

We merged 13 PRs since the last monthly project chat.

Open PRs

Open PRs marked DRAFT or work in progress or needs action

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)

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.
@azurit azurit mentioned this issue Mar 18, 2023
Merged
@franbuehler
Copy link
Contributor
franbuehler commented Apr 3, 2023 •
edited
Loading

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.

This was referenced Apr 5, 2023
Closed
Closed
@RedXanadu RedXanadu mentioned this issue Aug 14, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
🔖 Meeting Agenda
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@RedXanadu @franbuehler
0