If anyone else is not already working on this can I pick this up?

It's all yours 👍

I researched about this and I don't think this will be possible in the already existing scan rule Anti-clickjacking Header, I think we can create another ascanrule called Universal Reverse ClickJacking or Same Origin Method Execution.

Here are the POCs for firing range:

1. In fragment in callback
2. In fragment in other param
3. In query in callback
4. In query in other param

Here's the approach:

1. Create an ascan rule which will check if the request is a javascript request.
2. If yes, then check if there is a parameter which is getting reflected and can be exploited for reverse clickjacking by manipulating function names or even creating entire functions.

Let me know if this sounds good or if anyone else has any ideas.
Thank you 😄

Sounds good to me.
Out of interest - how are you detecting the fragments like #q in order to attack them?

Sounds good to me. Out of interest - how are you detecting the fragments like #q in order to attack them?

No we won't be attacking that request, let me explain:

When you open this link we have a fragmented parameter #q, even if we attack that using an active scan we won't be able to identify the vulnerability since it is creating the <script> element with the JSONP endpoint as src using JS, for that we will have to parse the DOM. Instead of that I'm planning to attack the JSONP endpoint directly and check if there is a parameter which influences the function structure, in this case the JSON endpoint is https://public-firing-range.appspot.com/reverseclickjacking/jsonpendpoint?q=alert&callback=alert whose callback parameter can be modified to run limited JS.

Oh nice - look forward to your PR 😁