Too much information contained in .query

[jkiddo]

As discussed on https://chat.fhir.org/#narrow/stream/179166-implementers/topic/AuditEvent/near/397121962 I really don't think its a good idea to keep the entire raw request in

ITI.BasicAudit/input/pagecontent/volume-1.md

Line 127 in 6b858fc

The raw search request is base64 encoded and placed in the .entity[query].query element. The base64 encoding of the raw search request enables preserving exactly what was requested, including possibly malicious patterns. This enables detection of malicious or malformed requests.

. Its simply too dangerous and it will be a gold mine for exploiting long lived tokens from other users.
-this is also related to #87

[JohnMoehrke]

Is there some profile of the oauth token that can be described that preserves in the audit that which is useful while explicitly excluding the concerning portions? We need subject matter expert to define this profile of the oauth token for this use-case.

[JohnMoehrke]

no matter what we profile, the audit log is always a gold mine for exploiting. Long lived tokens are a bad security choice. I agree that we should limit the risk. However I had not received any subject matter expert advice by publication time. We can adjust this in a CP.

[jkiddo]

The auditlog is a goldmine for sure in itself. Adding the full requests with any potential long lived tokens to it takes it to a whole other level of exploit minefield as long lived tokens can be used for the purpose of getting access to data NOT yet in the auditlog.

[jkiddo]

My subject matter expert advice is as follows: Omit the full access token from the auditevent. If the access token is in the form of a signed JWT, then remove the signature part of it in the AuditEvent.

[jkiddo]

Going ahead making a publication where the full request and all headers are added to the auditlog is not recommended. I fail to understand if publication continues without addressing this. This comment has been around for 9 months and nothing has happened. If github is the wrong place for issues and the HL7 Jira is a better fit then I suggest to remove the option to raise issues on this repo.

[jkiddo]

Keeping the access token in its full form in the auditevent increases the number of attack vectors of the system.

[JohnMoehrke]

The problem with that is that both IUA and SMART have extensions in the oAuth token that are important to understand the transaction. We can't just not record this information. Plus there is a need to have some identity of the specific token somewhere.

[JohnMoehrke]

I have indicated multiple times... I want to profile what we record from the oauth token... please provide guidance to that goal.