XSS hardening #64
Merged
XSS hardening #64
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…criptive encoded value.
|
Thank you! Latest commits have integrated all of the changes from feedback. |
adafruit-adabot
added a commit
to adafruit/Adafruit_CircuitPython_Bundle
that referenced
this pull request
Aug 23, 2023
Updating https://github.com/adafruit/Adafruit_CircuitPython_HTTPServer to 4.3.0 from 4.2.0: > Merge pull request adafruit/Adafruit_CircuitPython_HTTPServer#64 from FoamyGuy/xss_hardening Updating https://github.com/adafruit/Adafruit_CircuitPython_Bundle/circuitpython_library_list.md to NA from NA: > Updated download stats for the libraries
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current server implementation and basic form_data example here: https://github.com/adafruit/Adafruit_CircuitPython_HTTPServer/blob/main/examples/httpserver_form_data.py are susceptible to XSS by submitting things like
<script>alert('xss');</script>to the input box which then gets reflected back onto the page returned in the response and executed by the client browser.By implementing this inside of FormData (super class) it means that by default user code will only have access to encoded values from the user rather than the actual raw values submitted. In some cases that might be problematic, for instance if the values aren't meant to be output within HTML, or if the intention is to allow the user to submit HTML content. In such cases the user could pass
Falseto disable the encoding and implement their own prevention measures.This PR does mitigate the risk with the provided example, however it is not all encompassing. There are still ways to write handlers and webpages that are vulnerable to other types of XSS like payloads injected into JS or CSS code instead of HTML. It might be good to ultimately add similar default prevention measures for JS and CSS contexts.
Another potential idea is to eventually add a section within the examples with clearly labeled and documented "Examples of what NOT to do" that illustrate the insecurely implemented handlers and explain what risks they pose.
@michalpokusa I'm curious if you have any thoughts or ideas around this or any other potential "guardrails" against XSS within the server.