Releases: YahooArchive/express-state
Express State v1.0.2
This is a minor patch release, but if you're using Express State v1.0.0 you should upgrade to get the XSS protection added in v1.0.1.
This release officially made Express State a Modown component.
The object branding technique used by extend() was also updated to assign the module's export as the branded value. This makes it easier compare and determine which Express State module instance was used to extend the Express app.
Express State v1.0.1 — XSS Protection
This patch release adds XSS protection, everyone using Express State v1.0.0 should upgrade to v1.0.1.
The focus of this patch release was to add a basic level of XSS protection to prevent string values exposed through Express State's expose() method from being able to close and re-open <script> elements.
Attack Vector
The main way Express State is used is to embed the JavaScript it produces during serialization inside of an HTML <script> element; e.g., using Express State with Handlebars templates:
<script>{{{state}}}</script>Triple-mustaches are used so that Handlebars does not HTML-escape the JavaScript code that Express State's serialization process creates, if this code was HTML-escaped it would be invalid JavaScript and fail to run in the browser.
This left open a possible XSS attack vector where exposed string values could close and re-open a <script> element and therefore gain an execution context. The following shows how this could be done in versions of Express State prior to v1.0.1:
res.expose('";</script><script>alert("hey!");</script>', 'foo');It's not likely that a developer would purposely want to expose the "</script><script>" character sequence, but this attack vector could have been exploited by exposing untrusted user input which was not first HTML-escaped.
Note: We are not aware of any developers using Express State who've been exploited this way, we are taking a proactive approach to adding a basic level of XSS protected to Express State in the cases where untrusted user input is not properly HTML-escaped before it is exposed.
Change that Added XSS Protection
String values exposed via Express State's expose() method will now have their unsafe HTML characters: '<', '>', and '/' encoded to their Unicode values during the serialization process. The encoded characters will === the non-encoded characters so there's no worry of this messing up application code.
This provides a basic level of protection against XSS attacks by not allowing the "</script><script>" character sequence within an exposed string value to be interpreted and cause the browser prematurely close a script element and reopen a new one.
Even with this basic XSS protection, it's still important to always escape untrusted user input.
Untrusted User Input
Always escape untrusted user input to protected against XSS attacks!
Express State provides a mechanism to expose configuration and state data as first-party JavaScript, which means any untrusted user input should be properly escaped before it's passed to Express State's expose() method. See the OWASP HTML escaping recommendations.
Express State v1.0.0
Express State is now ready for primetime!
Over the last few months Express State has been in development and in use within Yahoo!. The API has solidified, bugs have been squashed, and documentation has been written — it's now ready to serve as a foundation on which app code and other libraries can be built.
Express State is designed to make it easy to share configuration and state data of an Express app from the server to the client. It can be used to share any data that needs to be available to the client-side JavaScript code of the an app; e.g., the current user, a CSRF token, model data, routes, etc.
Progressively enhanced web apps can be built by rendering an app's initial state on the server and using Express State as the conduit through which the server passes data and control over to the client-side JavaScript code.