Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
FormattableMarkup warning about use in "<" and ">" of an HTML tag talks about placeholder, use in placeholder string is documented in PlaceholderTrait
Proposed resolution
Make the warning about use of the object (the string value in the object).
Remaining tasks
Task | Novice task? | Contributor instructions | Complete? |
---|---|---|---|
Create a patch | Instructions | ||
Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards | Instructions |
User interface changes
No
API changes
No
Data model changes
No
Comment | File | Size | Author |
---|---|---|---|
#52 | 2580505-52.patch | 8.18 KB | smustgrave |
| |||
#52 | interdiff-44-52.txt | 2.14 KB | smustgrave |
#26 | 2580505-25.patch | 8.31 KB | krknth |
#24 | interdiff-24.txt | 1.77 KB | kgoel |
#24 | 2580505-24.patch | 8.31 KB | kgoel |
Comments
Comment #2
YesCT CreditAttribution: YesCT commented#2577785: Remove PlaceholderTrait changed things.
Comment #3
YesCT CreditAttribution: YesCT commentedComment #4
YesCT CreditAttribution: YesCT commented@xjm in #2577785-35: Remove PlaceholderTrait asked for some followups. I think can use this, since the placeholdertrait changes I was going to make are now in FormattableMarkup also.
Comment #5
YesCT CreditAttribution: YesCT commentednot really true, also url for img src.
added words about security to motivate people that they actually *do* want to go read it.
made the beginning of each @ % : section use parallel wording, an tell people when they should use it (and not use it) at the beginning.
Comment #6
YesCT CreditAttribution: YesCT commentedmade consistant use of " or ' in the placeholderFormat calls.
Comment #7
YesCT CreditAttribution: YesCT commentedadding a reference for looking up which HTML attributes can take a URL value
to clarify:
Comment #8
YesCT CreditAttribution: YesCT commentedactual patch this time.
Comment #9
stefan.r CreditAttribution: stefan.r commentedThe grammar here sounds a bit funny
Is there a reason we are moving this?
+1
This change may not be needed, in the parent issue it was decided to only support the "href" attribute?
Just to be clear, what is this about and how is this related?
This change may not be needed, in the parent issue it was decided to only support the "href" attribute?
+1 to less of the $this->placeholderFormat noise. Should we keep the explanations that were removed in the first hunk of the patch?
This change may not be needed, in the parent issue it was decided to only support the "href" attribute?
Comment #10
YesCT CreditAttribution: YesCT commentedI missed the part where we decided to only support href. Is there a particular comment I can look at?
Comment #11
stefan.r CreditAttribution: stefan.r commentedComments #42 and #50 in the parent. Other attributes than href are untested, and the docs state to only use formattablemarkup for simple markup. Core has no use case for any other attributes, and contrib can be added as people ask for it.
Comment #12
jhodgdonmoving to docs component, right?
Comment #13
YesCT CreditAttribution: YesCT commentedI think this puts back the clarification that only href is supported.
Comment #14
YesCT CreditAttribution: YesCT commentedchanging unsupported to be more strongly worded as insecure.
Comment #15
YesCT CreditAttribution: YesCT commented#9 5. yeah, I think it was asked for in the parent issue, but also handled there. and the linked issue has the related issue on it, so just taking that out.
[edit: need to respond to #9 1. and 2.]
Comment #16
jhodgdonI think maybe this isn't done, but I took a look through the docs as they are and have some comments. This is confusing stuff.
Overall: I think we should say something, somewhere (not sure where), about the general strategy for all these new formatting objects. Which I think is: when you are formatting some text, you need to always use the proper objects and placeholders to format anything that comes from the database (which is usually unsanitized) or user input (definitely unsanitized). If you do so, everything should be escaped exactly once, not zero times (security risk) or multiple times (ugly).
This text doesn't quite get that across to me. Some detailed notes follow, but that is the general gist.
This is totally changing the meaning of this section of docs. Is that right?
Because before it was basically saying:
Within the string you are formatting with placeholders, don't use placeholders in the part that is between < and > in an HTML tag.
And now it says something totally different:
Don't use the output of formatting this entire thing between < and > of an HTML tag.
I don't think that is the right change to make?
I don't get it. Why is this a security risk? It is supposedly sanitized -- just below it says it is sanitized. So why is this a security risk? The security risk would only happen if you also used the wrong object to sanitize that placeholder.
Yes, but that is presumably because the MarkupInterface object has previously been properly sanitized. If it was the right object and right placeholders to begin with, you should be OK?
But... The point is that you don't want to double-escape tags. If you use the right type of string formatting/sanitizing class, you should be OK right?
Also I had to read this at least twice to understand it. Can it say something like:
... instead of passing a MarkupInterface object directly as the placeholder replacement value, cast it to a string first.
how about "... but you want the placeholder value to be wrapped in em tags..." or something like that? Confusing as it is.
I thought it said above that it's only for href attributes, not for all attributes?
ok so this contradicts it. Better not to have contradictory text in the docs.
Comment #17
YesCT CreditAttribution: YesCT commentednot yet addressing #16.
#9 2.
yes. put the warning right up front so people know.
#9 1. awkward wording...
addressing that now.
Comment #18
YesCT CreditAttribution: YesCT commentedneeds work for #16.
Comment #19
kgoel CreditAttribution: kgoel at Forum One commentedI am working on this.
Comment #20
kgoel CreditAttribution: kgoel at Forum One commentedAddressed https://www.drupal.org/node/2580505#comment-10451213 5, 6 and 7 in this patch.
Comment #21
jhodgdonI still don't know about this patch.
a) It cuts out a huge amount of documentation. Is this somewhere else? If so we should at least point there.
b) It makes a statement about security that I still do not understand.
Comment #22
YesCT CreditAttribution: YesCT commented#21
a. No, it does not cut a huge amount of documentation, it moves it to better locations.
b. yes. that could have been stated in comment #20 when the patch was posted. we are only partially through addressing your earlier feedback.
#16
I agree, adding some clarity (see the section "overall" in #16) is a good idea.
1.
Kind of. That information is still there, but is moved to the @param where it is relevant.
The section then on the *class* doc block *is* changed, to be about what to do with the class object (not about how to use a param on a method of the class).
Which I think is an improvement.
2. 3. and 4. need some more thought. I would like to get @pwolanin's input there.
And maybe add some more detail to the insecure examples to make what the risks are more clear. (right now the examples just say what not to do, they do not say what would happen if it were done insecurely.)
Comment #23
YesCT CreditAttribution: YesCT commentedlooking at the interdiff in #20
lost the information about the placeholder class.
"but is" should probably be "but it is"
Comment #24
kgoel CreditAttribution: kgoel at Forum One commentedAddressed #23 1 and 2.
Comment #25
pwolanin CreditAttribution: pwolanin as a volunteer commentedre #16
2) I'm not sure an attribute value is an example that's easy to see why it's dangerous. But, let's assume an href. I can supply a value like this which is fully escaped but still allows me to execute arbitrary javascript when the link is clicked:
If we assume tag name, or an attribute name, they are even more trivial to exploit. This is why we have the special ":" placeholder for URLs to strip dangerous protocols in URL attribute values.
3) This is basically the replacement for the ! placeholder in D7 - we want some markup to pass through. This should have some more warnings perhaps.
4) I guess there are cases where double escaping is better than no escaping, or the markup object maybe have safe HTML but we need plain text.
Comment #26
krknth CreditAttribution: krknth as a volunteer and commented#24
minor changes in patch about exceeding 80 characters.
not added any interdiff file.
Comment #27
stefan.r CreditAttribution: stefan.r commentedThis wording here still seems a bit confusing
We're changing
wrapped in <em> tags
towrapped in an em tag with a placeholder class
, but isn't the previous wording clearer?Use when the placeholder value is to be used as the value of a "href" attribute.
The bit about the href attribute is repeated here.
Not just in $string, maybe this could be more forceful about us not supporting any HTML attribute anywhere through any placeholder (just href).
"@variable" or "%variable"
Should these have more explanation about why these are insecure (see the removed code on top of this patch)?
":variable" placeholder
This is not insecure, just unsupported :)
Comment #28
jhodgdonStatus was wrong, per last review.
Comment #36
jungleComment #38
nikitagupta CreditAttribution: nikitagupta at Srijan | A Material+ Company for Drupal India Association commentedComment #39
nikitagupta CreditAttribution: nikitagupta at Srijan | A Material+ Company for Drupal India Association commentedReroll the Patch #26 also covers #27.
Comment #40
nikitagupta CreditAttribution: nikitagupta at Srijan | A Material+ Company for Drupal India Association commentedReroll the Patch #26 also covers #27.
Comment #41
davidhernandez+ * - The result of casting this object to a string should not be used within
I had trouble reading this at first. It might read better was "The result from casting..."
+ * placeholder value to be wrapped in an em tag with a placeholder class.
Should the "em" here be capitalized? I'm not sure if there is a standard. Examples I checked around core are inconsistent.
Comment #42
nikitagupta CreditAttribution: nikitagupta at Srijan | A Material+ Company for Drupal India Association commentedComment #44
Abhijith S CreditAttribution: Abhijith S as a volunteer and at Zyxware Technologies commentedFixed the CS issue in patch #43.
142 | WARNING | Line exceeds 80 characters; contains 81 characters
Comment #49
smustgrave CreditAttribution: smustgrave at Mobomo commentedRunning 10.1 tests if they pass I'll mark RTBC.
Comment #50
smustgrave CreditAttribution: smustgrave at Mobomo commentedComment #51
longwaveUnfortunately the formatting needs a bit of work still:
These lines can be wrapped together.
Indentation is off here in the first line.
Indentation is off here.
Indentation is off here.
Comment #52
smustgrave CreditAttribution: smustgrave at Mobomo commentedEasy fixes
Comment #53
longwaveTwo more nits and a wider comment:
Blank line isn't needed here.
Indentation is still off here; the first two lines need to go back in by two spaces. Also it looks like this entire paragraph can be rewrapped at closer to 80 characters.
This is a bit repetitive of the section above that mentions the :variable format. Should we combine the two?
Comment #54
smustgrave CreditAttribution: smustgrave at Mobomo commentedNot the best technical writer. There a good tag to get some feedback on that?