Related issue:
https://github.com/uBlockOrigin/uBOL-home/issues/325
This is a first version, with support only for custom filters which are
plain CSS selectors. Future versions will extend support to style-based
and procedural cosmetic filters.
Manually text-editing existing custom filters is currently not supported,
this will be added in a future version in the Develop pane. To remove
existing custom filters, the "Remove a custom filter" tool can be used.
As discussed with filter list maintainers.
@scriptlet edit-inbound-object.js
@description
Prune properties from an object passed as argument to a specific method.
Properties can only be removed.
@param propChain
Property chain of the method to trap.
@param argPos
0-based position of the argument. Use negative integer for position relative
to the end.
@param jsonq
A uBO-flavored JSONPath query.
@scriptlet trusted-edit-inbound-object.js
@description
Edit properties of an object passed as argument to a specific method.
Properties can be assigned new values.
@param propChain
Property chain of the method to trap.
@param argPos
0-based position of the argument. Use negative integer for position relative
to the end.
@param jsonq
A uBO-flavored JSONPath query.
edit-outbound-object-.js
@description
Prune properties from an object returned by a specific method.
Properties can only be removed.
@param jsonq
A uBO-flavored JSONPath query.
trusted-edit-outbound-object.js
@description
Edit properties from an object returned by a specific method.
Properties can be assigned new values.
@param jsonq
A uBO-flavored JSONPath query.
json-edit-xhr-request.js
@description
Edit the object sent as the body in a XHR instance.
Properties can only be removed.
@param jsonq
A uBO-flavored JSONPath query.
@param [propsToMatch, value]
An optional vararg detailing the arguments to match when xhr.open() is
called.
trusted-json-edit-xhr-request.js
@description
Edit the object sent as the body in a XHR instance.
Properties can be assigned new values.
@param jsonq
A uBO-flavored JSONPath query.
@param [propsToMatch, value]
An optional vararg detailing the arguments to match when xhr.open() is
called.
json-edit-fetch-request.js
@description
Edit the request body sent through the fetch API.
Properties can only be removed.
@param jsonq
A uBO-flavored JSONPath query.
@param [propsToMatch, value]
An optional vararg detailing the arguments to match when fetch() is
called.
trusted-json-edit-fetch-request.js
@description
Edit the request body sent through the fetch API.
Properties can be assigned new values.
@param jsonq
A uBO-flavored JSONPath query.
@param [propsToMatch, value]
An optional vararg detailing the arguments to match when fetch() is
called.
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
Related issue:
https://github.com/uBlockOrigin/uBOL-home/issues/157
The `header=` option will be converted into DNR's `responseHeaders`
condition.
There will be an attempt to convert regex-based values into DNR-
compatible syntax. Not all regex-based patterns can be converted to
use DNR's patterns with `*` and `?` special characters.
The implementation of `header=` option in uBO has been revisited to
improve compatibility with DNR syntax to minimize burden for list
maintainers when creating `header=` filters compatible with both
uBO and uBOL.
The changes:
- Header names are now case-insensitive by default
- Occurrences of `*` in non-regex-based header values now mean
"matches any number of characters"
- Occurrences of `?` in non-regex-based header values now mean
"matches zero or one character"
At time of commit, and as per MDN, only Chromium-based browsers
currently support filtering on repsonse headers:
https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/API/declarativeNetRequest/HeaderInfo
Also as per MDN, Chromium 121-127 silently ignore the `responseHeaders`
condition, potentially causing undue blocking of network requests.
Currently uBOL support Chromium 122 and later, meaning we need to mind
potential false positives in Chromium 122-127 for filters using
`header=` option.
The quoted email below was sent to ubo-security at raymondhill dot net:
=====
Dear Raymond,
I am writing to report a potential Regular Expression Denial of Service (ReDoS)
vulnerability in the 1p-filters.js script of uBlock Origin. The vulnerability
occurs due to the use of the regular expression /\s+$/, which is used to remove
trailing whitespace. This issue can lead to a denial of service when processing
strings with a large number of trailing spaces, potentially causing a browser to
freeze.
Affected file(s)
js/1p-filters.js
Vulnerable pattern(s)
Lines 131 and 167: /\s+$/
Description of the issue
The regular expression /\s+$/ is applied to remove trailing whitespace in user‑
provided content. However, when the content has a large number of spaces
(e.g., ~100,000), this pattern causes excessive backtracking in the regular
expression engine, resulting in performance degradation and UI freezing. This is
a classic ReDoS attack vector.
Steps to reproduce
1. Open the uBlock Origin dashboard and navigate to the My filters tab.
2. Run the following code in the browser's DevTools Console or as a bookmarklet.
3. Observe the UI freezing for several seconds or even longer, depending on the
number of spaces used.
PoC (Proof of Concept)
/**
* poc.js — triggers ReDoS in 1p-filters.js
* Expected: <1 ms; Actual: several seconds – UI freeze
*/
(() => {
const payload = " ".repeat(100000) + "!"; // 100,000 spaces + sentinel
const run = () => {
if (!window.cmEditor) {
console.error("cmEditor not ready");
return;
}
// Inject payload into the editor
cmEditor.setValue(payload);
console.time("ReDoS");
// Call the vulnerable function (mirroring getEditorText)
cmEditor.getValue().replace(/\s+$/, '');
// Alternatively, simulate a realistic user flow:
// document.querySelector('#userFiltersApply').click();
console.timeEnd("ReDoS");
};
if (document.readyState === "complete") {
run();
} else {
window.addEventListener("load", run, { once: true });
}
})();
Impact
This issue can significantly degrade the user experience, causing the page to
become unresponsive. If an attacker can inject this malicious string into the
page (for example, through XSS or other attacks), it could lead to a denial of
service (DoS). This vulnerability can be triggered repeatedly, causing the
browser to hang indefinitely.
Suggested fix
The issue can be mitigated by replacing /\s+$/ with a more efficient solution,
such as a look‑behind assertion /(?<=\S)\s+$/ (available in modern browsers)
which ensures no backtracking occurs, or using trimEnd() for legacy support:
// Example of using look-behind:
cmEditor.setValue(text.replace(/(?<=\S)\s+$/, '') + '\n\n');
// Alternatively, using trimEnd():
cmEditor.setValue(text.trimEnd() + '\n\n');
Additional information
If required, I am happy to assist in testing or provide more information.
Please feel free to contact me for further clarification.
Best regards,
[redacted]
=====
As discussed with filter list maintainers.
* @scriptlet trusted-create-element
*
* @description
* Element(s) from a parsed HTML string are added as child element(s) to a
* specific parent element in the DOM.
*
* @param parent
* A CSS selector identifying the element to which created element(s) will be
* added.
*
* @param html
* An HTML string to be parsed using DOMParser, and which resulting elements
* are to be added as child element(s).
*
* @param duration
* Optional. If specified, the time in ms after which the added elements will
* be removed. No removal will occur if not specified.
In Firefox, scriptlets are dynamically registered as content scripts
to ensure they execute in a timely manner.
The race condition could lead to scriptlet injection failing at
browser launch time in Firefox when the setting "Suspend network
activity until all filter lists are loaded" had been disabled[1],
even after forcing a page reload. Causing the filter lists to
reload would make the issue go away.
[1] Default is enabled in Firefox and it is strongly advised to NOT
change this.
Support for paths allows to narrow down specific static extended
filters to specific webpages on a given site.
Examples of usage:
example.com/toto##h1
/example\.com\/toto\d+/#@#h1
Scriptlets added:
- json-edit
- trusted-json-edit
- json-edit-xhr-response
- trusted-json-edit-xhr-response
- json-edit-fetch-response
- trusted-json-edit-fetch-response
- jsonl-edit-xhr-response
- trusted-jsonl-edit-xhr-response
- jsonl-edit-fetch-response
- trusted-jsonl-edit-fetch-response
These scriptlets are functionally similar to their `json-prune` counterpart,
except that they all use the new uBO-flavored JSONPath syntax, and the
`trusted-` versions allow to modify values instead of just removing them.
The `replace=` filter option has been extended to support applying
uBO-flavored JSONPath syntax to the response body. If the `replace=`
value starts with `json:` or `jsonl:`, the remaining of the value will
be interpreted as a JSONPath directive, which can be used to either
remove or modify property in a JSON document.
@description
Conditionally prevent assignment to `innerHTML` property.
@param [selector]
Optional. The element must matches `selector` for the prevention to take
place.
@param [pattern]
Optional. A pattern to match against the assigned value. The pattern can be
a plain string, or a regex. Prepend with `!` to reverse the match condition.
As discussed with filter list volunteers.
`generichide` option is implicitly enforced on all sites unless an
exception overrides `generichide`. Though rare, sometimes a
`generichide` exception needs to be overridden so that generic
cosmetic filtering is made possible on a specific site.
This commit is to add support for restoring generic cosmetic
filtering on sites which were excluded through a `generichide`
exception.
Concretely, this is needed to ensure the test suite can properly
verify that generic cosmetic filtering is working when the
filtering mode is set to "complete":
||ublockorigin.github.io^$generichide,important
Related issue:
https://github.com/uBlockOrigin/uBlock-issues/issues/3576
This is the first step, a trivial code change which disable the
injection of `Cache-Control` header in Firefox.
In the next dev cycle, the second step will be to remove all
the code related to `Cache-Control` injection.
New syntax for scriptlet-based filtering: it is now possible to
inject a scriptlet in a context according to whether an ancestor
origin matches a specific hostname. Example:
example.com>>##+js(set, iAmEmbeddedInExampleDotCom, true)
The new `>>` specifier means that the scriptlet will not be injected
in `example.com`, but will be injected in all direct and indirect
embedded contexts in pages loaded from `example.com`
The new ancestor domain specifier also works for entity directives:
example.*##+js(set, iAmEmbeddedInExampleDotEffectiveTLD, true)
This is an experimental feature, to be further evaluated and
discussed by filter list maintainers. This is not a complete
implementation, by choice. Do not open issues regarding this
new syntax, the current shortcomings are known.
The new syntax is being discussed internally at:
https://github.com/uBlockOrigin/uBlock-discussions/discussions/244
This extends coverage of strict-blocking to pattern-based filters
with `doc` filter option.
When proceeding with a URL-skip URL present, no temporary bypass
will be created when the "Don't warn me again about this site" is
left unchecked. The idea is to avoid the intermediate redirects
if we navigate again on the same strict-blocked site, while a
temporary bypass would prevent this.
uBO's "Badware risks" list has been spinned off as its own list.
The idea is that should a site be strict-blocked from that list,
we would want to know the strict-block is due to the
"Badware risks" list.
Deserialization failed to restore proper ArrayBuffer when used by
multiple TypedArrays.
This didn't affect uBO since this specific code path was never
taken.
