How to prevent third-party scripts to take over?

JavaScript
1

There is always a risk that a third party script takes over the control. It can be in an ad link tha tdownload a js script dynamically. It can be in a library bundle for which one has downloaded it but without lookign at the source for new versions.

With Javascript, one controls lots of things: history of pages, cached files, whatever the data there is on the page.

Is there a way to make a part of the page more isolated against third party scripts?

One way I see is the Iframe since it uses a separate page.

2

So, you are talking from the view of a site-owner, rather than a site-visitor?

You might run into issues loading everything into an iframe, and you’re really just shuffling the problem to the site living in the iframe, no?

Here are a few ideas. They are not exhaustive:

You should be setting a same-origin policy heading on your site (stuff like third-party JS tend to get around same-origin by using JSONP as a hack but be aware these can be injected).

If you’ve got forms you could have your backend whatever make a CSRF token or cookie.

Don’t use any of those large advertising networks on your site unless you can personally vet every party of that network (usually you can’t, I’ve heard).

When using something from a CDN (let’s say you want to use jQuery), see if the thing you are downloading has an MD5 hash. If it does, you should always check this hash to check that what you downloaded is what the CDN domain claims to offer. Of course, if the CDN store is compromised then I suppose the attacker could make their evil MD5 and then you’d think you had a match but I haven’t heard of anyone actually doing that.
Instead you hear a lot about people not checking anything and the third-party being compromised (like BrowseAloud).

If you really don’t need the latest version of some offsite resource (again let’s use jQuery) you could have a local version instead of the user calling the CDN. This does however defeat the benefit of maybe the user has already cached that script or resource.

If you’re using something like AWS or CloudFront or whatever, make sure you list all the hostnames you use in your panel. Like, every subdomain. I dunno how common it is, but having a (sub)domain who isn’t specifically listed may open you to domain fronting (someone makes another page in the same cloud as you and since you didn’t name your (sub)domain, they could name it. Then since some of these cloud services look at the Host heading, they’ll redirect users to this other person’s page and the domain will look legit).

You could try using Javascript tokens (JSON Web Tokens) instead of cookies for keeping track of sessions, or HTTP-only cookies (which either can’t be hijacked or it’s hard to).

I dunno, those are some ideas.

1 Like
3

You can reduce possibilities, but it can still happen.

Many advertising companies use a script HTML element with a source that is dynamically loaded from a URL. This means Javascript injection. IF you want to use it, then you must enable cross origin requests.

ANother example is in your source Javascript by using libraries you don’t look at carefuly.

An iframe will isolate the content in the iframe. I think it is a very good solution. Yo ucan communicate betwee nthe apge and the iframe with messages so all you ened is possible.

4

and how does it prevent any of the things you mentioned in your OP?

Let me be more specific:

That’s not related to your page, and the iframe can manipulate the browser’s history just as easily as the main page.

see above answer.

you’ve put your data into an iframe. Which can be edited by the scripts in the iframe. This hasn’t removed the problem, it’s just put a border around it so people can easily see you’ve loaded an iframe to watch it happen.

5

YEs good point.

Note that the code injection inside the iframe cannot acces data on the page outside the iframe.

Sites can use the X-Frame-Options header to prevent cross-origin framing.

6

the html element script or the header tag script allows cross-origin by default.

cookies, localstorage and other are sperated by origins.

I am not sure the browser history is available in JAvascript. Only for the current session. That seems logical since browser history has personal information about preferences.

7

Note that the code injection inside the iframe cannot acces data on the page outside the iframe.

…but, if I could inject code into your iframe, and if you’re using the iframe to show your page… then what did you gain? What’s outside your iframe that you’re trying to protect?

Unless you’re thinking of using the iframe to stuff the 3rd-party ads in. But I feel anyone allowing those ad-network 3rd-party ads are just being loose with security of their visitors anyway. It’s not sustainable and there are a lot more robot-clickers than actual people clicking those ads. The whole ad model is broken and I worry it’ll be the end of independent publishers.

We need user-agent micro-payments now, in my opinion.

In any case, I didn’t mention it above but yeah, I’d always set my x-frame-options to deny or sameorigin (there’s no point in setting allow-from since chromium said “no”).

ANother example is in your source Javascript by using libraries you don’t look at carefuly.

…and random npm dependencies :P.

You can reduce possibilities, but it can still happen.

Such is life in security : ) It’s more like disaster management: build your houses on good foundations, not in flood zones, fire zones, on the edge of cliffs or the foot of vulcanos, and then have a decent detection, evac and disaster plan in place.

1 Like
8

Hey cool I love reading these: Wordpress hack: https://blog.ripstech.com/2019/wordpress-csrf-to-rce/

it’s just… brilliant.

Always sanitize your HTML, kids. And then get someone to try to break your sanitation (what they’re doing here to get an inline JS on the anchor is not dissimilar to getting a <script> tag through sanitation by wrapping m0aR script around it (hey <scr<script>ipt> woo!).

1 Like
10

your link about code injection is interesting. When they say that the injected code can modify the cookie, it true for random npm deps but not for cross origin scripts since cookies are separated cross origins.

11

The is a common login way that uses other websites, A popup opens and you can choose to login with google or facebook, etc. I did not realize the first time I saw it how unsecured it is. The practical application is probably sincerely good.

12

As your link explains, injected Javascript can siphon input passwords. But the injected Javascript cannot cross the border of the ifframe. So if you put your form inside an Iframe, it is not siphonable.

13

…but your iframe is a page. It has a URL. If I saw everything was inside an iframe, I’d stop attempting to do anything to the page hosting the iframe, and just… do my evil on the iframe. It’s just another page.

14

no you cant control the iframe from the outside. And even cahche data is segmented.

You can use messages with the iframe.

15

That depends:

  • If the parent frame and the iframe are from the same domain, you can control the iframe from the parent frame
  • If the parent frame and the iframe are from differerent domains, you can not control the iframe from the parent frame

Never heard that one before. Do you have a source for that?

16

but the content of the iframe cannot control what lies outside of the iframe.

But yes a parent page would control the iframe. Though the communication to it is limited. And you cannot inject Javascript.

17

Again, if the iframe and the parent window are from the same domain, it can.

Third party scripts loaded within the iframe cannot access the parent frame. Maybe you meant that?

18

OK I was wrong. Thank you.

19

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.