5 ms·

Looks like an improvement over JSON.

by ape4 10y ago

rurban 10y ago
No, of course not. It makes this kind of JSON insecure and slow. You can use YAML for this kind of stuff already, and it's still more readable than STON.
- scott_s 10y ago
  Why is STON less secure than JSON?
  - nonsince 10y ago
    Because you can write arbitrary classes in the output, which can then be called (since dispatch is dynamic, and the output object is assumably either untyped or typed as the equivalent of `Object`). If you know which classes are available you can arbitrarily choose one as an attacker. JSON is data only, no functionality.
    - rurban 10y ago
      I wrote this: http://search.cpan.org/~rurban/Cpanel-JSON-XS/XS.pm#SECURITY_CONSIDERATIONS http://search.cpan.org/~rurban/Cpanel-JSON-XS/XS.pm#SECURITY... One of the relevant object serializer exploits was CVE-2015-1592
    - dragonwriter 10y ago
      That doesn't make the format insecure, it means it is possible to write an insecure deserializer (which is possible for any format); it's also possible to write a secure deserializer, or one that can be configured based on use-case to balance exposed functionality vs. security appropriately for the use case. One-size-fits-all security-through-lack-of-functionality is not necessarily the ideal approach for all data transfer applications.
      - sebastianconcpt 10y ago
        security-through-lack-of-functionality <- Excellent point! One should decide where the load of security should be paid.
      - nonsince 10y ago
        But you need constant vigilance to keep the deserialiser secure. In JSON, any change to the deserialiser requires checking for security holes and DoS attacks. With this, you also need to check every method in every class in the set of possible deserialisation targets. If you don't have any methods and it's all just pure data (which would ensure equal security to JSON), then why are you using this instead of JSON. It is _absolutely_ security through lack of functionality. You simply grant less powers to untrusted inputs, as well you should. If you're designing a programming language intended to be written by hostile actors, you would not include primitives for opening files, running applications or spinning infinite loops, since they are all security issues. That's security through restriction of functionality. JSON is trivially secure, this is not. You need to maintain its security.
- collyw 10y ago
  I am trying to set up deploy script using Ansible just now - which uses YAML. Its more readable in one sense, but indentation gets a bit confusing when you are not especially familiar with it. JSON is more obvious in that respect. I wish we could have Python dictionaries as an alternative to JSON, as large JSON configuration files are horrible, when you add an extra trailing comma or things get too nested.
  - rjeli 10y ago
    I really like TOML: https://github.com/toml-lang/toml https://github.com/toml-lang/toml

Looks like an improvement over JSON.

by ape4 10y ago

Looks like an improvement over JSON.

No, of course not. It makes this kind of JSON insecure and slow. You can use YAML for this kind of stuff already, and it's still more readable than STON.

scott_s 10y ago
Why is STON less secure than JSON?
- nonsince 10y ago
  Because you can write arbitrary classes in the output, which can then be called (since dispatch is dynamic, and the output object is assumably either untyped or typed as the equivalent of `Object`). If you know which classes are available you can arbitrarily choose one as an attacker. JSON is data only, no functionality.
  - rurban 10y ago
    I wrote this: http://search.cpan.org/~rurban/Cpanel-JSON-XS/XS.pm#SECURITY_CONSIDERATIONS http://search.cpan.org/~rurban/Cpanel-JSON-XS/XS.pm#SECURITY... One of the relevant object serializer exploits was CVE-2015-1592
  - dragonwriter 10y ago
    That doesn't make the format insecure, it means it is possible to write an insecure deserializer (which is possible for any format); it's also possible to write a secure deserializer, or one that can be configured based on use-case to balance exposed functionality vs. security appropriately for the use case. One-size-fits-all security-through-lack-of-functionality is not necessarily the ideal approach for all data transfer applications.
    - sebastianconcpt 10y ago
      security-through-lack-of-functionality <- Excellent point! One should decide where the load of security should be paid.
    - nonsince 10y ago
      But you need constant vigilance to keep the deserialiser secure. In JSON, any change to the deserialiser requires checking for security holes and DoS attacks. With this, you also need to check every method in every class in the set of possible deserialisation targets. If you don't have any methods and it's all just pure data (which would ensure equal security to JSON), then why are you using this instead of JSON. It is _absolutely_ security through lack of functionality. You simply grant less powers to untrusted inputs, as well you should. If you're designing a programming language intended to be written by hostile actors, you would not include primitives for opening files, running applications or spinning infinite loops, since they are all security issues. That's security through restriction of functionality. JSON is trivially secure, this is not. You need to maintain its security.
collyw 10y ago
I am trying to set up deploy script using Ansible just now - which uses YAML. Its more readable in one sense, but indentation gets a bit confusing when you are not especially familiar with it. JSON is more obvious in that respect. I wish we could have Python dictionaries as an alternative to JSON, as large JSON configuration files are horrible, when you add an extra trailing comma or things get too nested.
- rjeli 10y ago
  I really like TOML: https://github.com/toml-lang/toml https://github.com/toml-lang/toml