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 guidance has arisen as a mitigation against problems like the recent bootstrap-sass gem being backdoored in v3.2.0.3 - thankfully it was caught early.
The exploit relied on the gem having access to run code on the production server, specifically rack middleware.
Given the bootstrap-sass gem's purpose is to provide JS and CSS resources for the frontend only, this dependency ideally wouldn't have access to run code on the server. However, as a gem, this isn't possible, gems can always run code on the server.
To mitigate, avoid including frontend dependencies as gems. Instead, these dependencies can be included in a number of other ways which don't give access to the backend at runtime, e.g.:
This guidance has arisen as a mitigation against problems like the recent bootstrap-sass gem being backdoored in v3.2.0.3 - thankfully it was caught early.
The exploit relied on the gem having access to run code on the production server, specifically rack middleware.
Given the bootstrap-sass gem's purpose is to provide JS and CSS resources for the frontend only, this dependency ideally wouldn't have access to run code on the server. However, as a gem, this isn't possible, gems can always run code on the server.
To mitigate, avoid including frontend dependencies as gems. Instead, these dependencies can be included in a number of other ways which don't give access to the backend at runtime, e.g.:
(Aside: Could
require: false
inGemfile
production
group act as a less effective mitigation? Assuming assets are compiled outside of runtime?).For details on the bootstrap-sass backdoor:
The text was updated successfully, but these errors were encountered: