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

Go: Add Rs Cors Support #14873

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Go: Add Rs Cors Support #14873

wants to merge 6 commits into from

Conversation

Kwstubbs
Copy link
Contributor

Add RsCors support to CodeQL CorsMisconfiguration.ql

go/ql/lib/semmle/go/frameworks/RsCors.qll Show resolved Hide resolved
Comment on lines +16 to +18
/**
* Provides abstract class for modeling the Go CORS handler model allow all origins write.
*/

Check warning

Code scanning / CodeQL

Class QLDoc style. Warning

The QLDoc for a class should start with 'A', 'An', or 'The'.
Comment on lines +25 to +27
/**
* Provides abstract class for modeling the Go CORS handler model allow credentials write.
*/

Check warning

Code scanning / CodeQL

Class QLDoc style. Warning

The QLDoc for a class should start with 'A', 'An', or 'The'.
Copy link
Contributor

@owen-mc owen-mc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The abstract classes should not be in RsCors.qll. I'd either put them in go/ql/lib/semmle/go/Concepts.qll or in a new file in go/ql/lib/semmle/go/concepts/ which you then import in go/ql/lib/semmle/go/Concepts.qll.

go/ql/lib/semmle/go/frameworks/RsCors.qll Show resolved Hide resolved
@owen-mc
Copy link
Contributor

owen-mc commented Nov 22, 2023

Actually, since these abstract classes are only used by this one query, they shouldn't go in concepts (which is more meant for abstract classes that are used by multiple queries, I think). And I also didn't notice that this query is still in experimental. That makes it difficult to know where to put them. Maybe where they are is good enough for now. Do you think the query should be promoted?

}

/**
* A variable of type Options that holds the headers to be set.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't actually correct: if v is a.b.c then this is the Variable a and the thing that has type Options is a.b.c. I didn't notice this when you originally modeled GinCors. Can I ask why you are doing it this way? Is there a particular case where just using Variable or just using SsaWithFields doesn't work?

Copy link
Contributor

@owen-mc owen-mc Nov 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at it more carefully, I see that, because of the way that they are modeled, RsOptions and GinConfig are confined to be local variables defined in functions. Is that what you intended? Might you ever want to reason about one that is defined at package scope?

Copy link
Contributor Author

@Kwstubbs Kwstubbs Mar 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@owen-mc

This isn't actually correct: if v is a.b.c then this is the Variable a and the thing that has type Options is a.b.c. I didn't notice this when you originally modeled GinCors. Can I ask why you are doing it this way? Is there a particular case where just using Variable or just using SsaWithFields doesn't work?

I can change this to just use SSAWithFields. I will ensure that the getBaseVariable() is removed. I see the problem with the current model is that since I am using SSAVariable, getSourceVariable's result is by definition a local variable. I would like to support package variables as well. I have tried to remove SSAs all together and just use Node, but cannot find a way for two nodes to know if they actually represent the same variable. If you can think of any way to do this that would be great.

var opts cors.Options                            <----- the package opts variables 

func rs_vulnerable() {
	opts.AllowedMethods = []string{"POST"}
	opts.AllowedOrigins = []string{"null"} <--- how to compare Node corresponding to this opts 
	opts.AllowCredentials = true              <---- to  Node corresponding to this opts and see that they both correspond to the package level opts

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I wasn't clearer about why the way they are modeled means they have to be local variables. Well done for figuring it out - coming back to this after four months, it took me a few minutes, even with your explanation.

I would say that SSAWithFields works great as long as you don't mind missing out writes to global variables. You may decide that in practice, that pattern doesn't come up and you're okay with not spotting it.

When dealing with just nodes, I think the normal way to think about them "representing the same variable" is whether there is value/taint flow from one to another.

There is an approach to this kind of thing in go/ql/src/experimental/CWE-1004/AuthCookie.qll, but I'm not sure it's necessarily one that I'd recommend.

I'll ask the rest of the codeql-go team if they can think of a better way of doing it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@owen-mc let me know if you have any updates on this :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sorry I didn't get back to you. The best way to include global variables is to copy this code which defines SsaWithFieldsand replace the root case with a read from a global variable. I guess GlobalWithFields would be the obvious name.

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

Successfully merging this pull request may close these issues.

2 participants