Hacker News new | past | comments | ask | show | jobs | submit login

> This suggestion eliminates bugs that are introduced by unsafe typing, sure. But race conditions, logic flaws, misconfigured tools and almost every class of web vulnerability wouldn't be eliminated just by implementing this.

How often are security flaws a subtle, complex thing that couldn't have been caught by a sensible type system? Almost all of the flaws we hear about, at least here, are the really simple dumb mistakes that a better language absolutely would have caught.




Do you mean a language with a very strong type system like Haskell, where you could create a web framework in which things like user input have different types associated with them? Those can offer some real advantages by never mixing untrusted input with page output and various calls to other systems.

But you don't get a lot of web application security advantages when you compare, say, Python and Java.

Of course, a very weak type system like PHP's can definitely introduce additional security flaws.


A common pattern (at least getting there) in Scala/F#/Haskell is to have paired types, UserInput and ValidatedUserInput. All the business logic requires the Validated kind. A programmer can be certainly be lazy and just return the supplied value, but this is a conscious choice to do the wrong thing.

You can't accidentally forget to validate form parameters. It won't compile. This is pretty easy to do in Java. On the weaker side, I would assume php and python have something like perl's taint mode. It's such a simple thing and it avoids so many xss problems.


I'm mostly comparing with Scala because that's what I use most of the time. But even in Java it's very possible to get the same safety advantages - it's just that working with that level of type detail gets extremely cumbersome, so for most projects it's not worth it.


Agreed. I try to explain sometimes that I'm merely tired of experiencing the same problem, over and over, for years.

I would like to experience the next problem, please. If only for variety's sake.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: