Repository navigation
Stamp queued events with the time they were built - #736
Conversation
![aikido-pr-checks[bot]](https://avatars.githubusercontent.com/in/898896?s=60&v=4){kind=small}
| "time": get_unixtime_ms(), | ||
| "agent": get_manager_info(self), | ||
| } | ||
| payload = {"agent": get_manager_info(self)} |
There was a problem hiding this comment.
Removing the default time changes reports without an event-supplied timestamp; events with an explicit creation time already override the default during payload.update(event).
Details
✨ AI Reasoning
The intended behavior is to record event creation time for selected events. Those events already include a time field, and merging them into the payload replaces the default send-time value. Removing the default therefore changes behavior for reports that do not supply their own time, without being needed for the intended change.
🔧 How do I fix it?
Limit the change to what's needed to achieve its intent. Avoid bundling unrelated reformatting or refactoring, and don't rewrite code that didn't need to change.
Reply on this comment to give feedback or ignore the issue.
More info
There was a problem hiding this comment.
All five event types now set their own time
There was a problem hiding this comment.
⛔ You don't have permission to ignore issues.
| payload = {"agent": get_manager_info(self)} | ||
| payload.update(event) # Merge default fields with event fields | ||
|
|
||
| result = self.api.report(self.token, payload, self.timeout_in_sec) |
There was a problem hiding this comment.
🟡 Medium - A missing timestamp poisons the attack-event rate limiter
A local process can submit two put_event messages containing detected_attack events without time through the unauthenticated background-process socket (Trigger). The first malformed event is appended to the rate limiter's history, and the next detected attack tries to read that history entry's missing timestamp; report_api_event catches the exception but leaves the bad entry in place (Mechanism). Every subsequent detected-attack report in that background process is then dropped, disabling attack telemetry until restart (Consequence).
Show fix
| payload = {"agent": get_manager_info(self)} | |
| payload.update(event) # Merge default fields with event fields | |
| result = self.api.report(self.token, payload, self.timeout_in_sec) | |
| payload = {"agent": get_manager_info(self)} | |
| payload.update(event) # Merge default fields with event fields | |
| if payload.get("type") == "detected_attack" and not isinstance( | |
| payload.get("time"), (int, float) | |
| ): | |
| return {"success": False, "error": "invalid_event"} | |
| result = self.api.report(self.token, payload, self.timeout_in_sec) |
More info - Reply on this comment to give feedback or ignore the issue.
There was a problem hiding this comment.
🔴 We were not able to ignore this issue because of the following reason:
You do not have the permission to ignore issues.
| def __init__(self, event): | ||
| # Event is a dictionary containing data that is going to be reported to core | ||
| # "time" and "agent" fields are added by default from the CloudConnectionManager | ||
| # The CloudConnectionManager adds "agent", and "time" if the event has none |
3 participants
Custom, attack and attack wave events are reported from the background process up to five seconds after they happen, and in batches, so the send time distorted when and how tightly they occurred.