logoalt Hacker News

kstrausertoday at 1:27 AM1 replyview on HN

Maybe one showing that the change doesn't make it worse. Here's the code change:

  - <a class="item muted sidebar-item-link" href=${$(this).data('href')}>
  + <a class="item muted sidebar-item-link" href="${$(this).data('href')}">
I know zero about this code path, but suppose it's expected that `${$(this).data('href')}` is already a properly quoted value, like `"https://example.com"`. Then the first line expands to:

  <a class="item muted sidebar-item-link" href="https://example.com">
and the second expands to:

  <a class="item muted sidebar-item-link" href=""https://example.com"">
which would have all kinds of room for mischief. Or suppose the template engine auto-quotes values that it injects, so the quotes aren't necessary at all, which is a pretty common approach. The point is that you don't randomly want to throw quotes into HTML or single quotes into SQL just for giggles. You have to write tests demonstrating that the existing common use cases still work after the change, even if it's simply adding 4 quotes.

Replies

MajesticHobo2today at 1:36 AM

I'd say also add a test that shows the HTML injection (which spurred the PR) isn't possible. Given an attacker-controlled URL of:

    foo onclick
the following shouldn't render:

    <a class="item muted sidebar-item-link" href=foo onclick>
The following should:

    <a class="item muted sidebar-item-link" href="foo onclick">
show 1 reply