-
-
Notifications
You must be signed in to change notification settings - Fork 388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repeated StartTransaction Messages Accepted Post StopTransaction Without Database Records #1294
Comments
i don't know about you, but the logic behind these steps is sound to me. here is the justification. if the exact same message (semantically) is sent twice, we interpret this as a retry (due to technical reasons). even if one field is different (different semantics), a different and new transaction. |
Thank you for your response and the explanation of the message handling logic. I would like to point out a potential security issue that arises from the ability to resend an identical StartTransaction message. Consider a scenario where a user legitimately starts a transaction to charge their car and captures the OCPP StartTransaction message. If the system treats the resending of this exact message as a legitimate retry and starts a new charging session without recording it in the database, the user could potentially reuse the same message to repeatedly initiate charging sessions in the future without authorization and without incurring any cost. Given that charging stations are physically accessible, an attacker—or in this case, even a regular user—could exploit this to charge their vehicle multiple times while avoiding payment, as the transactions are not being recorded after the first instance. This could lead to unauthorized use of electricity and financial losses. |
i could undo the changes and treat every message as a brand new StartTransaction, but then i would clutter the database with noise and effectively bring back the pains expressed in #81. the code was added after the report in the issue. i am not sure how big of an issue this is with our user base currently after a couple of years. this would also increase the ghost transactions which need to be handled after the fact. considering rejections of repeated StartTransactions: we cannot reject an incoming StartTransaction. this is according to ocpp. a proper StartTransaction response needs to be sent back. and there is no possibility to express a failure within the StartTransaction response payload. we can return a general CallError, but this will result in station retrying for X times in intervals of Y. it will drop the message after exhausting the retries. so, this option would result in information loss and we cannot employ this approach. unfortunately, as far as station is concerned, the first StartTransaction was communicated, but the reply of steve did not arrive at station properly. we could detect the subsequent retries and return with an AuthorizationStatus that is not Accepted in order to signal to station to stop this immediately and by doing that close the attack vector you mentioned. but then, if this is a valid retry we would reduce the usability, operation and customer experience. another possibility is to "seal" a transaction after a while the first StopTransaction from station arrives, and not allow any more StartTransaction retries by returning CallError. however, all these possibilities assume steve to be a tight controller and gatekeeper for the sake of security. there is a tone in spec that offline behaviour of stations is as important as online behaviour. therefore, all these StartTransactions and StopTransactions can/should be treated as "happenings/events of the past being reported to backend". this diminishes the role of the backend, and we cannot be as tight as you would like. the station must do the right thing. |
Hello, I also want to let you know that we are planning to submit this as cve and publishing this result in an academic paper. Thank you for your attention to this matter. |
Checklist
Specifications
Expected Behavior
Once a
StartTransaction
message is sent and subsequently stopped with aStopTransaction
message, any further attempts to send the sameStartTransaction
message should not be accepted, as the transaction has already concluded. The system should respond with an appropriate error message indicating that the transaction is already stopped. Additionally, attempts to start a new transaction should require a unique transaction initiation message, rather than accepting a message that differs only by a single parameter such asmeterValue
.Actual Behavior
After stopping a transaction, sending the same
StartTransaction
message again is erroneously accepted by the system, but no new record is created in the database. This could mislead users into believing that a new transaction has started when, in fact, it has not. Furthermore, it's possible to initiate a new transaction by altering a single field in theStartTransaction
message, which could lead to transaction duplication and data inconsistencies.Steps to Reproduce the Problem
StartTransaction
message and receive atransactionId
.StopTransaction
message to end the transaction.StartTransaction
message. Notice that the system accepts the message, but no record is created in the database, the previoustransactionId
is returned by the server.meterStart
) in theStartTransaction
message and send it again. Observe that a newtransactionId
is generated and a new transaction appears to start.Additional context
This behavior can lead to significant issues with transaction management, where the system's state does not accurately reflect the actual transactions that have occurred. It can cause confusion, make it difficult to track transaction history accurately, and might have implications for billing and auditing processes.
Thank you for your time and consideration in addressing this issue.
The text was updated successfully, but these errors were encountered: