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 False to 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.
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
False
to 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.