Abuse reports/form

[tinsun]

Hi! You need to find a way to report abuse, since your site is being used for for eg phishing. Case in point: https://run.plnkr.co/plunks/MdCTqXVPIzSwEx2Y/

Regards, //Martin

[ggoodman]

Great idea. Thanks for the report.

[ggoodman]

@tinsun any thoughts on where in the UI this would be most effective?

[tinsun]

@ggoodman I think in general the best is if there's a report abuse link at the bottom of all pages (but maybe that messes too much with the ui), or a form link easily accessible from the footer of https://plnkr.co. Thanks for the swift action on the phishing page btw.

[philchippy]

Another phishing link here. Please take down https://run.plnkr.co/plunks/1JoPiqtMvys8gK7I/&sa=D&ust=1592566868916000

[ggoodman]

Thanks @philchippy, deleted.

[jdsnape]

Here's another one

https://run.plnkr.co/plunks/zWw7Qn4tZ32YD8fV/index.html

If you search run.plnkr.com on urlscan you can find loads of phishing sites that are still up - https://urlscan.io/search/#run.plnkr.co

[ggoodman]

Hi @jdsnape,

I've taken a different approach to this problem. You will see that users who are directed to the standalone runner for a saved plunk will see a phishing message by default.

Users must explicitly click through this interstitial.

Do you think that this addresses the underlying issue?

[yusufkayaer]

Hi @ggoodman Isn't there a general solution to this?

Our security systems block run.plunker.co because it has been reported as suspicious.

[ggoodman]

Hi @yusufkayaer, I'm still working on this. It appears that my solution is only working for run.plnkr.co when viewed via https:// and I'm investigating why.

[anjorinjnr]

Hi @jdsnape,

I've taken a different approach to this problem. You will see that users who are directed to the standalone runner for a saved plunk will see a phishing message by default.

Users must explicitly click through this interstitial.

Do you think that this addresses the underlying issue?

The dismiss doesn't work in embedded plnkr, is that intentional? We embed our own plnkr on our site, and it shows the warning, but the proceed and dismiss buttons don't do anything.

Do you plan to have a different solution for embeds?

Thanks.

[ggoodman]

@anjorinjnr this sounds like a pretty serious bug 🤔 . Can you share a link that would help me see what you're seeing?

[anjorinjnr]

Here's a screenshot, the link is behind a login so I can't easily share it.

And Video

If this isn't enough, I can try and figure out how to get you access.

PS: this behavior isn't consistent, sometimes it shows the warning and other times it doesn't.

thanks for looking into it.

[ggoodman]

@anjorinjnr I've struggled to reproduce this or rationalize what might be causing it to happen. The preview component is expected to be initiated in such a way that it should never present a phishing prompt.

Any chance of grabbing a HAR?

Also, I redeployed in the last few days. Can you give it a spin again (with a hard refresh)?

[anjorinjnr]

Hi @ggoodman I've attached a HAR file. Hopefully it helps.

I tried with an hard refresh and still got the prompt. Here is the exact embed I tried.

      <iframe
          src="https://embed.plnkr.co/plunk/VUPLQBKMlusfX4EZ?show=app,preview"
          frameBorder="0"
          width="100%"
          height="480px"
        ></iframe>

plnkr embed.har.zip

Thanks for your help.

[anjorinjnr]

So I think it's likely browser specific. I tried on it Firefox and it didn't get the prompt.

But I am getting it on Chrome Version 85.0.4183.121 (Official Build) (64-bit). I get the prompt for the example on your site as well https://ggoodman.gitbooks.io/plunker/content/embed.html

[ggoodman]

@anjorinjnr I've been looking into the HAR file and have some news on this front.

I'm seeing a few things that make me think that Firefox' additional security measures or some extra iframe sandboxing in play.

The normal way that this works is as follows:

1. The preview wrapper (an iframe served from run.plnkr.co) receives a refresh request from the main app and creates a hidden form (with a target attribute pointing to a nested iframe that will actually house the preview) that it POSTs to run.plnkr.co with the contents of the project files to preview.
2. The preview server (run.plnkr.co) responds to this with a 302 redirect on which it attaches a session cookie called praccept [1]. The redirect serves to change the request to a GET request for the inner iframe on the preview's actual url.
3. The browser redirects the inner preview iframe to the Location from the 302 redirect and SHOULD attach session cookies.
4. The preview server SHOULD receive the session cookie and thereby opt out of presenting the phishing page.

What I'm seeing is that the browser is not attaching the cookies as expected 💢 .

[1]: set-cookie: paccept=2020-10-08T16:20:24.845Z; HttpOnly; SameSite=true; Domain=run.plnkr.co; Path=/preview/ckg111p3l00073h5zi6r0woks/

@anjorinjnr can you confirm that there aren't any browser plugins that might be interfering?

[anjorinjnr]

Happy New Year @ggoodman

It doesn't look like the problem is a browser plugin because I can consistent reproduce on Chrome, Safari, Firefox and Edge

[yusufkayaer]

run.plnkr.co

hi @ggoodman

Is any update this situation. ?

Thanks.

[boghyon]

@ggoodman

The dismiss doesn't work in embedded plnkr, is that intentional?

@anjorinjnr this sounds like a pretty serious bug 🤔 . Can you share a link that would help me see what you're seeing?

Here is an article shared by @bbotto-pdga that has the same issue and reproducible: https://medium.com/@benjamin.botto/mirroring-drawings-symmetry-with-affine-transformations-591d573667ec.

Is it necessary in the first place that embed.plnkr.co shows the warning? Only run.plnkr.co would be useful for attackers since there is no additional UI from Plunker, making the page look like a genuine website.