Bug #50929
closed
Don't call rawurlencode() twice on curUrl
Added by Jan Spisiak over 11 years ago.
Updated about 11 years ago.
Description
In ElementBrowser.php:
$this->setTitle = $this->curUrlArray['title'] != '-' ? rawurlencode($this->curUrlArray['title']) : '';
...
$JScode = '
...
var add_title="' . ($this->setTitle ? '&curUrl[title]=' . rawurlencode($this->setTitle) : '') . '";
...
';
This is for all curUrl attributes. In the end this means that javascript variables are encoded twice and the prefilled form is also encoded even if it shouldn't be.
I've included patch, but I am not sure if it satisfies all the rules.
Files
This double encoding was introduced in a security fix in 2011.
http://review.typo3.org/3754
I believe this fix was wrong, since it should protect against XSS. Double encoding of course does the trick, but it would IMHO be better to simply htmlspecialchar the output.
Yes, that is the fix that broke it. Well the output into the form is already htmlspecialchar'ed:
<td><input type="text" name="ltitle" class="typo3-link-input" onchange="browse_links_setTitle(this.value);" value="' . htmlspecialchars($this->setTitle) . '" /></td>
But there is also the cur_* variables:
var cur_title="' . ($this->setTitle ? $this->setTitle : '') . '";
These are not rendered, they are just sent through
renderPopup_addLink() back to editor, so should they also be htmlspecialchar'ed ?
- Assignee set to Georg Ringer
- Target version changed from 2463 to next-patchlevel
This needs to be fixed, otherwise it renders editing links impossible when using ElementBrowser (Flux uses it).
please never assign any issues to someone else then yourself!
- Target version deleted (
next-patchlevel)
- Is Regression changed from No to Yes
- Status changed from New to Accepted
- Status changed from Accepted to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by