-
-
Notifications
You must be signed in to change notification settings - Fork 36
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
Conversation
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 Thanks for putting this together. Just a few comment, nothing serious:
|
There was a problem hiding this 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
@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 |
There was a problem hiding this comment.
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.
- For the former, UTS55 is relevant.
- 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.
There was a problem hiding this comment.
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.
spec/appendices.md
Outdated
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_ |
There was a problem hiding this comment.
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
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_ |
There was a problem hiding this comment.
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.
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.