Skip to content
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

False positive: Insecure Direct Object Reference (cs/web/insecure-direct-object-reference) and Missing function level access control (cs/web/missing-function-level-access-control) #16327

Open
alensiljak opened this issue Apr 25, 2024 · 1 comment

Comments

@alensiljak
Copy link

alensiljak commented Apr 25, 2024

Description of the false positive

In a C# project, we have dozens of potential false positives for "Insecure Direct Object Reference (cs/web/insecure-direct-object-reference)" and "Missing function level access control (cs/web/missing-function-level-access-control)" due to the custom authorization that we use via an attribute. Please see the code example below.
What would you suggest as a mitigation in this situation?

Code samples or links to source code

[Function(Functions.Event.Add)]
public void PublicFunction() {
    Function1();
}

private void Function1() {
    Function2();
}

private void Function2(id) {
    // load object id <= Insecure Direct Object Reference (cs/web/insecure-direct-object-reference)
}

where the [Function] attribute takes the user's identity and looks if it is authorized for a specific system function. This checks for both authentication and authorization.

The "Missing function level access control (cs/web/missing-function-level-access-control)" is often reported directly on the function declaration:

[Function(Functions = new[] { Functions.Location.Edit })]
public async Task<IActionResult> Edit(string name)  // <= scanner reports insecure function
@joefarebrother
Copy link
Contributor

Thanks for the report. Unfortunately, it looks like this code is using a custom attribute-based system for authorization, which it is hard to see how the query could recognise using general rules. If you have a suggestion for a general heuristic that would take this into account, we could consider incorporating it — otherwise I’m afraid you will need to dismiss the false positives that result.

@sidshank sidshank added the C# label Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants