I tried to mount a client-side "attack" on a news website poll by using only Javascript. And I failed miserably.

ispoljari

Ivan Spoljaric

Posted on July 14, 2021

I tried to mount a client-side "attack" on a news website poll by using only Javascript. And I failed miserably.

Alt Text

First step - Running the script locally

For academic purposes I tried to create a client-side script to manipulate the results of a random poll on a Croatian news portal

The poll is open at the moment writing, but it probably won't stay that way for long.

Here's the code

The code consists of these steps:

  • waiting for "DOMContentLoaded" event

  • closing the cookie banner

  • selecting a poll answer

  • MutationObserver indicates changes in the DOMTree target iframe. This means that the results are "in". Then the localStorage is cleared.

  • a timer, which started running immediately after "DOMContentLoaded", reloads the page after 2 seconds. And the script starts from the beginning

It works as intended if you run it directly in the dev tools console.

You'll probably notice how the code is tightly coupled with the html/css implementation of the web page.

Since I was creating a proof of concept I didn't bother to write the functions in a generalised way.

I used the exact CSS class names from the site, and targeted the poll iframe based on its position in the HTML.

I had a pretty strong hunch that it won't work anyway (not that it stopped me from trying).

Second step - Automating the script

The next step was to think of a way to run the script automatically, without the need to paste the code in the console every time.

So, I created a custom browser extension, which has only one additional manifest.json file.

And that didn't work.

Line 2 is the problem.

  document.getElementsByTagName('iframe')[3].contentDocument;
Enter fullscreen mode Exit fullscreen mode

It doesn't work because of the "Same Origin Policy".

It's a "critical security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin".

And this also applies to iframes.

"External" iframe's can't be accessed, nor manipulated from a document which is not served on the same origin (domain).

...

For completeness sake, I also tried to use the 3 most popular browser extensions that enable running custom scripts on any web page;

  • GreaseMonkey
  • TamperMonkey
  • ViolentMonkey.

I tested out a few StackOverflow suggestions, related to the configuration of those extensions, in a foolish attempt to beat the system.

But with no luck.

You can't beat the system by breaking its hard rules. Unless you're the One. And it turns out I'm not. At least not yet.

A glimmer of hope

Fortunately not all of my work was in vain.

As I was slowly accepting my fate, and getting ready to completely give up, I stumbled on an alternative approach to this problem.

There's a method called Window.postMessage

And its API looks kind of promising (with regard to CORS issues caused by external iframe communication).

So the story continues. Stay tuned. :)

Conclusion

Do you know any other way, or a hack, to bypass the Same Origin Policy?

Is there another approach to the "external iframe" problem, which I didn't think of?

Or is it just plain impossible to do this on the client (FE) side (which is a good thing I suppose, because it prevents malicious behaviour).

💖 💪 🙅 🚩
ispoljari
Ivan Spoljaric

Posted on July 14, 2021

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related