ER: Potential XSS Vulnerability in wins.js

[jaasonw]

Emergent Requirement - Problem

I originally submitted this as a security advisory, but @roslynwythe said there isn't a way to convert it to an issue so I'm reposting it here

Original text:

Summary

The usage of innerHTML to dynamically modify DOM elements in wins.js may introduce a vulnerability to Cross-Site Scripting (XSS) attacks if wins-data.json is compromised, not properly sanitized, or not adequately vetted.

Details

The vulnerability exists on the following lines of code where DOM elements are dynamically modified using external data.

https://github.com/hackforla/website/blob/gh-pages/assets/js/wins.js#L339
https://github.com/hackforla/website/blob/gh-pages/assets/js/wins.js#L340
https://github.com/hackforla/website/blob/gh-pages/assets/js/wins.js#L498
https://github.com/hackforla/website/blob/gh-pages/assets/js/wins.js#L501
https://github.com/hackforla/website/blob/gh-pages/assets/js/wins.js#L504

To address this vulnerability, it is recommended to avoid using innerHTML and prefer safer DOM manipulation methods like createElement and textContent

Additionally, the unformatted nature of wins-data.json can make it difficult to spot changes in the file with a git diff. Consider reformatting the JSON file to be more human-readable and version control-friendly.

PoC

The vulnerability audit states that "User input strings remain strings and escape injection through decodeURIComponent()" however, in my testing this is not the case and strings parsed through decodeURIComponent() are still susceptible to XSS.
Proof of concept: https://codepen.io/jaasonw/pen/GRPBzGJ

Impact

Potential defacement of the website or visitors being subject to phishing attacks.

Issue you discovered this emergent requirement in

• Originally discovered while reviewing Update wins.html file to use liquid in this file #5258, however it was not introduced by that PR

Date discovered

10/1/2023

Did you have to do something temporarily

• YES
• NO

Who was involved

@

What happens if this is not addressed

Potential defacement of the website or visitors being subject to phishing attacks.

Resources

https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement
https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent
https://medium.com/front-end-weekly/javascript-innerhtml-innertext-and-textcontent-b75ec895cbe3
https://jekyllrb.com/docs/datafiles/

Recommended Action Items

• Make a new issue
• Discuss with team
• Let a Team Lead know

Potential solutions [draft]

option 1

Update code that does DOM manipulation. Instead of using innerHTML, we should update the code to use safer DOM manipulation methods like createElement and textContent

option 2
Alternatively, I noticed a lot of the data on the website is loaded in on page load with javascript rather than at build time. Seeing as we already use Jekyll, I suggest using its built-in functionality with the strip_html filter to load data into the HTML at build time statically, as this has benefits to both page load times and accessibility benefits to visitors to the site that have javascript disabled

[github-actions]

Hi @jaasonw.

Please don't forget to add the proper labels to this issue. Currently, the labels for the following are missing:
Complexity, Role, Feature

NOTE: Please ignore the adding proper labels comment if you do not have 'write' access to this directory.

To add a label, take a look at Github's documentation here.

Also, don't forget to remove the "missing labels" afterwards.
To remove a label, the process is similar to adding a label, but you select a currently added label to remove it.

After the proper labels are added, the merge team will review the issue and add a "Ready for Prioritization" label once it is ready for prioritization.

Additional Resources:

• Wiki: How to create issues
• Wiki: How to read and interpret labels

[roslynwythe]

• Great work @jaasonw pointing out several excellent suggestions. Regarding the XSS vulnerability, would you be willing to write an issue to update wins.js? Regarding the formatting of _wins-data.json, I agree completely and have written Update wins Google Apps Script to format wins json feed #4035 for that purpose. If you have any comments on that issue, they would be welcome.

Finally regarding your suggestion to load wins data at build time rather than on page load, I will discuss that with Bonnie to see if she is interested in pursuing that. Thanks again for your contributions; we are very happy that you are on the website team!