[langsec-discuss] Enforcing validation layer with types

Meredith L. Patterson clonearmy at gmail.com
Tue Dec 18 01:52:37 UTC 2012

Hash: SHA256

No, this is great, actually -- it's a typesystem-side way to handle
tainting, and it plays nicely with both handrolled input handling and
inline DSLs. Sometimes your input language isn't large enough to need
a grammar stronger than a few regular expressions -- is the username
one or more non-control UTF-8 characters? is the zip code 5 digits? --
and if you can parse each input in a form with one regex per input, by
the principle of least power, you *should*. Returning Option[T] from
each parsing function clearly demarcates whether validation succeeded
(a la scala.util.parsing.combinator.Parsers.ParseResult's Success and
Failure/Error cases).

I can sort of see how this can be extended to non-Scala API design,
though a static typesystem definitely makes things easier. I'll have
to play with this some; conveniently, at work I'm in the middle of
refactoring a boundary of competence between user input and some
in-house C++.

- --mlp

On 12/17/2012 08:09 PM, Will Sargent wrote:
> I've been thinking about language security, and what causes
> problems for me personally when I'm trying to make sure I've
> enforced a security layer in code.
> One of the things that stood out for me is that I really don't
> like raw types: Strings / Ints / Dates etc don't have any semantic
> value assigned to them, and so you don't know if what you're
> accepting has been checked and validated as correct, or you're
> being passed a mickey.
> I did some research, and wrote up a blog post: 
> http://tersesystems.com/2012/12/16/problems-scala-fixes
> The relevant bit here is that Haskell's newtype system (and soon 
> Scala's value class in 2.10) makes it very easy to define types
> which say ValidString or PastDate as arguments, and so can't be
> passed input which hasn't been through a validator (which is not to
> say they can't be passed invalid input.
> I know this isn't the main thrust of Meredith's talk on context
> free grammars and the like, but I think it would be helpful if API 
> designers baked validation concerns right into the API itself.
> Will. _______________________________________________ 
> langsec-discuss mailing list langsec-discuss at lists.langsec.org 
> https://lists.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the langsec-discuss mailing list