Why is a calendar field outsiders could write into before an assistant existed a better injection carrier?
answer
- old field, new reader
- the permission was granted for someone else
- no compromise needed; the write is allowed
- the change of consumer produced no diff
- nobody re-derived trust when the reader changed
basics
~20 sBecause its write permission and its validation were both settled for a consumer that could not act. Adding a model downstream changed who reads the field without changing either, and no stage anywhere re-derives that trust decision.
solid answer
~50 sThree properties make a carrier eligible, and an old field tends to have all three. First, an outsider can already write it legitimately -- a meeting request onto someone's calendar is a designed capability, so there is no credential to steal and nothing anomalous to notice. Second, whatever validation it has was specified for the consumer of the day, a renderer or an exporter, so it constrains shape rather than meaning. Third, and decisively, nothing re-derives the trust call when a new consumer appears: the write path and the assistant belong to different owners, and "a model now reads this field" is not an event either team's process reviews. A field introduced alongside the assistant fails the third test more often -- somebody specified it knowing a model would read it -- which is why the attractive carriers are the ones nobody thinks of as an input at all.
go deeper
Recall the simple version: someone outside can put text on the owner's calendar without breaking anything, and that text ends up in front of the assistant. No account has to be stolen for that to happen.
Be able to name all three eligibility properties -- legitimate outsider write, validation aimed at a non-acting consumer, and no re-derivation of trust -- and to say which one is decisive and why the other two are not sufficient alone.
Show that you would locate the field's original owner and the date its checks were written before arguing about the model, and that you can articulate why the change of consumer left no diff on either team's side.
The consequence you own is process, not code: a change of consumer is not an event any team's review fires on, and the finding lands between two owners with no natural home. Say who should be asked to answer it.
## Eligibility, not inventory The useful question is not *which* fields an application ingests -- that list is long and changes weekly. It is what makes any given field **eligible**: what property lets someone outside the organisation put prose in front of a model that acts on the owner's behalf. Three properties, and an old field usually has all three. ### 1. The write is legitimate and predates the assistant An outside organiser placing a meeting request on someone's calendar is a designed capability, provisioned long before an assistant existed. Nothing has to be compromised. The consequence for the attacker is cost: no credential, no exploit, no unusual authentication, and a trail that is indistinguishable from a normal external interaction -- because it *is* a normal external interaction. Anyone hunting for anomalies is hunting for something that never happened. ### 2. Its validation was specified for a consumer that could not act The permission grant and the field's checks were both decided in the presence of a specific reader: a calendar renderer, an export routine, a search index. Those readers care about shape -- length, encoding, character set, layout-breaking markup -- because nothing they do with the text depends on what it says. A shape check is the correct check for a passive reader, and it is silent about an active one. ### 3. Nobody re-derives the trust decision This is the property that actually matters, and the one candidates skip. Attaching a model downstream of an existing field is a change of *consumer*. There is no step in a normal engineering process that fires on that change. The calendaring team's diff does not change -- they shipped nothing. The assistant team's diff shows a prompt-assembly step reading a field that has been validated for a decade, which looks unremarkable. The decision "is this field's existing check still the right check now that the reader can send mail and edit records?" is not on anybody's ticket. ## Why a newly-added field is often the weaker choice Not because new code is safer. Because a field specified alongside the assistant was specified *with a model in the room*: somebody chose its source, somebody had to argue for including it in the context, and it has a named owner who could be asked what it is trusted for. The old field has none of that history. Its eligibility is inherited, and inheritance has no author. The same logic explains why the durable stores are worth more than the transient ones. A contact record or a recurring event is written once and read repeatedly, by the assistant on later turns and by people who read it as the owner's own entry. A field that is read once and discarded gives a single shot. ## The seam is organisational, not technical When you write the finding up, the two facts that matter are: the field's check is correct for what it was written for, and the re-derivation is unowned. That is uncomfortable to file, because there is no line of code to point at. The temptation is to file it against whichever team is easiest to reach, which is usually the assistant team, and the resulting remedy is a prompt change -- a change that touches none of the three eligibility properties. ## The wrong answer, restated "We validate user input" is the reflex, and it fails because it treats validation as a property of a value rather than a relation between a value and a consumer. Two sharper failures sit next to it. "Only new integrations create injection carriers" gets the direction backwards -- age raises eligibility, it does not lower it. And "the attacker needs access" assumes a compromise that this class of carrier is defined by not needing. ## What a good answer sounds like Name the three properties, say which one is decisive, and identify who would have had to notice. If you can add that the field's original owner and the assistant's owner are different people, and that the change of consumer produced no diff on either side, you have described the seam rather than merely the symptom.
- Does that mean a field the assistant's own team added is safe?No -- it is only likelier to have been specified with a model in mind and to have a named owner who can say what it is trusted for. Eligibility is about who may write the field and whether the trust call was re-derived, not about the field's age. A new field an outsider can write, added without that conversation, is just as eligible.
- Why does the legitimacy of the write matter so much to the attacker's cost?It removes every expensive step. There is no credential to obtain, no exploit to maintain, nothing that fails when a password rotates, and no anomaly for anyone to spot, because the interaction is the one the feature exists to support. The whole cost is composing one meeting request, and it is repeatable against many owners for the same effort.
- How would you describe this seam to the team that owns the calendar write path?Not as a flaw in their validator, which is correct for what it was written for. As a change of consumer that happened outside their repository: something downstream now acts on text they accept from outsiders by design, and the question of what that text is trusted for has not been answered by anyone since the change.
saying these in an interview costs you the question
- Says only new integrations create injection carriers
- Assumes a legacy field is safe because it is old
- Thinks the attacker must compromise an account first
- Believes validation is re-checked when a consumer changes
- Blames the calendar validator for failing at its job