[langsec-discuss] Enforcing validation layer with types
munin at mimisbrunnr.net
Tue Dec 18 06:18:46 UTC 2012
I found FP after doing systems programming for many years. This semester I went back into doing a lot of C systems programming and greatly missed the type system of a strong, statically typed functional language!
I don't do any web programming or untrusted input processing in ocaml, but it seems like you could naturally express a thought like this by having a separate type for any input data, and then a separate type for any trusted function input. The type system wouldn't let you directly source data through, so you would essentially have:
type input_type = Untrusted_Input of string
type output_type = Trusted_Output of string
val sanitize : input_type -> output_type
val from_web : unit -> input_type
val to_database : output_type -> unit
this seems pretty similar?
a lot of ocaml apis avoid the "blind string" and "blind int" and the language seems to make it easy to provide rich semantic meaning to types. I don't do any web programming though …
On Dec 17, 2012, at 8: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
> I did some research, and wrote up a blog post:
> 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.
> langsec-discuss mailing list
> langsec-discuss at lists.langsec.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4827 bytes
Desc: not available
More information about the langsec-discuss