Companies Per Solution

JS PROXY

JS Proxy – is a method that can be utilized in the browser that allows an overwrite of some of the JS prototypes, for example, you can overwrite the input.get.value prototype and decide if you want to allow it or not.

Security considerations

Though JS Proxy allows for a much more granular control, it will prove less than effective when a whitelisted or “trusted” 3rd party provider is breached and is leveraged to spread malicious code. This is due to the fact that JS proxy is fairly easy to bypass, in simple terms; what was overwritten by the page, can be overwritten again by the hacker.

If a whitelisted 3rd party is hacked, they can import a “clean” prototype and simply use it instead of the proxied prototype.

Complications introduced by implementing and maintaining JS Proxy

JS Proxy is a powerful tool for website protection and data management, but will also introduce some complications and challenges that might result in loss of revenues and exhaustion of valuable resources:

MARKETING

• Time to market – using JS Proxy means that any added 3rd party script will have to go trough an R&D process of identification and whitelisting of a lot of its actions. This will create a cumbersome, long, and tiering process for both R&D and marketing and will affect the time to production of any new provider; it will also cost greatly
  in R&D resources.
• Possible loss of abilities – any action blocked by the proxy might cause that script to stop working, on occasions, identifying these issues might take days or even weeks, during that time important functions are lost.

R&D

• Resources – managing JS Proxy on your site will require constant examination of new 3rd party tools, keeping track of the different 4th parties and constant updates of your website on any new 3rd party added or, any 3rd party remove.

LIMITATION OF CSP & SRI

Content Security Policy (CSP) is an added layer of security that helps to mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribution of malware.

CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those whitelisted domains, ignoring all other script (including inline scripts and event-handling HTML attributes).

Security considerations

Though CSP and SRI might mitigate some of the risks of XSS, they will prove less than effective when a whitelisted or “trusted” 3rd party provider is breached and is leveraged to spread malicious code. This is due to the fact the CSP will only affect the page itself, but not the whitelisted elements of 3rd parties, specifically; iFrames.

If a whitelisted 3rd party is hacked, they can gather any information from any area of the page, transmit that to a foreign iFrame they create coming from their domain, and, since that iFrame is not under the CSP policy, use that iFrame to transmit that data anywhere else.

Considering the above, the recent hacks on British Airways, Ticketmaster or the [24]7. ai breach, would not have been prevented by this technology.

Complications introduced by implementing an maintaining CSP

CSP is a powerful tool for website protection and data management, but will also introduce some complication and challenges that might result in loss of revenues and exhaustion of valuable resources:

MARKETING

• Time to market – using CSP means that any added 3rd party script will have to go through an R&D process of identification and whitelisting of a lot of its actions. This will create a cumbersome, long, and tiering process for both R&D and marketing and will affect the time to production of any new provider; it will also cost greatly in R&D resources.
• Possible loss of abilities – since any new domain must be whitelisted beforehand, any change done by a 3rd party in their internal domains (for example, a new CDN) might cause that script to stop working. On occasions, identifying these issues might take days or even weeks, during that time important functions are lost.
• Partnerships – many 3rd party vendors support partnerships with additional vendors which allows them greater efficiency and higher ROI. These partnerships will usually be triggered by different user profiles and may change based on multiple factors, making impossible to predict.Since CSP required any 4th party domain to be whitelisted, most 4th party partnerships will most likely be blocked. Though this is not visible when examining the behavior of a 3rd party on the page, it will affect the bottom line of that partnership, especially with DMP’s, remarketing tools and specialized campaign aid tools.

PCI DSS 4.0 makes client-side security a priority.

Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.

Download the Guide