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
Currently, the API forbid users to use a storage power sensor that doesn't belong to them. Nonetheless, we are not checking that the entities within the flex-context and flex-model are readable by the user.
This fact could be used in a malicious way:
I think someone could exploit this fact to leak data, specially, inflexible device power. I would follow these steps:
Create a battery that is own by the "attacker" with an very large capacity with initial SOC = 100%
Set a site capacity constraint of 0 which forces the battery to supply the same energy to the inflexible device.
Set an efficiency to 1, constant price and prefer_charge_sooner = False
Add the target device as an inflexible device
Run a storage scheduler
This would make the battery track the power of the inflexible device and would get the data from any sensor.
which checks if the args have a "flex-model" or "flex-context", and then checks_access for each sensor we know can be in there, for the current_user and the "read" permission.
Currently, the API forbid users to use a storage power sensor that doesn't belong to them. Nonetheless, we are not checking that the entities within the
flex-context
andflex-model
are readable by the user.This fact could be used in a malicious way:
I think someone could exploit this fact to leak data, specially, inflexible device power. I would follow these steps:
This would make the battery track the power of the inflexible device and would get the data from any sensor.
Adapted from #897 (comment)
I suggest to create a utility function that checks if a user has the right access the data that is being used.
The text was updated successfully, but these errors were encountered: