4 ms·

Shameless self-promotion, but anyone reading this who is just getting into front-end and doesn't want to deal with that ^, check out Joystick [1]. It's a full-

Shameless self-promotion, but anyone reading this who is just getting into front-end and doesn't want to deal with that ^, check out Joystick [1]. It's a full-stack JS framework with its own components library that uses plain HTML, CSS, and JS (and has dead-simple, obvious APIs for implementing more advanced logic like state and event handlers). It's a logical next step from learning web dev fundamentals to building full apps. [1] https://cheatcode.co/joystick https://cheatcode.co/joystick

chrismorgan 2y ago
Judging by your front page demo, your component stack is built on simple string concatenation (via untagged template strings), with nothing about escaping of any form, for any format. That's a very bad sign, you're just begging for injection attacks. There's absolutely no chance of me using a framework with a demo like that, even if it actually had decent tools for handling the situation.
- rglover 2y ago
  That's all mitigated on the server. You also have access to additional escaping tools for handling user-generated data on the server, too.
  - chrismorgan 2y ago
    > That's all mitigated on the server. How? Please be specific, because unless you're altering the source (which I'd be very unpleasantly shocked by), your use of untagged template strings makes it fundamentally impossible to mitigate such stuff, short of forbidding characters like & and < and " from data, which would be insanity. You're mixing template and data willy-nilly.
    - rglover 2y ago
      The source isn't altered (I take the component HTML, parse it, build it into a DOM, and render it). The data from the API is compiled separately (where sanitization can happen if you have untrusted user data). The two are combined together during SSR by passing the sanitized data to the component. Developer controlled code at the component-level is assumed trusted, however, there are three mechanisms for handling escaping/sanitizing on the server: 1. There are helpers built in to the API (you can conditionally enable sanitization depending on need) to handle sanitization and helper functions built-in to the server-side to do one-off escaping/sanitization for HTML. 2. Query params are sanitized automatically to prevent injection. 3. To prevent unescaped HTML in data from breaking renders, I base64 encode it before sending it to the browser. This approach to escaping is by design as some use cases call for sanitization (they're rendering user-generated data) while others do not. You're welcome to audit the source and see if I missed something or make suggestions on improvements.
      - chrismorgan 2y ago
        I wrote something much longer and more detailed, but I haven’t the heart to post it in the end. This is a phenomenally bad idea. By escaping things willy-nilly you’re making life much harder, and vastly more error-prone. You can only even vaguely sanely do such things with the support of a better type system than you have available to you. You’re encouraging storing escaped HTML in the database; exposing an API that HTML-encodes all strings; you’re misusing the term “sanitise” (sanitising is fairly consistently used to mean stripping control sequences, not escaping). This is a disaster. Given that you’re working in JavaScript, you need to use something like JSX or equivalent functions or tagged template strings, so you can escape only as appropriate. As it stands, I would genuinely expect to be able to find trivial functionality and/or security bugs in practically every decent-sized Joystick site involving user input. One specific technical bug: https://github.com/cheatcode/joystick/blob/canary/node/src/lib/escape_html.js https://github.com/cheatcode/joystick/blob/canary/node/src/l... tries to escape &<>"'`= but will replace backticks and equals signs with “undefined”. Defining HTML_ENTITY_MAP in a separate file was a mistake; you’ll hopefully never refer to it anywhere else, and separating it made such an error easier to make. (Incidentally, backtick and equals sign have never been useful things to escape in HTML. Truthfully, & and < are all you need in HTML text, and & and " in double-quoted attribute value. If you want to support XML, then escape < and > everywhere as well. But nothing beyond that is useful.)
        rglover 2y ago
        I updated the escape_html() method to cover the missing characters/cases and centralized the entity map to the function definition. Appreciate you pointing that out. I went beyond what you suggested in terms of characters which should cover most (if not all) problem cases. Here's an example repo: https://github.com/cheatcode/escape_test https://github.com/cheatcode/escape_test And example text I used to test: https://gist.github.com/rglover/c75e37b526d864313b461d38195b6970 https://gist.github.com/rglover/c75e37b526d864313b461d38195b... > You’re encouraging storing escaped HTML in the database You can store unescaped HTML in the database and upon retrieval, escape it (see the linked demo repo above). You hypothetically could store escaped HTML, but you'd have to show me where I'm encouraging it (I think what you're saying is that because you can do it, I'm encouraging it). > As it stands, I would genuinely expect to be able to find trivial functionality and/or security bugs in practically every decent-sized Joystick site involving user input. You're welcome to audit it, but please, actually test it by building something and then provide an example repo. Make sure to use the canary release as that has the latest changes. If you email me (ryan.glover@cheatcode.co) I can give specifics on how to get set up. --- FWIW, this isn't a productive way to point out issues with a project. A PR with comments is preferred.
Eric_WVGG 2y ago
port 2600 huh ;)
- rglover 2y ago
  Yes! You're the first person to catch that. Check out the test port.

chrismorgan 2y ago

Judging by your front page demo, your component stack is built on simple string concatenation (via untagged template strings), with nothing about escaping of any form, for any format. That's a very bad sign, you're just begging for injection attacks. There's absolutely no chance of me using a framework with a demo like that, even if it actually had decent tools for handling the situation.

rglover 2y ago
That's all mitigated on the server. You also have access to additional escaping tools for handling user-generated data on the server, too.
- chrismorgan 2y ago
  > That's all mitigated on the server. How? Please be specific, because unless you're altering the source (which I'd be very unpleasantly shocked by), your use of untagged template strings makes it fundamentally impossible to mitigate such stuff, short of forbidding characters like & and < and " from data, which would be insanity. You're mixing template and data willy-nilly.
  - rglover 2y ago
    The source isn't altered (I take the component HTML, parse it, build it into a DOM, and render it). The data from the API is compiled separately (where sanitization can happen if you have untrusted user data). The two are combined together during SSR by passing the sanitized data to the component. Developer controlled code at the component-level is assumed trusted, however, there are three mechanisms for handling escaping/sanitizing on the server: 1. There are helpers built in to the API (you can conditionally enable sanitization depending on need) to handle sanitization and helper functions built-in to the server-side to do one-off escaping/sanitization for HTML. 2. Query params are sanitized automatically to prevent injection. 3. To prevent unescaped HTML in data from breaking renders, I base64 encode it before sending it to the browser. This approach to escaping is by design as some use cases call for sanitization (they're rendering user-generated data) while others do not. You're welcome to audit the source and see if I missed something or make suggestions on improvements.
    - chrismorgan 2y ago
      I wrote something much longer and more detailed, but I haven’t the heart to post it in the end. This is a phenomenally bad idea. By escaping things willy-nilly you’re making life much harder, and vastly more error-prone. You can only even vaguely sanely do such things with the support of a better type system than you have available to you. You’re encouraging storing escaped HTML in the database; exposing an API that HTML-encodes all strings; you’re misusing the term “sanitise” (sanitising is fairly consistently used to mean stripping control sequences, not escaping). This is a disaster. Given that you’re working in JavaScript, you need to use something like JSX or equivalent functions or tagged template strings, so you can escape only as appropriate. As it stands, I would genuinely expect to be able to find trivial functionality and/or security bugs in practically every decent-sized Joystick site involving user input. One specific technical bug: https://github.com/cheatcode/joystick/blob/canary/node/src/lib/escape_html.js https://github.com/cheatcode/joystick/blob/canary/node/src/l... tries to escape &<>"'`= but will replace backticks and equals signs with “undefined”. Defining HTML_ENTITY_MAP in a separate file was a mistake; you’ll hopefully never refer to it anywhere else, and separating it made such an error easier to make. (Incidentally, backtick and equals sign have never been useful things to escape in HTML. Truthfully, & and < are all you need in HTML text, and & and " in double-quoted attribute value. If you want to support XML, then escape < and > everywhere as well. But nothing beyond that is useful.)
      - rglover 2y ago
        I updated the escape_html() method to cover the missing characters/cases and centralized the entity map to the function definition. Appreciate you pointing that out. I went beyond what you suggested in terms of characters which should cover most (if not all) problem cases. Here's an example repo: https://github.com/cheatcode/escape_test https://github.com/cheatcode/escape_test And example text I used to test: https://gist.github.com/rglover/c75e37b526d864313b461d38195b6970 https://gist.github.com/rglover/c75e37b526d864313b461d38195b... > You’re encouraging storing escaped HTML in the database You can store unescaped HTML in the database and upon retrieval, escape it (see the linked demo repo above). You hypothetically could store escaped HTML, but you'd have to show me where I'm encouraging it (I think what you're saying is that because you can do it, I'm encouraging it). > As it stands, I would genuinely expect to be able to find trivial functionality and/or security bugs in practically every decent-sized Joystick site involving user input. You're welcome to audit it, but please, actually test it by building something and then provide an example repo. Make sure to use the canary release as that has the latest changes. If you email me (ryan.glover@cheatcode.co) I can give specifics on how to get set up. --- FWIW, this isn't a productive way to point out issues with a project. A PR with comments is preferred.

Eric_WVGG 2y ago

port 2600 huh ;)

rglover 2y ago
Yes! You're the first person to catch that. Check out the test port.