-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
base: main
Are you sure you want to change the base?
Go: Add Rs Cors Support #14873
Conversation
/** | ||
* Provides abstract class for modeling the Go CORS handler model allow all origins write. | ||
*/ |
Check warning
Code scanning / CodeQL
Class QLDoc style. Warning
/** | ||
* Provides abstract class for modeling the Go CORS handler model allow credentials write. | ||
*/ |
Check warning
Code scanning / CodeQL
Class QLDoc style. Warning
There was a problem hiding this 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
.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
isa.b.c
thenthis
is theVariable a
and the thing that has typeOptions
isa.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 usingVariable
or just usingSsaWithFields
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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 SsaWithFields
and replace the root case with a read from a global variable. I guess GlobalWithFields
would be the obvious name.
Add RsCors support to CodeQL CorsMisconfiguration.ql