29 lines
1.5 KiB
Plaintext
29 lines
1.5 KiB
Plaintext
Using remote artifacts without integrity checks can lead to
|
|
the unexpected execution of malicious code in the application.
|
|
|
|
On the client side, where front-end code is executed, malicious code could:
|
|
|
|
* impersonate users' identities and take advantage of their privileges on the application.
|
|
* add quiet malware that monitors users' session and capture sensitive secrets.
|
|
* gain access to sensitive clients' personal data.
|
|
* deface, or otherwise affect the general availability of the application.
|
|
* mine cryptocurrencies in the background.
|
|
|
|
Likewise, a compromised software piece that would be deployed on a server-side application could badly affect the application's security. For example, server-side malware could:
|
|
|
|
* access and modify sensitive technical and business data.
|
|
* elevate its privileges on the underlying operating system.
|
|
* Use the compromised application as a pivot to attack the local network.
|
|
|
|
By ensuring that a remote artifact is exactly what it is supposed to be before
|
|
using it, the application is protected from unexpected changes applied to it before it is
|
|
downloaded. +
|
|
Especially, integrity checks will allow for identifying an artifact replaced by malware on the
|
|
publication website or that was legitimately changed by its author, in a more benign
|
|
scenario.
|
|
|
|
Important note: downloading an artifact over HTTPS only protects it while in
|
|
transit from one host to another. It provides authenticity and integrity checks
|
|
*for the network stream* only. It does not ensure the authenticity or security
|
|
of the artifact itself.
|