3 ms·

Array.isArray isn't needed when you know your array isn't going to be deserialized e.g. via MessagePort. What other supposed bugs? And yes I'm aware this doesn

Array.isArray isn't needed when you know your array isn't going to be deserialized e.g. via MessagePort. What other supposed bugs? And yes I'm aware this doesn't have a huge API surface. That's the whole point. If I already have a JSON object, I can reach into it and get either what I ask for or nothing. In many real world cases, this is enough.

rafram 1y ago
let someArray = [1, 2, , 4]; console.log(as.numbers(someArray) === someArray); // => true for (let number of numbers) { // This should be safe because I know everything in the array is a number, right? console.log(number.toFixed(2)); // => TypeError: number is undefined } I mean, it's probably fine if you're only ever getting your data from JSON.parse(). But I would hesitate to use this in production.
- 90s_dev 1y ago
  The point is that it's layered. 1. Validate your Buffer/UInt8Array for valid size/encoding/etc first 2. Parse it to an object via JSON.parse or whatever your use-case needs 3. Reach into it with this function to get data if it matches the type you need This code only deals with #3 and makes a few assumptions about #2 (e.g. no undefined, typical JSON-like object, etc).
- Dylan16807 1y ago
  > I mean, it's probably fine if you're only ever getting your data from JSON.parse(). So 90% of use cases?
  - rafram 1y ago
    Sure, and then only 10% of your use cases contain easily exploitable vulnerabilities.
    - Dylan16807 1y ago
      You use a different function than Validate_Parsed_JSON in those cases. But most typescript programs are only going to need JSON-compatible input. Maybe some XML but that's also going to have similar formulaic output from your parser. If something can directly hand you a maliciously built data structure, you're probably designing your system wrong. Are you running untrusted javascript in the same interpreter? That's a very hard problem that should be avoided if at all possible. Basically, only working on JSON.parse is something to document but it's not at all a weird restriction, or a reason to balk at putting it into production.

rafram 1y ago

let someArray = [1, 2, , 4]; console.log(as.numbers(someArray) === someArray); // => true for (let number of numbers) { // This should be safe because I know everything in the array is a number, right? console.log(number.toFixed(2)); // => TypeError: number is undefined } I mean, it's probably fine if you're only ever getting your data from JSON.parse(). But I would hesitate to use this in production.

90s_dev 1y ago
The point is that it's layered. 1. Validate your Buffer/UInt8Array for valid size/encoding/etc first 2. Parse it to an object via JSON.parse or whatever your use-case needs 3. Reach into it with this function to get data if it matches the type you need This code only deals with #3 and makes a few assumptions about #2 (e.g. no undefined, typical JSON-like object, etc).
Dylan16807 1y ago
> I mean, it's probably fine if you're only ever getting your data from JSON.parse(). So 90% of use cases?
- rafram 1y ago
  Sure, and then only 10% of your use cases contain easily exploitable vulnerabilities.
  - Dylan16807 1y ago
    You use a different function than Validate_Parsed_JSON in those cases. But most typescript programs are only going to need JSON-compatible input. Maybe some XML but that's also going to have similar formulaic output from your parser. If something can directly hand you a maliciously built data structure, you're probably designing your system wrong. Are you running untrusted javascript in the same interpreter? That's a very hard problem that should be avoided if at all possible. Basically, only working on JSON.parse is something to document but it's not at all a weird restriction, or a reason to balk at putting it into production.