Jeffrey Goldberg <jeff...@goldmark.org> writes: > Hello, > > I work for a company that produces a consumer product for a number of > different operating systems and environments as well as running a web service > (written in Go). Although I’ve been telling people to not use ad-hoc parsers > and adding a new regex each time someone discovers a bug, it would be much > much easier to persuade/force developers to do things right if I can actually > offer them something concrete.
I sincerely doubt that security sells well in the consumer space. Think about Windows, Android/Linux and the new internet of exploitable things. Or, for a more specific example, just consider the „crypto messengers” that pop up left and right. Almost all of them have usability flaws, are not interoperable and can not exactly be called “secure”. Interoperable alternatives exist (mainly XMPP+OTR), but they are not marketed well. I would appreciate if you would go into details about the product or even show the code of a “typical” vulnerability that occured there. > Our needs are (mostly) textual. So we don’t need things like Hammer or Nail. > I’m really old and so I think of lex/yacc (or perhaps flex/bison), but I am > hoping for things that might be better suited to simple deterministic Context > Free Grammars. And I would make our developers happier (i.e., more willing to > comply) if the parser-generators produce code that they can link and use > easily. What are your needs specifically? > So what I need is help from the langsec community in selling doing things the > right way among the developers where I work. Me talking abstractly about > “write a grammar, generate a parser from that grammar, and validate with that > parser before doing anything else” would go much better if I could actually > show people how to do that and how it will make things easier for them. Also > me saying “I told you so” with every new input validation bug, is getting > tiresome. You should not validate inputs but outputs. Think about it: If you print a string in an XML or HTML document, it needs to be escaped differently than if you use it in an SQL statement or display it in a PDF document. > So I would like to write a grammar (of, say, the subset of RFC2822 email > addresses that we want to accept) once and offer a practical way to get from > that grammar to a validator for languages and development environments > including Go, JavaScript/TypeScript, C#, Objective-C, and (perhaps) Delphi. There exists an easy way to check if an email address is valid: Check if it contains at least one @ sign, then verify if DNS gives you MX record. I think it might be possible to ask the SMTP server if usernames exists. > Go and JavaScript/Typescript would be the big sell. I realize that for some > environments we might just have to build from C and link from that. Anything where you can have different types for textual content that is of a different language (like HTML and plain text) might catch the most obvious errors. See example from Chris Double with Rust phantom types: <http://bluishcoder.co.nz/2013/08/15/phantom_types_in_rust.html> > So what are the parser-generators y’all actually recommend to > developers that they can easily and practically use? I honestly have no idea. > Cheers, > > Jeffrey Goldberg > > > > > _______________________________________________ > langsec-discuss mailing list > langsec-discuss@mail.langsec.org > https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
pgpnQPgRO6B8i.pgp
Description: PGP signature
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
