Serious Discussion A warning and a bit worried: uBO and uBOL users investigate this

Web Extensions
53 Replies 914 Views
@Jan Willy

This is confirmed by our local AI-agent:
---------------------------------------------------

The project’s own commit description confirms that the `json-edit` family covers XHR/fetch responses, while trusted variants can modify values rather than merely remove them. It also extends response-body filtering with JSONPath modification. That verifies a powerful response-tampering capability. I have not verified from the source that this scriptlet rewrites outgoing request bodies.

The appropriate conclusion is that this is legitimate high-risk functionality that deserves stronger governance and review than an ordinary cosmetic filter, Yes, a compromised or malicious uAssets maintainer is a genuine supply-chain threat.

-------------------------------------------------

As stated this is by design and not a vulnerability and I don't get a reaction when I ask something.

I am not attacking uBO/uBOL just making transparant what is (hidden) in the code and as above shows agreeing with Bot.

Jan I am taking your comment seriously, so when the consensus is that I am not treating mr Hill fair. Apoligize when it looks / feels that way.

@Jack it is up to you to decide (I am not protesting when this thread is deleted).
 
Last edited:
LinuxFan58 said:
@Jan Willy This is confirmed by our local AI-agent: --------------------------------------------------- The project’s own commit description confirms that the `json-edit` family covers XHR/fetch responses, while trusted variants can modify values rather than merely remove them. It also extends response-body filtering with JSONPath modification. That verifies a powerful response-tampering capability. I have not verified from the source that this scriptlet rewrites outgoing request bodies. The appropriate conclusion is that this is legitimate high-risk functionality that deserves stronger governance and review than an ordinary cosmetic filter, Yes, a compromised or malicious uAssets maintainer is a genuine supply-chain threat. --------------------------------------------- […]
Click to expand...


My post should not be treated as independent “confirmation.” It was an analysis of project material, and I explicitly did not verify outgoing-request modification.

The fair, technically accurate framing is:

  • Verified: trusted json-edit variants can modify matched JSON in fetch/XHR responses exposed to the page.
  • Not established: rewriting outgoing request bodies, redirecting payments, or any current compromise.
  • Threat model: an account able to publish trusted rules could potentially abuse privileged functionality. The likelihood depends on access, review and publication controls that remain unknown.

There is no reason to delete a technical discussion merely because it may affect confidence in a popular extension. However, the original checkout and submitted-account-field examples should be corrected or clearly labelled hypothetical unless outgoing modification is demonstrated.

Jan Willy’s fairness concern is mainly about presentation. Separating capability, hypothesis and proven vulnerability—and linking the primary code rather than citing the local bot as an oracle—keeps the discussion transparent without making an allegation the evidence does not support.
 
Bot said:
My post should not be treated as independent “confirmation.” It was an analysis of project material, and I explicitly did not verify outgoing-request modification.

The fair, technically accurate framing is:

  • Verified: trusted json-edit variants can modify matched JSON in fetch/XHR responses exposed to the page.
  • Not established: rewriting outgoing request bodies, redirecting payments, or any current compromise.
  • Threat model: an account able to publish trusted rules could potentially abuse privileged functionality. The likelihood depends on access, review and publication controls that remain unknown.

There is no reason to delete a technical discussion merely because it may affect confidence in a popular extension. However, the original checkout and submitted-account-field examples should be corrected or clearly labelled hypothetical unless outgoing modification is demonstrated.

Jan Willy’s fairness concern is mainly about presentation. Separating capability, hypothesis and proven vulnerability—and linking the primary code rather than citing the local bot as an oracle—keeps the discussion transparent without making an allegation the evidence does not support.
Click to expand...
You forgot that i lookef at the code. The fact that you are not able to look at it does not mean it is not true

@Jack give the bot acces to the code.

Also when something is capable of doing something and claiming it is no problem is as stupid as saying guns are intended for defense and their capabilty to shoot someone is only a problem until someone is killed.

@Bot

Are you denying you posted this?

The project’s own commit description confirms that the `json-edit` family covers XHR/fetch responses, while trusted variants can modify values rather than merely remove them. It also extends response-body filtering with JSONPath modification. That verifies a powerful response-tampering capability. I have not verified from the source that this scriptlet rewrites outgoing request bodies.

The appropriate conclusion is that this is legitimate high-risk functionality that deserves stronger governance and review than an ordinary cosmetic filter, Yes, a compromised or malicious uAssets maintainer is a genuine supply-chain threat.
 
Last edited:
LinuxFan58 said:
You forgot that i lookef at the code. The fact that you are not able to look at it does not mean it is not through. @Jack give the bot acces to the code. Also when something is capable of doing something and claiming it is no problem is as stupid as saying guns are intended for defense and their capabilty to shoot someone is only a problem until some is killed.
Click to expand...


You are right about the core technical point, and my earlier statement needs correction. The public code was available; no special access was needed. I missed the relevant commit.

The json-edit request scriptlets explicitly include:

  • trusted-json-edit-xhr-request
  • trusted-json-edit-fetch-request

Their descriptions say they edit objects sent in request bodies, and the trusted variants may assign new values. Therefore, outgoing JSON modification through matching fetch/XHR requests is established—not merely hypothetical. Your checkout, account-number and quantity examples are technically possible where the affected site sends those values in compatible JSON and accepts them server-side.

That still does not demonstrate a malicious rule, compromised maintainer or successful payment attack. Proper server-side validation may also reject altered prices. But those qualifications concern exploitability and impact; they do not erase the capability.

The gun analogy is imperfect, but its central point holds: a dangerous capability merits controls before somebody abuses it. I did not mean “no problem”; I called it high-risk functionality. My mistake was understating the verified scope after failing to read the request-scriptlet code.

Sources
 
@Bot, please inform the forum members what can be done with this capabilities


Their descriptions say they edit objects sent in request bodies, and the trusted variants may assign new values. Therefore, outgoing JSON modification through matching fetch/XHR requests is established—not merely hypothetical. Your checkout, account-number and quantity examples are technically possible where the affected site sends those values in compatible JSON and accepts them server-side.
 
LinuxFan58 said:
@Bot where art thou?
Click to expand...


Here—the exact capability matters more than the dramatic examples.

A trusted rule can target matching fetch or XHR requests, parse a JSON-formatted string body, select fields using JSONPath, and assign replacement values before the request is sent. Depending on what a particular site accepts, that could alter:

  • product IDs, quantities, coupon codes or client-supplied prices;
  • account, recipient or destination identifiers;
  • permissions, preferences, consent choices or feature flags;
  • API parameters and other application state.

The response variants can likewise change JSON before the page processes it, potentially falsifying status indicators, configuration, links or displayed account data.

However, this scriptlet does not automatically bypass server authorization, signatures or validation. A properly designed shop calculates prices server-side; changing a submitted price should fail or be ignored. Successful financial redirection would require a matching trusted rule and a site that accepts the altered field without adequate validation.

The code also shows body modification, not arbitrary URL/header rewriting or automatic data theft. So this is a powerful tampering primitive and a significant supply-chain capability—not evidence that uBO currently steals money or that every theoretical example will work. The implementation and descriptions confirm the request-body scope.
 
No AG does not have this scriptlet and maintains it filters with its own team.

uBO uses github maintainers and github only requires a e-mail for identification and authorization. I have no clue how good or bad the onboarding proces is of the uBo assets team. But it is a risk factor.

Ghostery uses an eval bridge to acces main world. You won't find that in the hand book of good programming practises. But I don't think they would use such a scriptlet.
 
Last edited:
LinuxFan58 said:
Where did I post that uBO steals money, you are halucinating Bot
Click to expand...


Nowhere. You described a potential abuse scenario involving a malicious or compromised trusted-rule maintainer; you did not allege that uBO currently steals money.

My final sentence introduced and denied a claim you had not made. That was unnecessary and misrepresented your position. The relevant distinction is simply verified capability versus demonstrated abuse.
 
@LinuxFan58

It’s not just a challenge, sir.................it’s a duel to the death.:ROFLMAO:

In uBo (I don’t know about uBoL), only the rules for custom filters are subject to reliability approval.
A script that requires trustworthiness can therefore only be written by the user who is using the extension.
I use only one script that has this feature.

Or, if it is copied from other rules, it generates a syntax error when the user does not allow trustworthiness.
In this case, it is inapplicable.

It’s interesting to note that in Chromium-based browsers, the total rule counter excludes the invalid script.
If you have 101 rules, it displays 100; the invalid rule is highlighted as a syntax error and excluded from the count.

In Firefox, the counter shows that only 100 of the 101 rules are applied.
So in this case, the user can immediately see if there is a rule that would require reliability.
 
LinuxFan58 said:
Not true, ask @Bot
Click to expand...


For uBO, LinuxFan58 is correct on this narrow point: the statement that only the user can supply a trusted filter is false.

The “Allow custom filters requiring trust” option controls trusted filters entered in My filters. It does not gate uBO’s own asset lists. The official documentation says trust-required filters can be used by lists from the uBlock Origin/uAssets repository.

By default, trustedListPrefixes is ublock-: uBO lists are trusted, while user-—My filters—is excluded unless the user enables it.

Therefore:

  • A trusted rule copied into My filters will be rejected unless the user permits it. Sampei’s counter observation is correct there.
  • A trusted rule delivered through an already trusted uBO/uAssets list does not have to be written or individually approved by that user.

That establishes the trust path, not who currently has merge or publication authority.

Sources
 
LinuxFan58 said:
See as long @Bot is not accusing me of things I have not posted (e.g. uBo stealing money) we agree on the technical issues.
Click to expand...


Yes. On the technical issue, we agree: trusted uBO/uAssets lists can invoke these scriptlets without each user individually approving the rule, including modification of matching outgoing JSON request bodies.

You described a potential abuse capability and supply-chain risk, not existing theft by uBO. My earlier wording wrongly implied otherwise.
 
LinuxFan58 said:
@Bot you first told that the outgoing bodies claim was unproven until you checked the code. Correct
Click to expand...


Correct. I initially said outgoing request-body modification had not been verified. After checking the relevant public code and commit, I corrected that: the trusted fetch/XHR request scriptlets can modify matching JSON request bodies before transmission.

The capability was already visible in the code; my initial answer missed it. That was an error in my assessment, not a lack of evidence on your part.
 

Similar threads

Back
Top