weizman/shield

Window property clobbering via iframes

terjanq opened this issue · 6 comments

<iframe srcdoc="<script>window.name='config'</script><a href=cid:hey id='src'>"></iframe>

clobbers config.src

image

In Chrome and Firefox, it works by having an iframe to a cross-origin page and then redirecting back.

x = document.createElement('iframe');
x.src = 'https://terjanq.me/xss.php?js=window.name="vvv";location="https://weizmangal.com/shield/";'
document.body.appendChild(x);

image

I think I can address this, hope I'll find the time. Thanks!

Thinking about it, surprisingly, this might be out of scope @terjanq.

Because in order to introduce name clobbering in such a way (where it happens dynamically rather than by static attributes), you must run js code.

Dom clobbering attacks are interesting because they grant you power within scenarios in which you can't run code, otherwise, the clobbering part wouldn't have been interesting - the code execution ability would have.

Or to put differently, if you can introduce code, you might as well can do:

'''Javascript

<script>window.someObject = document.createElement("a"):</script>

'''

Just another way to clobber the dom given you can use JS for it.

But dom clobbering isn't about running js, it's about changing the state of the app in your favor by leveraging input you control that cannot turn into executable js code.

In other words, those who managed to inject such an iframe#srcdoc as demonstrated above never showed how it granted them clobbering ability, because it doesn't matter when you just found xss.

Given I correctly see the picture (correct me if I'm wrong) - shield actually does its job well if this vector remains out of scope.

Thoughts?

Edit: note to self - add csp that blocks strings turning into code in the demo if it ends up really being out of scope (still allow strings to turn into html though)

Think that's a fair statement, closing for now

It is code execution but in a cross-origin context.

#2 (comment) shows how an iframe can clobber a property to a truthy value.

<iframe src='https://terjanq.me/xss.php?js=window.name="vvv";location="https://weizmangal.com/shield/";'></iframe>

Yes, but then it's a question of whether having XO code execution overshadows DOM Clobbering narrative so that you have a far bigger problem than DOMC, or on the other hand, it's code execution that that allows you to manipulate the protected origin, so it is an escalation..

I guess it can lead to an escalation, so that's fair.

But given how there's not much I can do about it, plus it's fair to expect a web app to CSP control its frame-src, I feel ok letting this be.

Unless you can think of a clever way to approach this?