Open Tano-Coppoletta opened 1 year ago
Hello,
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.
Thank you and looking forward to your response.
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.