8000 Add exclusion set for OData standard · Issue #2127 · coreruleset/coreruleset · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add exclusion set for OData standard #2127

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.

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

Open
fzipi opened this issue Jun 11, 2021 · 17 comments
Open

Add exclusion set for OData standard #2127

fzipi opened this issue Jun 11, 2021 · 17 comments
Assignees
Labels

Comments

@fzipi
Copy link
Member
fzipi commented Jun 11, 2021

Motivation

OData (Open Data Protocol) is an ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming RESTful APIs. Its usage of common wording, similar to SQL is probably going to be something to consider in next versions.

This is a proposal to add some exclusion set that allows our users to use OData in a controlled environment.

Proposed solution

Create a new exclusion ruleset that enables users to start rolling OData.

Additional context

This was originally detected in issue #2123.

@dune73
Copy link
Member
dune73 commented Jun 23, 2021

We talked about this issue at our recent project meeting.

Decision: @theseion takes this on and @fzipi promises to coach him.

@theseion
Copy link
Contributor
theseion commented Jun 23, 2021

I read through some of the OData documentation. From what I understand we will have to come up with an exclusion package that disables all those rules (mainly SQLi and RCE I suppose) that trigger false positives. For that we will need a comprehensive suite of tests that can generate the FP's. Is that what you had in mind?

I guess we can start by focusing on the specification and create tests that run through the different types of queries with a bunch of different parameters. This approach is of course quite limited, because the queries can become extremely complex. But I think it's valid start. A possible second step could be to write a test data generator, that basically takes the spec as input and produces valid random queries with varying complexity. That might be too much effort though (but it sounds cool :)).

BTW, if we're doing this for OData, should we also do it for things like JsonAPI or GraphQL? Others?

@fzipi
Copy link
Member Author
fzipi commented Jun 23, 2021

GraphQL and others are coming, for sure.

We can use the OData test service in https://services.odata.org/ and see what we get. Probably proxying it with modsec will give us an initial subset.

From RCE, we only had one particular match, but taking a look there won't hurt.

@fzipi
Copy link
Member Author
fzipi commented Jun 23, 2021

Looks like also https://pragmatiqa.com/xodata/ is using that site for tests.

@dune73
Copy link
Member
dune73 commented Jun 23, 2021

@theseion : We are usually not as systematic as you propose. It's more of an empiric approach. Like putting CRS in front of an installation and logging the FPs, doing the REs and then repeat until no more FPs.

Ideally it's a group of people that use a software and we kind of wished the communities behind these softwares would join / support us with coming up with RE packages, but that never happend.

@dune73
Copy link
Member
dune73 commented Jul 19, 2021

Any update here, @theseion?

@theseion
Copy link
Contributor

No, I haven't worked on this yet.

@dune73
Copy link
Member
dune73 commented Nov 15, 2021

Any interest to keep this on, or do we search a new volunteer? Orignally @fzipi had an interest in this.

@theseion
Copy link
Contributor

If someone else volunteered that would be great.

@dune73
Copy link
Member
dune73 commented Nov 15, 2021

OK. Adding this to the agenda for tonight.

@dune73
Copy link
Member
dune73 commented Dec 20, 2021

For the record: We're waiting for a volunteer to provide a PR here

@github-actions
Copy link
Contributor

This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days

@github-actions github-actions bot added the ⌛ Stale issue This issue has been open 120 days with no activity. label Apr 20, 2022
@theseion theseion removed the ⌛ Stale issue This issue has been open 120 days with no activity. label Apr 20, 2022
@github-actions
Copy link
Contributor

This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days

@github-actions github-actions bot added the ⌛ Stale issue This issue has been open 120 days with no activity. label Aug 19, 2022
@azurit azurit removed the ⌛ Stale issue This issue has been open 120 days with no activity. label Aug 19, 2022
@github-actions
Copy link
Contributor

This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days

@azurit
Copy link
Member
azurit commented Apr 26, 2024

I can take this.

@fzipi Would it be sufficient to create a first version of RE plugin based on examples of communication from tutorials (here and here)?

@dune73
Copy link
Member
dune73 commented May 2, 2024

It's maybe worthwhile to touch on this in the Monday meeting as well. Feel free to add.

@fzipi
Copy link
Member Author
fzipi commented May 6, 2024

I can take this.

@fzipi Would it be sufficient to create a first version of RE plugin based on examples of communication from tutorials (here and here)?

Definitely yes, let's start with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants
0