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
This is a self-reporting response to the W3C TAG security questionnaire. As such, where possible, we follow the order of questions in that document.
Note that JSPI is an API that is focused on general access of WebAssembly programs to asynchronous APIs. In that sense, JSPI is not a 'regular' API that accesses some direct functionality but a 'meta' API that facilitates such access.
Questions to Consider
What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
JSPI does not itself expose information that is not otherwise available. For example, JSPI can be used to facilitate access to an API that exposes information, but does not itself offer any new information not otherwise available to the application.
Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
As noted above, JSPI changes the way that applications access information and APIs, but neither adds nor subtracts from such capabilities.
How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
JSPI does not directly use or offer any PII.
How do the features in your specification deal with sensitive information?
The JSPI does not change how such sensitive information is handled. JSPI itself does not require any information beyond the type signature of functions that are to be imported/exported.
Do the features in your specification introduce new state for an origin that persists across browsing sessions?
No.
Do the features in your specification expose information about the underlying platform to origins?
Other than the ability to enable a WebAssembly function to be suspended, and later resumed as a result of a Promise being resolved, no. Note that this is similar to the ability of an asynchronous JavaScript function to be suspended; although the technology used is different. In particular, JSPI does not rely on, nor does it offer, any information about any threading capabilities of the client.
A malicious origin may attempt to use this to guess how much memory a client has (by creating many suspensions); but this does not appear to be a novel source of information.
Does this specification allow an origin to send data to the underlying platform?
Only by using existing Web APIs such as fetch.
Do features in this specification enable access to device sensors?
Only by using existing Web APIs.
Do features in this specification enable new script execution/loading mechanisms?
Yes. It allows a WebAssembly program to be suspended. In combination with Web APIs such as fetch, it allows a WebAssembly application to be loaded in a non-linear fashion.
The JSPI does not affect the execution or the loading of JavaScript applications.
Do features in this specification allow an origin to access other devices?
No.
Do features in this specification allow an origin some measure of control over a user agent’s native UI?
No.
What temporary identifiers do the features in this specification create or expose to the web?
The primary such temporary identifier is the so-called Suspender object. A new Suspender object is created every time a WebAssembly module's export is invoked. The lifetime of the Suspender object is bounded by the lifetime of the call to the WebAssembly function.
Suspender objects are opaque values that are not inspectable by either a JavaScript application nor by a WebAssembly application.
How does this specification distinguish between behavior in first-party and third-party contexts?
It does not.
How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
No difference.
Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
TBD
Do features in your specification enable origins to downgrade default security protections?
No.
How does your feature handle non-"fully active" documents?
No changes to existing specifications are anticipated. If a non-fully active document cannot process events, this API does not change that.
What should this questionnaire have asked?
The questionnaire does not ask anything about WebAssembly specifically. One of the issues that the WebAssembly CG has considered has been how information can and should flow between modules; this is a potential issue when linking together multiple modules.
Threat Models
Overall, in addition to the threat models discussed in the TAG document, the WebAssembly CG identifies execution of malicious code to be a primary threat.
WebAssembly employs a sandbox model to protect the browser from executing malicious code; however, that does not protect the user from malicious or incorrectly programmed WebAssembly modules.
The JSPI does not change the overall stance wrt threat models. However, we also enforce a limitation on the use of JSPI: specifically that JavaScript programs cannot use JSPI to change the execution of JavaScript applications.
Network attackers
Since WebAssembly does not offer direct access to the network (network APIs must be explicitly imported into a WebAssembly module), we do not see any change in the threat of network attackers with JSPI.
One point that may be worth raising is the use of network APIs on the main thread. Generally, WebAssembly applications could not use network APIs on the main thread; but JSPI allow them to do so in a way that is analogous to how asynchronous JS code also allow JS programs to use network APIs on the main thread. It is not known if this increases the threat vector for WebAssembly applications.
Legitimate Misuse
Overall, the JSPI does not appear to create any new attack surface for WebAssembly. However, asynchronous programming generally is difficult and can potentially create opportunities for bugs.
More generally, given the nature of WebAssembly, and the fact that a primary group of users using WebAssembly to compile C/C++ code, there is definitely a risk of corrupt data and of buffer overruns in WebAssembly code. The WebAssembly sandbox model does mitigate this; and, for example, it is not possible to use buffer overruns to execute malicious code. However, other attack vectors, such as SQL injection, remain.
Mitigation
Given the nature of JSPI, it does not seem that additional mitigation strategies need to be employed; beyond the already standard techniques for WebAssembly.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This is a self-reporting response to the W3C TAG security questionnaire. As such, where possible, we follow the order of questions in that document.
Note that JSPI is an API that is focused on general access of WebAssembly programs to asynchronous APIs. In that sense, JSPI is not a 'regular' API that accesses some direct functionality but a 'meta' API that facilitates such access.
Questions to Consider
JSPI does not itself expose information that is not otherwise available. For example, JSPI can be used to facilitate access to an API that exposes information, but does not itself offer any new information not otherwise available to the application.
As noted above, JSPI changes the way that applications access information and APIs, but neither adds nor subtracts from such capabilities.
JSPI does not directly use or offer any PII.
The JSPI does not change how such sensitive information is handled. JSPI itself does not require any information beyond the type signature of functions that are to be imported/exported.
No.
Other than the ability to enable a WebAssembly function to be suspended, and later resumed as a result of a Promise being resolved, no. Note that this is similar to the ability of an asynchronous JavaScript function to be suspended; although the technology used is different. In particular, JSPI does not rely on, nor does it offer, any information about any threading capabilities of the client.
A malicious origin may attempt to use this to guess how much memory a client has (by creating many suspensions); but this does not appear to be a novel source of information.
Only by using existing Web APIs such as fetch.
Only by using existing Web APIs.
Yes. It allows a WebAssembly program to be suspended. In combination with Web APIs such as fetch, it allows a WebAssembly application to be loaded in a non-linear fashion.
The JSPI does not affect the execution or the loading of JavaScript applications.
No.
No.
The primary such temporary identifier is the so-called Suspender object. A new Suspender object is created every time a WebAssembly module's export is invoked. The lifetime of the Suspender object is bounded by the lifetime of the call to the WebAssembly function.
Suspender objects are opaque values that are not inspectable by either a JavaScript application nor by a WebAssembly application.
It does not.
No difference.
TBD
No.
No changes to existing specifications are anticipated. If a non-fully active document cannot process events, this API does not change that.
The questionnaire does not ask anything about WebAssembly specifically. One of the issues that the WebAssembly CG has considered has been how information can and should flow between modules; this is a potential issue when linking together multiple modules.
Threat Models
Overall, in addition to the threat models discussed in the TAG document, the WebAssembly CG identifies execution of malicious code to be a primary threat.
WebAssembly employs a sandbox model to protect the browser from executing malicious code; however, that does not protect the user from malicious or incorrectly programmed WebAssembly modules.
The JSPI does not change the overall stance wrt threat models. However, we also enforce a limitation on the use of JSPI: specifically that JavaScript programs cannot use JSPI to change the execution of JavaScript applications.
Network attackers
Since WebAssembly does not offer direct access to the network (network APIs must be explicitly imported into a WebAssembly module), we do not see any change in the threat of network attackers with JSPI.
One point that may be worth raising is the use of network APIs on the main thread. Generally, WebAssembly applications could not use network APIs on the main thread; but JSPI allow them to do so in a way that is analogous to how asynchronous JS code also allow JS programs to use network APIs on the main thread. It is not known if this increases the threat vector for WebAssembly applications.
Legitimate Misuse
Overall, the JSPI does not appear to create any new attack surface for WebAssembly. However, asynchronous programming generally is difficult and can potentially create opportunities for bugs.
More generally, given the nature of WebAssembly, and the fact that a primary group of users using WebAssembly to compile C/C++ code, there is definitely a risk of corrupt data and of buffer overruns in WebAssembly code. The WebAssembly sandbox model does mitigate this; and, for example, it is not possible to use buffer overruns to execute malicious code. However, other attack vectors, such as SQL injection, remain.
Mitigation
Given the nature of JSPI, it does not seem that additional mitigation strategies need to be employed; beyond the already standard techniques for WebAssembly.
Beta Was this translation helpful? Give feedback.
All reactions