[langsec-discuss] Enforcing validation layer with types

munin 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
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4827 bytes
Desc: not available
URL: <https://lists.langsec.org/pipermail/langsec-discuss/attachments/20121218/3e4ac429/attachment-0001.bin>

More information about the langsec-discuss mailing list