Any pointers are much appreciated.

Hemant,

I am not sure which "obvious threats" you mean. Storing (almost) arbitrary textual data in DICOM data elements such as Study Description or Requested Procedure Description should not be an issue for the PACS. Of course, your web service should clearly distinguish between "user input" and "code" (that is to be executed). However, this requirement is not DICOM specific.

Regards,
Jörg

On Wednesday, 29 March, 2023 at 1:02:40 am UTC+5:30, Jörg Riesmeier wrote:
> Hemant,
>
> I am not sure which "obvious threats" you mean. Storing (almost) arbitrary textual data in DICOM data elements such as Study Description or Requested Procedure Description should not be an issue for the PACS. Of course, your web service should clearly distinguish between "user input" and "code" (that is to be executed). However, this requirement is not DICOM specific.
>
> Regards,
> Jörg
Thanks Jörg for the reply. I agree its not a direct dicom specific requirement and of course the textual data resting in the Dicom Data elements as such would not be an issue, but it might create issues for the applications (e.g. viewers) consuming these dicom objects where they may try to render the dicom meta information in the frontend. Another aspect of this could be PACS servers storing / retrieving dicom meta information in database.

I somehow do not see a possibility of blacklisting / whitelisting being effective due to the wide character set allowed.

My question is more to understand if you (community) also have come across this situation and if you consider this as potential threat?
If yes, then what resolutions were applied to mitigate this?

On Thursday, April 6, 2023 at 3:29:15 PM UTC+2, Hemant Jain wrote:
> On Wednesday, 29 March, 2023 at 1:02:40 am UTC+5:30, Jörg Riesmeier wrote:
> > Hemant,
> >
> > I am not sure which "obvious threats" you mean. Storing (almost) arbitrary textual data in DICOM data elements such as Study Description or Requested Procedure Description should not be an issue for the PACS. Of course, your web service should clearly distinguish between "user input" and "code" (that is to be executed). However, this requirement is not DICOM specific.
> >
> > Regards,
> > Jörg
> Thanks Jörg for the reply. I agree its not a direct dicom specific requirement and of course the textual data resting in the Dicom Data elements as such would not be an issue, but it might create issues for the applications (e.g. viewers) consuming these dicom objects where they may try to render the dicom meta information in the frontend. Another aspect of this could be PACS servers storing / retrieving dicom meta information in database.
>
> I somehow do not see a possibility of blacklisting / whitelisting being effective due to the wide character set allowed.
>
> My question is more to understand if you (community) also have come across this situation and if you consider this as potential threat?
> If yes, then what resolutions were applied to mitigate this?

IMHO this a client-side only threat. I can store "rm -rf --no-preserve-root /" in e.g. the PatientName and this will never be an issue on any Windows system. So just be sure to sanitize those strings on the client side. If you client side is Web/JavaScript, there are frameworks to sanitize strings which may contains `<script/>` or `On*` events.

2cts