#3411 closed Enhancement (fixed)
output/url should assume 'value' parameter means "untrusted data"
| Reported by: | ewinslow | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Elgg 1.8.1b |
| Component: | UI/UX | Version: | 1.7 |
| Severity: | minor | Keywords: | |
| Cc: | brett@… | Difficulty: | easy |
Description
I'd like to see output/url be more secure by default when the 'value' parameter is used to pass in the url (paralleling the other output/* views). 2 specifics:
- Automatically run it through filter_tags to combat XSS.
- Automatically add rel=nofollow to combat spam.
Use of 'href' can then indicate "trusted" content and no filter_tags or rel=nofollow would be added by default.
Change History (13)
comment:1 Changed 2 years ago by cash
comment:2 Changed 2 years ago by ewinslow
Indeed -- I suspected this might be a concern.
The reason I still recommend this approach is because we have things like the group profile hooks. If you say 'website' => 'url', then Elgg is going to look for input/url to take the input and pass the output to output/url as the 'value' parameter.
Basically what I'm saying is that it's just convention that the 'value' parameter passed to any output/* view should be considered untrusted.
comment:3 Changed 2 years ago by cash
Why don't we make everything passed to output/url be untrusted unless an explicit flag is passed to say that it should be trusted.
comment:4 Changed 2 years ago by ewinslow
To put it crassly: passing 2 options is a hassle. I guess we just have to strike a balance b/w intuitiveness and convenience. I find value/href distinction sufficiently intuitive because of parallelism with input/url and other output/* views, but I can see how others may not agree.
comment:5 Changed 2 years ago by cash
We have already established a pattern of passing in booleans to say something is an action, to turn off encoding, to turn off security (for forms I think). It seems like it follows a pattern and involves less magic.
comment:6 Changed 2 years ago by brettp
I prefer passing a flag instead of changing the name of the option.
comment:7 Changed 2 years ago by ewinslow
Fair points. How do we deal with menu items? Do we make those trusted by default? I'd hate to shut down a site's crawlability with our choice of defaults.
comment:8 Changed 2 years ago by cash
Yes, menu items would be trusted by default (and I think those are the vast majority of non-user created links).
comment:9 Changed 2 years ago by ewinslow
sgtm
comment:10 Changed 2 years ago by cash
- Component changed from Core to UI/UX
- Difficulty set to easy
- Milestone changed from Needs Review to Elgg 1.8.1
I'll put at 1.8.1 but if someone has time/interest, we can sneak it into 1.8.0.
comment:11 Changed 20 months ago by Cash Costello
- Resolution set to fixed
- Status changed from new to closed
Fixes #3411 output/url now has a is_trusted parameter - defaults to false
Changeset: d5f0d44d4ddf33db2248ef0bdd44633d57c31683
comment:12 Changed 20 months ago by brettp
- Milestone changed from Elgg 1.8.1 to Elgg 1.8.1b
comment:13 Changed 19 months ago by Cash Costello
Fixes #3411 output/url now has a is_trusted parameter - defaults to false
Changeset: d5f0d44d4ddf33db2248ef0bdd44633d57c31683

Not a fan of value vs href. There is nothing that tells me one should be trusted or untrusted. I would favor an explicit flag (filter?, trusted?) if we did this.