Skip to content
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

fix(menu-item): Replace innerHTML of menu item to fix string bug on player #8793

Closed
wants to merge 6 commits into from

Conversation

CarlosVillasenor
Copy link
Contributor

@CarlosVillasenor CarlosVillasenor commented Jul 10, 2024

Description

Replace innerHTML of menu item to fix string bug on player.

Specific Changes proposed

With a condition using a regex replace innerHTML of menu item to fix string bug on player when content of the string contains HexCode.

Requirements Checklist

  • Feature implemented / Bug fixed
  • If necessary, more likely in a feature request than a bug fix
    • Change has been verified in an actual browser (Chrome, Firefox, IE)
    • Unit Tests updated or fixed
    • Docs/guides updated
    • Example created (starter template on JSBin)
    • Has no DOM changes which impact accessiblilty or trigger warnings (e.g. Chrome issues tab)
    • Has no changes to JSDoc which cause npm run docs:api to error
  • Reviewed by Two Core Contributors

Copy link

codecov bot commented Jul 10, 2024

Codecov Report

Attention: Patch coverage is 87.50000% with 1 line in your changes missing coverage. Please review.

Project coverage is 83.03%. Comparing base (51b4670) to head (c34934d).
Report is 2 commits behind head on main.

Files Patch % Lines
src/js/menu/menu-item.js 66.66% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #8793      +/-   ##
==========================================
- Coverage   83.75%   83.03%   -0.73%     
==========================================
  Files         120      120              
  Lines        8022     8034      +12     
  Branches     1925     1930       +5     
==========================================
- Hits         6719     6671      -48     
- Misses       1303     1363      +60     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -74,6 +74,15 @@ class MenuItem extends ClickableComponent {
textContent: this.localize(this.options_.label)
});

const containsHexCode = (s) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like a utility function that pertains to strings in particular so I'm wondering if it might be better to move it here.

Since we're proposing using innerHTML as part of this solution, and this function is essentially guarding that step, maybe it would be beneficial to add some tighter conditions to make it more difficult to use other problematic characters (i.e.: /'", etc) that are typically escaped for safety? We should also probably add a check for a semicolon ; as part of the regex test.

@mister-ben
Copy link
Contributor

Does the menu item label absolutely need to accept an HTML string? Using innerText doesn't seem ideal. Could this be introducing an xss vector, say if an HLS manifest had a captions track with a NAME attribute containing HTML? Can this be fixed closer to the source of the problem, by (re)encoding the string properly before it's passed to the component?

@CarlosVillasenor
Copy link
Contributor Author

CarlosVillasenor commented Jul 12, 2024

Does the menu item label absolutely need to accept an HTML string? Using innerText doesn't seem ideal. Could this be introducing an xss vector, say if an HLS manifest had a captions track with a NAME attribute containing HTML? Can this be fixed closer to the source of the problem, by (re)encoding the string properly before it's passed to the component?

HTML string

Does the menu item label absolutely need to accept an HTML string? Using innerText doesn't seem ideal. Could this be introducing an xss vector, say if an HLS manifest had a captions track with a NAME attribute containing HTML? Can this be fixed closer to the source of the problem, by (re)encoding the string properly before it's passed to the component?

In terms of security the regex that is used in the new function 'containsHexCode' was updated and will not accept any problematic characters only characters from specific ranges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants