@Sohom Datta: This is not a full review, but I have some comments for things that I think need to be addressed:

• in the Vulnerability section, there is no explanation of how this attack works. It does describe how it is set up, by inserting HTML with the same name as a variable. But it is entirely unexplained how one might inject the HTML to do this, nor how this assignment might be used.
• the Threat model section states that it "depends on the attacker being able to inject potentially benign HTML into a website", but again, fails to mention how this might happen. It also says it is similar to another attack, but the description of that appears to be "getting user to click on an URL", and I'm not sure exactly how this paper is directly related to this topic.
• I would suggest that History be the first sub-section, as it introduces a number of terms and gives some specific examples.

Maury Markowitz (talk) 17:07, 4 December 2023 (UTC)[reply]

@Maury Markowitz I have tried to address your concerns

• I've added some context as to how this attack uses the assignment of the variable to influence code execution.
• I've added a example section to give a small example of how the attack might look like
• I've updated the threat model to explain how a attack could inject markup into the page, I don't think it is compared to another attack, we just say that the 'threat model' being considered for this attack is similar to that which would be expected in a classical 'web attacker threat model'
• The paper (Towards a Formal Foundation of Web Security) was one of the first papers to formally define what a 'web attacker threat model' actually is. (which is why it is cited right after the discussion regarding the model). The JSAgents/DOMPurify paper references the model, but does not delve into what it actually is (AFAIR)
• I've moved the History section to the top.

Let me know if you have any other concerns. Sohom (talk) 19:37, 4 December 2023 (UTC)[reply]

@Maury Markowitz (Friendly re-ping) Let me know if there are any other things that I should address :)

Also, just a heads up, I might have some reduced availiability next week for personal reasons :) Sohom (talk) 19:31, 6 December 2023 (UTC)[reply]

@Sohom Datta: Excellent update, my issues have been resolved! Maury Markowitz (talk) 17:33, 18 December 2023 (UTC)[reply]

This review is transcluded from Talk:DOM clobbering/GA1. The edit link for this section can be used to add comments to the review.

Reviewer: Elli (talk · contribs) 21:18, 19 February 2024 (UTC)[reply]

Claiming this review. Will go through the article in the next few days. Elli (talk | contribs) 21:18, 19 February 2024 (UTC)[reply]

@Elli are you going to work on this? RoySmith (talk) 16:57, 4 March 2024 (UTC)[reply]

Sorry, just been caught up with a lot of stuff the past few weeks and haven't gotten the chance to sit down for an in-depth review. I am still planning to do this soon. Elli (talk | contribs) 17:31, 4 March 2024 (UTC)[reply]

History[edit]

• In 2015, Heiderich et al. proposed a design for a library called JSAgents, (later DOMPurify) that would be effective at sanitizing markup injection attacks such as those related to cross-site scripting and DOM clobbering. do you have secondary sources for this?

I've added another source :)

• Third paragraph relies mainly on primary sources and a corporate blog post; is there anything better that could be used here?

The blog post is a guest post by Gareth Heyes, who is a subject matter expert and PortSwigger is a fairly well-known (in the field) web-security-research-oriented company that regularly features posts from experts on their blog. I personally would consider that source to be fairly reliable.

I'll try to see if I can get any reporting on the rest, however, this might be a bit difficult since such proposals rarely make it into traditional RS

• In general, this section might belong below the "Vulnerability" section? The content here (especially in the first paragraph) doesn't make a lot of sense if you don't understand what the vulnerability is.

Done :)

@Sohom Datta: I am very sorry for the delay in starting this review. I'll get to the other sections soon. Elli (talk | contribs) 19:16, 4 March 2024 (UTC)[reply]

No issues, feel free to take your time :) Sohom (talk) 15:12, 5 March 2024 (UTC)[reply]

Vulnerability[edit]

• Looks good, though could you point out the particular pages of "Code-Reuse Attacks for the Web: Breaking Cross-Site Scripting Mitigations via Script Gadgets" that verify the relevant content?

 Done

Example[edit]

• Specifying the page here would also be good.

 Done

Threat model[edit]

• The threat model for a DOM clobbering attack is similar to that of the web attacker model proposed by Akhawe et al. in 2010. that model hasn't been explained and isn't linked here.

The next sentence goes into the highlights of the model that are relevant to the article. Describing the whole model wouldn't be relevant to the page and I don't think we have a article for this specific model. (Hopefully once we have better coverage of this subject area, we should be able to tease out a article for it)

Defenses[edit]

• While the optimal defence against DOM clobbering would be to turn off access to named DOM elements, this is currently not feasible due to the significant active usage of these features as per Chrome telemetry data in 2021. not sure that a comment on GitHub is sufficient to establish this.

Added cite

• Maybe expand this section a bit more in general? Proper sanitation would completely mitigate this, right? (Even if no libraries exist to do so.) snyk at least indicates that using proper scoping can help and is an easy mitigation; that probably should be mentioned.

Snyk is being a bit optimistic here. However, there does seem to be some scope for expansion.

Lead[edit]

• This can lead to a skilled attacker being able to perform a variety of unwanted behaviours I'd change the wording here to be a bit clearer, such as This enables a skilled attacker to perform a variety of unwanted behaviours -- more concise.

 Done

• recent efforts to mitigate it completely have been unsuccessful due to a significant amount of usage of the underlying features across the web as of 2021 again I'd want a better cite in the body for this than a comment on GitHub.

Ditto

Overall[edit]

• This article is in pretty decent shape. Would suggest adding more specific pagenumbers to the sources (such as with ((rp)) or similar) to make verification easier. (If you do not want to do that, I would appreciate you providing the locations to me at least for easier verification.)

 Done

@Sohom Datta: I've finished the initial review. I am so sorry for the long delay in getting to all of this. Elli (talk | contribs) 20:04, 9 March 2024 (UTC)[reply]