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
Description of the Issue:
I have discovered a possible logic flaw in transaction handling. Specifically, the server accepts StopTransaction messages where the meterStop value is lower than the meterStart value from a corresponding StartTransaction message, leading to the storage of a negative charged value in the database.
Steps to Reproduce:
Send a StartTransaction message with a meterStart value.
Send a StopTransaction message with a meterStop value lower than the meterStart value.
Observe that the server processes the transaction and stores a negative value for the charged amount.
Expected Behavior:
The server should validate that the meterStop value is greater than or equal to the meterStart value to ensure transaction consistency and prevent illogical charging data.
Actual Behavior:
The server stores the transaction with a negative charged amount, which is illogical in the context of energy metering and could lead to financial discrepancies.
Potential Impact:
If left unaddressed, this could result in incorrect billing calculations, impacting the integrity of transactional data and potentially causing financial losses or disputes.
Attachments:
A screenshot showing the negative charged amount as recorded in the system:
Suggested Solution:
Implementing server-side validation checks to confirm that meterStop is not less than meterStart before accepting and storing transaction data would mitigate this issue.
Thank you for your attention to this matter. Looking forward to your response.
Best regards,
Gaetano Coppoletta.
The text was updated successfully, but these errors were encountered:
I'm reaching out for an update regarding this issue.
We are in the process of submitting Common Vulnerabilities and Exposures (CVEs) related to this matter. However, we can wait if you are in the process of fixing it.
Additionally, we intend to publish our findings in an academic paper.
Your prompt response and attention to this matter would be greatly appreciated as it will greatly inform our next steps.
I'm planning to add an optional config switch for that.
OCPP.Core has no integrated billing. So there is no real risk of negative payments.
With Issue #31 we have seen that the server should not simply reject a StopTransaction-Request. This might lead to problems in the chargers state because the car can always force a stop. So when the charger sends a lower meter value the server should still accept the stop request. It is the mistake of the charger if it sends a wrong meter value. But rejecting the stop request most probably means that the charger repeats sending the same stop request over and over.
That's why I'm planning to add an OPTIONAL config switch for that.
Description of the Issue:
I have discovered a possible logic flaw in transaction handling. Specifically, the server accepts
StopTransaction
messages where themeterStop
value is lower than themeterStart
value from a correspondingStartTransaction
message, leading to the storage of a negative charged value in the database.Steps to Reproduce:
StartTransaction
message with ameterStart
value.StopTransaction
message with ameterStop
value lower than themeterStart
value.Expected Behavior:
The server should validate that the
meterStop
value is greater than or equal to themeterStart
value to ensure transaction consistency and prevent illogical charging data.Actual Behavior:
The server stores the transaction with a negative charged amount, which is illogical in the context of energy metering and could lead to financial discrepancies.
Potential Impact:
If left unaddressed, this could result in incorrect billing calculations, impacting the integrity of transactional data and potentially causing financial losses or disputes.
Attachments:
Suggested Solution:
Implementing server-side validation checks to confirm that
meterStop
is not less thanmeterStart
before accepting and storing transaction data would mitigate this issue.Thank you for your attention to this matter. Looking forward to your response.
Best regards,
Gaetano Coppoletta.
The text was updated successfully, but these errors were encountered: