search

illuminated-g / lv-http-server

HTTP Server implementation in LabVIEW. Utilizes IG TCP Streams and provides mechanisms akin to Web Services.
MIT License
9 stars 0 forks source link

Investigate XSS and injection possibilities in all core components. (Brainstorming) #2

Open negentropicdev opened 2 years ago

negentropicdev commented 2 years ago

Everything from the start of the Process Async.vi to the end of processing will need to provide assurances that injection attacks are protected against for all included components. We can only provide meaningful assurances of included components as user code can of course inadvertently leak or persist data across requests and sessions. For these cases documentation and tooling to allow developers to protect their applications as much as possible will be necessary. This includes best practices, bad practices, escaping routines, and any request-scoped checks that can be performed for reasonable Request formats and Response headers.

One of the biggest vulnerabilities that is purposefully included is debugging mode. If possible, it would be nice to have some mechanism that can ignore debug mode without some form of user interaction. Current debugging mode responses will typically include values from the request such as appending paths to web root folders on disk. Modern browsers are good at protecting against this kind of attack but this cannot be relied on when possible.

e.g. generating a link of "http://testsite.test/" may cause the script portion of the supplied URL in insecure clients to be sent to the server unescaped and server error reporting may "reflect" that content back in the page content of an error response, triggering untrusted javascript execution. Chrome URL encodes special characters but I'm sure there are clients out there that don't behave that well, particularly improperly implemented custom applications utilizing HTTP exchanges.

One easy solution to some of these vulnerabilities is to avoid having any core components that can persist state across requests that isn't regenerated based on validated request content. If any caching gets implemented to increase performance, these mechanisms will need to be investigated for possible attack vectors. User code will be free to utilize reference based mechanisms in their controllers, handlers, and services so the best we can do there is dissuade the practices, educate the developers, and make it as easy as possible to do things in a more secure manner.

This issue will be left open long term to collect thoughts and discussion on injection attack vectors unless moved elsewhere.

negentropicdev commented 2 years ago

https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Provides many details on escaping untrusted content that goes into documents and includes source locations where untrusted content should never be allowed or specific locations where minimum rules must be followed.

negentropicdev commented 2 years ago

For an example of making it as easy as possible for the user, serialization libraries should be brought in, particularly for turning LV values into JSON. This can be BlueOrigin's serialization libs that have been published on VIPM but I'm more likely to update my own existing libraries. Will need to do some benchmarking of the various JSON libraries against each other.

All appropriate encoding routines should be available with clear documentation on where they should be used. HTML encoding, URL encoding (already exists in LV), JavaScript encoding, & CSS encoding.

Down the road another useful toolkit would be for sanitizing routines such as limiting untrusted html content to specific attributes and specific tags.