jiebi/CodeConvo huggingface dataset:
Victim then visits URL, which executes The request to URL is cross-site, so it does not attach cookies URL performs a navigation to the value of the URL parameter through This triggers a request to URL, which attaches cookies, allowing an attacker to make authenticated requests from a cross-site position A similar scenario was discussed in this . Besides JavaScript redirections, other requests, such as subresource loads, could also be exploited to subvert the security assumptions granted by cookies. cookies effectively defend against certain classes of XS-Leaks attacks. However, -based attacks are still possible since cookies are attached to top-level cross-site requests. Since cookies are not attached to top-level cross-site requests, they have been deemed an effective mitigation against -based XS-Leaks. As discussed in 2.1, gadgets that allow attackers to forge same-site requests from a cross-site position can be leveraged for XS-Leaks. An example would be a page that performs a stateful subresource load, which modifies the page DOM. If an attacker opens this page through , cookies will not be attached, but following subresource loads in the new page will attach these cookies, leading to state-dependent changes to the DOM, which could be measured by the attacker (through frame counting for example). Best regards
Thanks for your well researched issue! I’ll try and address some of the points you brought up. First and foremost, SameSite is meant as only one layer in a defense in depth strategy, its design and implementation tries to balance our security and privacy goals with the realities of the web as it exists today. This ultimately means that it must be used with smart site design that leverages the other security tools and features available. differs from the original site (let’s call it a.example) navigating itself by allowing a.example to continue to hold and manipulate a reference to the new window. But, every navigation a.example makes on that reference will have an initiator of a.example (On Chrome at least, I haven’t checked other browsers, but I believe it’s true for all). This means that, as far as SameSite is concerned, an a.example window navigating itself directly or opening a new window and navigating that instead are all the same type of top-level navigation. This appears to hold true for all the examples and notes in your post. This was a purposeful decision.
We wanted to allow the site to be able to operate specific “landing pages” in order to allow third-party entities (maybe a sign in flow or payment processor) to navigate the user back and then the landing page could refresh to allow access to cookies in order to complete the process. Since the reload must be explicitly initiated by the page it would require the site developer to “opt-in” to the behavior and hopefully design the landing page with that behavior in mind. Conversely, we disallowed user initiated reloads because that doesn’t show an intention on the site’s behalf that it wants or needs cookies following that cross-site navigation. Users have been taught over the years to try reloading if a page looks broken, something that could occur if cookies aren’t present. Continuing to block cookies helps prevent users from inadvertently weakening their own security. That’s expected and intended. Samesite operates on a per request basis (or on a per JS call basis) so all requests, sub-resource or otherwise, are subject to the same rules. See . The spec assumes that since the page loading the same-site resources is in control of what it loads, it shouldn’t load anything that makes harmful changes. You’re correct that if a site exposes an API like you’ve given in 2.1 then it’s possible to give an attacker control + access to SameSite cookies. But to me it appears that the gadget is the footgun and I’m not sure how/if SameSite should solve this. Allowing any cross-site entity to make requests as yourself is a dangerous tool! I mentioned above that pages are in control of what they load and as long as they only load safe resources that they’re expecting they should be fine, but if you have any examples to the contrary I’m very interested in hearing about them. Going back to how s are basically the same as any other top-level navigation, this is the intended behavior. Lax cookies shouldn’t be used for anything that can allow changes to anything important. Agreed, it’s definitely possible to leak state this way. I’m not familiar with the reasoning with why the single-origin policy allows references to read , but I’m sure the spec writers had a good reason. Hope that helped clear things up, let me know if you have any other questions or concerns.
Hi NAME thanks (as usual) for the kind and thorough response!
I did a bit of additional investigation and found some discussions that we missed before opening the issue: URL and URL As far as I understood, the current behavior concerning page reloads has been defined only recently (2021). Before that, different browser vendors had . Even nowadays, browsers do not seem to fully agree on the intended behavior, or at least Firefox is inconsistent with Chrome's behavior since it does not attach SameSite=strict cookies after a call to . Some confusion on this matter is justifiable. :) I now see the rationale behind the design that enables specific pages to opt-in to SameSite=strict cookies upon a self-initiated reload. I always thought SameSite=lax cookies ensured compatibility with SSOs and payment flows, as lax cookies are attached to top-level navigations. But this "strict + reload hack" (so to say) puts the webpage in control instead of attaching cookies to all cross-site top-level requests. The downside of this behavior, as discussed, is that JS-based open redirectors become a gadget for bypassing SameSite=strict cookies. I'm not sure if the benefits outweigh the risks, but probably, the spec would benefit from a more explicit discussion of this trade-off. Concerning subresource loading, I would argue that in general this is not a valid assumption. In principle, here we have an untrusted context (the cross-site page opened via ) that automatically loads authenticated resources. This is somehow the dual of SRI, CSP, mixed content, and other security mechanisms that prevent a trusted context from loading untrusted resources that an attacker could abuse. We have not measured the prevalence of security issues caused by this behavior in the wild (i.e., xs-leaks introduced by an authenticated subresource being loaded), but I would expect a non-negligible number of affected instances. The current behavior surprised me, and it is possible that developers who care about protecting from xs-leaks are also unaware of the potential risks. For instance, the states that: citing only other reasons (e.g., the 2 minutes exception rule) as major limitations of SameSite cookies. To conclude, we just wanted to discuss this issue after encountering a behavior that diverges from our mental model of SameSite cookies and that we could not entirely justify it after reading the spec.
As for JS-initiated reloads, if the behavior is here to stay, I think the spec could mention these limitations more explicitly to prevent developers from building their applications based on wrong assumptions. Thanks again for the discussion! Marco
Hi NAME As you found in those discussions, reload behavior wasn’t well aligned previously and I’m not sure how purposeful each UA’s behavior was at the time. I know Firefox has a number of SameSite related behaviors behind default disabled configs, this could be as well. I don’t have easy access to Firefox at the moment but I believe the nightly builds have these flags enabled. What happens if you try testing on a nightly build? SameSite=Lax is useful for flows that use top-level navigation, but if a flow is happening in an iframe then SameSite=Lax cookies would be blocked. The reload technique enables these iframe based flows to function. The issue here is that a page may still load sub-resources that require SameSite=Strict auth cookies even if the initial request didn’t include those auth cookies? Plainly, any site that allows unauthenticated access to a page which loads authenticated sub-resources is incorrectly using SameSite. Sites should return a 401 error, or some other denial, if the initial request does not include the appropriate cookies. Sadly though, I agree with you that there are probably sites that do not. Just to confirm, the behavior you’re talking about are: URL navigations are not as restrictive as iframe navigations. Non-user controlled reloads allow cookies Sub-resource requests send SameSite cookies Redirect gadgets allow access to SameSite cookies Did I miss any? What do you mean by “these limitations”? Are you referring to the redirect gadget?
Any remaining comments/concerns before I close?
Hi NAME Sorry, I missed your earlier reply in October, and I'm just now seeing it. Thanks for the ping. I tried Firefox 123.0.1 (stable) and Firefox 125.0a1 (nightly), and they behave the same way. SameSite cookies are not attached to requests initiated via , but they are attached to requests caused by . Chrome sends the cookie in both cases. Indeed. While open redirectors and script gadgets are known to carry their problems, I am concerned about issues enabled by authenticated subresource requests, as they are less known to web developers. I don't think so.
NAME I'm just going to land this (as it's trivial), and roll an -05 today.
This should use a named section reference, no? Otherwise it can break again when section numbers change.
In URL under sub heading # 1 there is a paragraph, "Attackers can still pop up new windows or trigger...", which references section 2.1 for more information on that topic. However section 2.1 is "Conformance Criteria" so that doesn't seem the intended target.
Thanks!
The intent here is to say that your requirements for trusting a secondary certificate should be at least as strict as for trusting additional names in the primary certificate.
Add text noting the DNS check / not-check guidance in RFCs 7540 and 8336, respectively. Explicitly side-step the issue by saying that if you would do a DNS lookup for a hostname in the primary cert, you MUST do the DNS check for a hostname in a secondary cert as well; if you would omit the DNS lookup for a hostname in the primary cert, you MAY omit the DNS check for a hostname in the secondary cert as well.
I would argue that in CT Auditors are checking more than Signed Certificate Timestamps
NAME there is a lot of detail there and I am not sure how far you/others want to go, but I decided to keep it simple and I propose adding slightly more detail in URL I am sure you and others will let me know if that is too little (I doubt/hope it is not too much.)
NAME thanks for the issue. Did you have an intent for what to scope? Reading the , it implies a unique focus on x.509, rather than x.509 is one example of identity types that are supported. Considering CT in terms of SCITT: I'd suggest we limit the focus on x.509, and focus on the generalization that an issuer signs the protected header, which includes producing a timestamped signed statement and a timestamped receipt.
LGTM
This updates the concurrent streams in the XML and updates the HTML too (which picked up some other changes).
"For implementors it is recommended that this value be no smaller than 100" - what is the significance of "for implementers" here? I'm concerned this language is ambiguous enough to cause trouble. E.g., some may read it as pure advice; others might take away that values smaller than 100 can be assumed to be 100. Best way to specify is with MUST/SHOULD/MAY, identifying who it applies to (sender / recipient), and ideally specifying what should happen on both ends of the wire (when generating and receiving).
I agree this is ambiguous. I snuck in a short explanation there. I feel like we should take this back to the working group mailing list. I propose we either commit as is, as my extra explanatory clause is innocuous, and open an issue to resolve the ambiguity. Or I can withdraw this pull request for now, go back to the mailing list, and proceed with the flow control pull request first.
I'm happy to merge now and note an issue; just trying to minimise the number of such edits we cause with each change, as they have a tendency to stack up.
Since they're on different streams, an object can arrive before its SUBSCRIBEOK. This is easy to process because the Subscribe ID and Track Alias must have been the ones that the subscriber chose. What if the publisher then sends a SUBSCRIBEERROR? Is this valid behavior or an error? (If it weren't for the Expires field, SUBSCRIBE_OK would be entirely redundant and we could get rid of it.)
Individual Comment: This is covered a bit in and Luke expressed a desire to document the full state machine in . My read is that you can't send objects before SUBSCRIBE OK (but they can arrive out of order). I don't think you can send SUBSCRIBEERROR after SUBSCRIBEOK (objects or no objects), instead, use SUBSCRIBE_RST?
I agree that SUBSCRIBEERROR cannot follow SUBSCRIBEOK. I think you're saying that if Objects are in flight, then SUBSCRIBEOK must be as well, so a SUBSCRIBEERROR would in itself be an error. That sounds reasonable to me.
We're clear that only one of SUBSCRIBEOK or SUBSCRIBEERROR can be sent: the subscription, via SUBSCRIBEOK ({{message-subscribe-ok}}) or the SUBSCRIBEERROR {{message-subscribe-error}} control message. The entity receiving the SUBSCRIBE MUST send only a single response to a given SUBSCRIBE of either SUBSCRIBEOK or SUBSCRIBEERROR. I wrote to clarify that you can't send objects and a SUBSCRIBE_ERROR.
Text looks good but it's going to clash with the array spec work URL
It's a small change, we can sort that out when merging either.
Now that is allowed at multiple locations in the JSON document, including recursively, I would expect Sec. 5.1.2 to define explicitly where the claim should appear. Once at the top of the document? Can it also appear alongside claims located deeper in the document? Also, please change the section heading from "hash function" to "hash algorithm", for consistency.
Thank you! The intention is that there is only one at the top level. We will clarify.
Concur with NAME
+1
Clarify the optionality of the cnf claim (to
please see issue and note that the text in this PR has "This [cnf] claim MUST be present when cryptographic Key Binding is to be supported." Also note this PR isn't for issue and it was probably a mistake on my part to have suggested text there that touches two issues. But they were both on cnf so I did what I did [no pun intended]. This PR only attempts to clarify the optionality of the cnf claim for issue . There doesn't yet seem to be consensus on .
URL
NAME you probably made the comment while I was updating my original comment based on re-reading the PR. I still think it should remain "required when cryptographic binding is used"
what does this mean? you believe sd-jwt-vc should have more than one way to do cryptographic holder binding? or that many of the credentials will not use cryptographic holder binding?
No, I just mean SD-JWT VCs can be key bound, but they don't need to be. Therefore it is an optional feature.
I see, the difference here is that if key binding shall be used, then cnf must be used while the other formulation leaves more space?
If that's the intent, sounds more appropriate to me. just saying would lead to confusion that it is optional even when cryptographic binding is used.
I also like the proposed version more. The proposed language addresses which is based on developer feedback that were confused by the current language that uses REQUIRED if ... . So I think that OPTIONAL seems to solve that issue. IMO, it is also appropriate since we have the additional requirement in the paragraph that says MUST be present if cryptographic binding is required.
Sorry, I don't understand why more space is needed here? The less optionality in key binding, more interop. with the current PR, it would be ok to use a top level sub claim and put a DID there (instead of using URL). I think it is harmful for the interop, that SD-JWT VC is hoped to bring
I don't see that this optionality is allowed by the following?
I see your point. The proposed text opens a door for key binding without using the cnf claim.
However, the new text is more initiative and we could add this constraint as an additional sentence or in the section on key binding
Okay, it is already present. Sorry I didn't recheck the changes. Lgtm then
I'm struggling to understand the disagreement/argument here. But I'm trying... The text for cnf in the PR has: which seems to me to clearly says that cnf is the required way to do key binding, if doing key binding. Especially the "This claim MUST be present when cryptographic Key Binding is to be supported" sentence. Would changing that sentence to "This claim is REQUIRED when cryptographic Key Binding is to be supported" help? Maybe I'm missing the point of contention but that and the current PR text and the current text in the draft all say the same thing - that cnf is the one and only way to do key binding in SD-JWT VC but b/c key binding isn't itself required, the claim also isn't required.
I thought that was better phrasing anyway so made the change w/ 9edae9d4aa1dc2b647c77029b7d415d384cded49
Seems great to me.
You're suggested pedantic wording is indeed better than what I'd had. Thanks. I've accepted it w/ c6b138036e035e6df2a2f983aa4cf8b183d39fc2
Not all VCs require key binding. For those, cnf should be made optional.
I've read the text in URL that says "REQUIRED when Cryptographic Key Binding is to be supported." as being optional or not required when key binding isn't needed. Perhaps we need to discuss and/or make things more clear?
Do you think we should also explain the OPTIONAL case or replace the REQUIRED with something else? CONDITIONAL is not a reserved word unfortunately.
I would propose to clarify this. From a quick reading this is not obviously optional and it does not match the other claims that only state REQUIRED/OPTIONAL without any conditions. As cryptographic binding is optional, I think this line should begin with "OPTIONAL. [...]"
URL attempts to do just that
thank you!lgtm, see my comment in the discussion.I like this version.
There is a bit of angst about using SUBSCRIBE to obtain the current Group ID. This PR is a straw man to provide an explicit means of obtaining the group ID. I would be surprised if this ended up in the final RFC, but it might be useful to keep in the draft as a primitive while the other SUBSCRIBE/FETCH stuff moves around.
Summary from meeting. We want to make it more extensible for other things. Scope to things the relay knows, not a substitute for Catalog. Rename to make it more generic.
What about returning latest object in addition to latest group?
OK, changes: I painted my bikeshed TRACKSTATUS, on the grounds that TRACKINFO sounds like more permanent data that maybe out to be in the Catalog. I added last Object ID because Will asked for it and it seemed easy enough. I did not fill Suhas's suggestion to make it optional because the parameterized idea got a lot of pushback in the call, and this seemed adjacent. Please have a look, and if Ian's happy with it he can merge.
I'll also note that we could put a track alias hint in here, but I didn't care enough to add it without more positive feedback.
This is a good start. We can massage the status codes later. They should correspond to some sort of state machine that we define for moqt in general. I'm sure we will have future changes to this, but I think we should merge it.
We accept that a strong suggestion to use round-robin isn't ideal. And look for other ways to phrase the suggestion of distributing or timeslicing. Fortunately we already had some text in the next paragraph that explained the ways that timing of delivery of incremental resources parts is important to clients and the sorts of things that servers need to consider. So this PR rearranges the text a bit and gives it dust off to make sure it is in line with our understanding now.
This recommendation is too strong. There is still value in allowing requests to complete. This suggests that pieces of all responses be provided concurrently. That leads to more context switching than necessary, or even inefficiencies in transmissions (one byte from each at a time would have excessive overheads). I would instead say:
I agree that "round-robin manner" is poorly defined and could be interpreted as 1 byte of everything. That would be bad. However, the full context of that SHOULD is in relation to the other requirements in that paragraph RECOMMENDing respect with no guidance on what that means seems a bit iffy to me. Your suggestion might get misinterpreted as relaxing the RECOMMEND. Rewriting that paragraph risks kicking the hornets nest of one the most divisive issues we had (URL). I sort of inclined to keep the SHOULD but expand on what we intended to say with "round-robin"
LGTM, some suggestions only.
Incorporating feedback based on
Follows . (CC NAME User Experience (extension) During potentially dangerous operations (e.g., reading the QR code on the Authorizing Device), advise users to verify the trustworthiness of the source, for instance by checking that the connection is protected through TLS or by verifying that the URL really belongs to the Authorization Server. In particular, when activating the camera to read the QR code on the Authorizing Device, the activity could also display a warning message advising users to only scan QR codes displayed on a specific website. Limitations: those already reported in the mitigation
After discussing with Daniel, this is very close to the recommendations on user education. We will review that addition and incorporate the recommendation to add warning messages when scanning a QR code, if it is not sufficiently clear already.
Clarify that the binding is not done through cryptographic means but rather through association by the authorization server since the binding is only between the client and the authorizations server. See issue cc NAME , NAME
Since RFC 9449 does not specify how "additional" parameters can be bound, please say explicitly that (presumably) this is a claim within the DPoP proof JWT named "auth_session".
It is not a new claim in the DPoP proof, because that would imply the binding happens from the client, not the AS. Brian's suggestion was to require the AS to do the binding, in which case it's internal and not part of the spec.
So can you please fine tune the language in 9.6.1. At least this reader understands the word "binding" when used in this context as cryptographic binding, and this is obviously not what you want. Maybe use "associate" instead.
Fixed by .