Skip to content

Add security considerations section #588

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

Merged
merged 4 commits into from
Jan 15, 2024

Conversation

aphillips
Copy link
Member

Addresses #579

Adds a document for appendices and populates with with Security Considerations. I considered adding this to the front matter, but observe that most documents place these types of materials at the end.

Please suggest other considerations as needed.

@duerst, please also have a look.

Addresses #579 

Adds a document for appendices and populates with with Security Considerations.
I considered adding this to the front matter, but observe that most documents place these types of materials at the end.

Please suggest other considerations as needed.
@aphillips aphillips added Agenda+ Requested for upcoming teleconference Action-Item Action item assigned by the WG specification Issue affects the specification LDML45 LDML45 Release (Tech Preview) labels Jan 10, 2024
@duerst
Copy link

duerst commented Jan 11, 2024

@aphillips Thanks for putting this together. Just a few comment, nothing serious:

  • "Unicode characters, excepting surrogates": Can be read as if surrogates were characters, an impression which we want to avoid at all costs.
  • "Users are also reminded that": That paragraph is perfectly okay for somebody who already understands bidi, but is a bit difficult to read for people for whom bidi isn't a major concern. I'd rewrite the text so that something like "right-to-left text" (preferably with the addition "e.g. Arabic or Hebrew") is mentioned very early in the paragraph.

Copy link
Collaborator

@eemeli eemeli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good start. We should also include discussion of custom functions as an attack vector. I presented this two years ago, but can't find the relevant meeting notes on it just now: https://docs.google.com/presentation/d/19Q90N6Z9HNF0t_bc2_jtUdYu2PKTPy1oFxuJsxrh2O8/edit?usp=drivesdk

@aphillips
Copy link
Member Author

@eemeli I think that's a good callout, but one we could include in a new PR.


Bidirectional text containing right-to-left characters (such as used for Arabic or Hebrew)
also poses a potential source of confusion for users.
Since MessageFormat 2.0's syntax makes use of
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to separate 2 cases: what the MF message appears like to the programmer, vs what a resulting message appears like to the user.

  1. For the former, UTS55 is relevant.
  2. For the latter, we can point out that MF conformance requires that placeholder replacements be generated in a way that avoids bidi reordering issues between the literal message text and the placeholder contents.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This text refers specifically to viewing the message in a source code context (and thus UTS55 is relevant).

That reminds me that there is probably the need to call out another security consideration, which is that the output of formatting needs to be examined for e.g. injection or other abuse.

MessageFormat _messages_ permit nearly all Unicode code points,
with the exception of surrogates, to appear in a _pattern_.
This means that it can be possible for a _message_ to contain invisible unquoted
control characters that abnormally affect the display of the _message_
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

control characters that abnormally affect the display of the message

Suggested change
control characters that abnormally affect the display of the _message_
control characters (such as bidirectional format characters) that abnormally affect the display of the _message_

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@duerst's original comment was about C0 controls. The bidi controls also certainly affect the display. I'll cite both.

This includes an attempt at @eemeli's comment from earlier.
@aphillips aphillips merged commit 2a2c2be into main Jan 15, 2024
@aphillips aphillips deleted the aphillips-security-considerations branch January 15, 2024 18:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Action-Item Action item assigned by the WG Agenda+ Requested for upcoming teleconference LDML45 LDML45 Release (Tech Preview) specification Issue affects the specification
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants