CWE-1004: Sensitive cookie without HttpOnly #529
Conversation
|
Does / will this have a corresponding bounty application? |
Yes, was planning if it is merged. Are there any differences? Does bounty application speeds up review? |
|
No particular speed difference but it affects who does the work. In this case you should apply before merging, and you'll get accuracy comments from the security lab team. |
|
Sorry, didn't know that. Just created it. |
| HttpOnlyCookieTrackingConfiguration httpOnlyCfg, AuthCookieNameConfiguration cookieNameCfg, | ||
| SetCookieSink sink, DataFlow::Node source | ||
| | | ||
| httpOnlyCfg.hasFlow(source, sink) and | ||
| cookieNameCfg.hasFlow(source, sink) and |
owen-mc
Apr 28, 2021
Contributor
I don't think you really want to use two taint tracking configurations here. You are only really interested in one path. You should combine them, and make the source be the conjunction of the two current source predicates. It might be clearest if you make the two current source predicates into their own separate predicates.
I don't think you really want to use two taint tracking configurations here. You are only really interested in one path. You should combine them, and make the source be the conjunction of the two current source predicates. It might be clearest if you make the two current source predicates into their own separate predicates.
|
No, you didn't do anything wrong. The first path is fine, though some steps are skipped that you might expect to see. The extra paths are a quirk of how to we track data flow. I think this was explained here. |
|
Great - it's so much easier to read with the comments! I understand a lot better what's going on now. I only had time to do a partial review. Most of my comments are about slightly better ways of doing things, e.g. using data flow nodes instead of exprs, but they will make things a lot more readable. |
| exists(NameToNetHttpCookieTrackingConfiguration cfg, DataFlow::Node nameArg | | ||
| cfg.hasFlow(_, nameArg) and | ||
| sink.asExpr() = nameArg.asExpr() | ||
| ) |
owen-mc
May 11, 2021
Contributor
I think this logic should move into the definition of SetCookieSink. You only really care about calls to SetCookie which have a sensitive name. This will restrict the number of sinks for two configurations, and for performance reasons it's always good to restrict the number of sources and sinks for configurations.
I think this logic should move into the definition of SetCookieSink. You only really care about calls to SetCookie which have a sensitive name. This will restrict the number of sinks for two configurations, and for performance reasons it's always good to restrict the number of sources and sinks for configurations.
owen-mc
May 14, 2021
Contributor
I still think this would be an improvement - make it part of the definition of SetCookieSink that a sensitive name flows to it (and maybe change its name to reflect that). This would improve performance and wouldn't change the results at all.
I still think this would be an improvement - make it part of the definition of SetCookieSink that a sensitive name flows to it (and maybe change its name to reflect that). This would improve performance and wouldn't change the results at all.
|
Oh, and I forgot to mention that you need to regenerate the |
|
Looking good. A few more comments. Also, I should say that this advice about staying at the level of |
|
Oh, and my unresolved comment about changing the definition of |
Do you mean this one? The sink predicate becomes odd, otherwise it is non monotonic recursion... |
|
Hmm, it seems that comment doesn't make sense any more. Oh well. |


No description provided.