[dmix]

> it means you should never assume that user data is safe, or even sane

I'm curious if Haskell's purity helps developers focus on this issue and therefore makes it easier to mitigate. Given that all user input/state already has to be handled carefully (for ex: with monads). It will be obvious in the codebase which parts need to be zero'd in on for possible attack vectors.

[sitharus]

Haskell's web frameworks help, but it's nothing to do with purity. In fact any web framework can do this, you segregate user-supplied data and ensure it can never be supplied to an untrusted function without explicit cleaning.

Perl and Ruby have included this as a 'tainted' flag, many functions cannot be called with a tainted string.

[MustardTiger]

>I'm curious if Haskell's purity helps developers focus on this issue and therefore makes it easier to mitigate

No, haskell's type system does, not its purity.

>Given that all user input/state already has to be handled carefully (for ex: with monads)

What? Monads are not some mythical beast, there is nothing "handled carefully" about it. A monad is just a general interface.

[dmix]

I'm talking about clear separation of state via Monads making it easier to focus on the riskier input. For example when you are doing code reviews. That is about the developer nothing to do with some inherent functionality of Monads. Not sure what it being a "general interface" has to do with that. Maybe I wasn't clear.

[MustardTiger]

>Not sure what it being a "general interface" has to do with that

I was explaining what monads are. You have read some of the weird misconceptions about haskell and monads and are now repeating them.

[dmix]

How does purity not help the developer focus in on areas where user input might have a negative affect the codebase or system?

I used monads only as an example (in brackets) but it's hardly the only form where purity creates clear divisions in the codebase. So, once again, the specific functionality of monads has nothing to do with it. I'm speaking about the coding style that Haskell promotes making detecting bugs easier during code reviews.

Having done security reviews of code I would have loved to have that type of distinction exist in a codebase compared to the usual OOP mess (with PHP or Ruby for example, which is typically the only paid work available in infosec) where state/user input is leaking all over the place. Compared to clearly defined paths containing IO - which are separated from pure functions which don't have unexpected side effects and require far less scrutiny.

I'm answering my own question here but I was hoping someone who has more experience than me at conducting security-centric code reviews would chime in to provide their perspective.

[MustardTiger]

I don't know how to be any more clear. Monads are not an example, that is the point. It is like saying in python "Given that all user input/state already has to be handled carefully (for ex: with dictionaries)." It is nonsense.