Add anti-tamper mechanism

[uncttao]

🚀 feature request

Relevant Package

All rendering related packages. Not sure about the specific ones.

Description

HTML editing is being abused by scammers to deceive gullible victims and extort their money. This usually happens in a fake tech support setting where the scammer first gains remote access to the victim's computer and pull up the victim's online banking website. Then, the scammer tries to distract the victim while at the same time open up the developer console and manually edit the HTML of the banking website to convince the victim that money is added to their account. Finally, the scammer proceeds to claim they added more money than s/he should and demands the victim to return the additional amount by purchasing the scammer gift cards, etc. The scam concludes if the victim falls for it.

Source: https://www.youtube.com/watch?v=03fvkJ27eOs (An Internet vigilante records and exposes how such scam works from start to finish.)

This is by no means a fringe problem. It is proven that scammers use similar techniques to conduct scam systematically in a career fashion, and millions of dollars per year are scammed out of gullible victims such as the computer illiterate and elderly population.

Source: https://www.youtube.com/watch?v=7rmvhwwiQAY (BBC documentary on the fake tech support scamming industry)

Describe the solution you'd like

Adding a kind of anti-tamper mechanism would significantly reduce the efficacy of such abuse if not eliminate it.

For instance, the Angular rendering system can listen at a regular interval (or respond to DOM change) and then compute if differentiation occurs at places where it is not supposed to occur. For example, consider the account balance display on a typical banking website, it is expected that such display is implemented using HTML elements such as <div>, <p> or <span>. In general, we do not expect the content of such elements to change except those computed from Angular according to the website's frontend logic. Angular should be able to detect such abnormal changes and eliminate them.

If implemented, this can be added as a build option flag ex. --anti-tamper to enable the feature in production.

Describe alternatives you've considered

We believe there is no easy workaround for this issue on the web developer side. It should be a feature that developers can enable on the framework level without additional effort.

[Airblader]

where the scammer first gains remote access to the victim's computer

At this point the victim has lost already. With remote access to the machine, the scammer can do virtually anything. If the mechanism described here would exist, they could disable JS, redirect to a phishing website, … – it would not help at all.

In terms of injection attacks Angular already has mechanisms in place to sanitize resources such as URLs and HTML.

[uncttao]

where the scammer first gains remote access to the victim's computer

At this point the victim has lost already. With remote access to the machine, the scammer can do virtually anything. If the mechanism described here would exist, they could disable JS, redirect to a phishing website, … – it would not help at all.

In terms of injection attacks Angular already has mechanisms in place to sanitize resources such as URLs and HTML.

Unsurprisingly, these scammers are not sophisticated hackers; they are regular joes hired by a mastermind to be trained to follow a script. If banking websites implement this security feature, it would at least put their current operation out of business for quite a while. At best, it would eliminate this scam completely as this model would no longer be cost-efficient.

I would further clarify the motivation of this ticket to be: 1) It is a "nice-to-have" feature for many applications. 2) It yields a tremendous social value of stopping an industry of crime. By all means, we should assess the cost and return value for implementing it. If somehow we could conclude that framework patching is not a good way to go, then I would be happy to inform this research to the security community and move on to better solutions.

[Airblader]

By all means, we should assess the cost and return value for implementing it.

My feeling is that it throws all performance out the window as you constantly have to check the entire DOM tree and compare it against the internal model. The change detection mechanism would no longer make sense.

But I'm not an expert on the internals of Angular, that's just my (possibly naive) expectation.

[angular-robot[bot]]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-robot[bot]]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.

[JoostK]

Closing as this hasn't received much interest and does not seem like a framework concern; this can be implemented in user code according to the desired requirements and trade-offs in terms of accuracy.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}