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.
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;
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).
Top comments (9)
I love this approach.
It's doing the same thing I wanted in essence, but without the hassle with iframes. Much cleaner and streamlined.
CORS might be an issue though.. The iframe has it's own origin. And the server is configured to accept requests to /poll from within it. I think calling this endpoint from the console, or a bookmarklet, won't work because of this reason.
I will try it out anyway. Thx :)
If you’re open to running a script from outside the website (a node script), you could use a tool like puppeteer to open a web page, then have it click on the poll, then have it repeat the process indefinitely. It would mimic a real user so there would be no CORS issues. This is similar to how you would end-to-end test a website, but in this case you’d be “testing” another site.
Hey. Thx for the comment. I thought of a Node.js approach to bypass CORS. Not sure if it would work though - because iframes are weird. In any case that wouldn't be a client-side "attack" anymore.
True. But unlike browsers Node.js servers don't implement the Same Origin Policy. So technically speaking, yeah, you are still a "client" for the target BE - although somewhat different - even though you are running your script from a server. Maybe I should have been more precise and called it a "browser-side attack".
Based on experience, i know it would be easier to try this from the server side because there are no CORS related issues. I am just not sure what would happen if I tampered with iframes in this scenario. I'll have to test this out.
Try using selenium js