Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

170
Visualizações
Threat Assessment Javascript User-controlled Variable Names on Window

I have a requirement to support some external integration to a 3rd party vendor on our site (which is a SaaS site with multiple tenant logins). The vendor requires a script and a global variable to be available which the script reads to get some extra info. In this case, the vendor's script will run on the page, add some "help" content in the corner of the screen which helps the user. This vendor only has a few different URL patterns it would need, and there is one uuid variable in the script JS file that targets the tenant (e.g. the company) that is integrated with this vendor.

One option for us is to very specifically target this vendor, add an admin screen called "Configure X" (where X is the vendor name) and then ask the admin to select which environment (prod/preview) and enter the uuid and that's it. This would be quick, easy, and probably safest to do this way.

However, suppose we offered even more flexibility - this could be used for this Vendor and as well as other similar Vendors too. The Admin page could be called "Configure Integrations" (or similar) and gives Admin flexibility to add as many Global Variables or Scripts URLs they want - with some restrictions:

  1. only users with special admin permission can modify the settings for the tenant
  2. global variable names have a black list, you cannot specify global variable names that match particular patterns
  3. global variable values must be defined as a JSON string, so cannot be functions or something else
  4. script URLs will have a white list of base URLs, base URLs will start with https:// and end with / -- the script URLs must start with one of these base URLs, for now the white list will only include this one vendor

With this new flexible approach - is there any thing I'm not thinking about that a malicious actor with permissions to modify this set of globals/scripts could do?

The code behind the startup script might look like this

const {globals, scripts} = /* JSON config object persisted by Admin user. */
globals.forEach(({name,value}) => { window[name] = JSON.parse(value); });
scripts.forEach(({url}) => { /* create <script> with src=url, then add to body */ });

My first thoughts here are that the scripts here are white listed to only a set of origins - but the path after the domain part is not restricted - so that might go to somewhere bad (but I guess it would be from the vendor... though, right?)

Then the globals - what if they put something weird there like overwrite something some other script would try to inject scripts from or something - so I'd really need to do research into the black list.

Is there anything else here I should consider, is this a really bad idea?

about 4 years ago · Juan Pablo Isaza
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda