3 ms·
It's not just about the language or tools you use. You can produce a memory-safe, beautifully structured parser and use whatever framework you like, but if it d
by nly 9y ago
It's not just about the language or tools you use. You can produce a memory-safe, beautifully structured parser and use whatever framework you like, but if it doesn't do full recognition of your input before you do any processing then you're likely boned.
Not only is there a high risk that you'll still be passing bad input through to your database, another program, or an unsafe library deep down in your application (YAML in Ruby anyone?), but you get what Meredith Patterson calls a "weird machine" that is programmable by an attacker.
There's a lot more of this at:
http://langsec.org/ http://langsec.org/
Stacks of papers, articles, videos, examples etc.
- CarolineW 9y ago> ... if it doesn't do full recognition of your input before you do any processing then you're likely boned. There are languages where you need to process some of what you've done before a later part of the source can be dis-ambiguated. How does that sit with what you've said here?
- cyphar 9y agoThe argument that langsec.org makes is that any such languages are missing security properties. In fact they regard most ad-hoc languages as insecure due to the lack of verification, which they believe to be the root cause of many security problems.