You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
annotation_layer.js has logic to keep input elements in sync. The logic uses document.getElementsByName with a name derived from the PDF to retrieve the set of related elements. This query is not namespaced, so if the viewer ever adds a name attribute to a checkbox or radio input in the page, then the PDF file can get it changed (without user interaction via the scripting interface). Fortunately, there doesn't appear to be any input/radio element in the default viewer code. A custom viewer can be affected by this bug, however.
I suggest to replace the document.getElementsByTagName calls with a function that checks that the elements are created by the annotation_layer.js code before returning them. There are several ways to do so, e.g. by adding a custom attribute to each input element.
Seemingly generic property assignment
This code on its own looks dangerous because it allows the caller to overwrite any property
- it aims to fixmozilla#14003.
- in a custom viewer, the use of document.getElementsByName could lead to get some elements which don't correspond to an annotation, so this patch removes it and annotations with the same fieldName are collected when they're created.
annotation_layer.js
has logic to keep input elements in sync. The logic usesdocument.getElementsByName
with a name derived from the PDF to retrieve the set of related elements. This query is not namespaced, so if the viewer ever adds aname
attribute to a checkbox or radio input in the page, then the PDF file can get it changed (without user interaction via the scripting interface). Fortunately, there doesn't appear to be any input/radio element in the default viewer code. A custom viewer can be affected by this bug, however.I suggest to replace the
document.getElementsByTagName
calls with a function that checks that the elements are created by theannotation_layer.js
code before returning them. There are several ways to do so, e.g. by adding a custom attribute to each input element.Seemingly generic property assignment
This code on its own looks dangerous because it allows the caller to overwrite any property
pdf.js/src/display/annotation_layer.js
Lines 684 to 688 in 99e4429
Fortunately, it is only called with a fixed key, so only the
value
property can be updated in response to user input events:pdf.js/src/display/annotation_layer.js
Lines 732 to 740 in 99e4429
Unchecking other checkboxes on checkbox state change
pdf.js/src/display/annotation_layer.js
Lines 979 to 990 in 99e4429
Updating the abstract state (storage)
pdf.js/src/display/annotation_layer.js
Lines 1061 to 1065 in 99e4429
Allowing scripts to uncheck checkbox/radio inputs
The others require user interaction to have any effect; this one allows scripts embedded in the PDF to run logic without user interaction.
pdf.js/src/display/annotation_layer.js
Lines 1073 to 1077 in 99e4429
The text was updated successfully, but these errors were encountered: