Perhaps Cecil is referring to this article, Clojure web security is worse than you think<https://hackworth.be/2014/03/26/clojure-web-security-is-worse-than-you-think/>, describing the immature state of Clojure's web security libraries. I don't think the language itself has much to do with this, except that until functional programming goes mainstream, we have a smaller community writing and testing these libraries. Also, maybe the language does not lend itself to a one-size-fits-all framework, but rather encourages rolling your own solutions. This is fine for folks well versed in web security, but it is a problem for non-experts who still want to write secure web apps.
On Monday, May 5, 2014 6:13:16 AM UTC+8, Evan Rowley wrote: > > The most serious security vulnerabilities I've heard about for 2014 are > Apple's SSL/TLS/HTTPS vulnerability, the OpenSSL Heartbleed vulnerability, > FreeBSD's TCP bug, and of course the Mt. Gox bug that resulted in the > company's bankruptcy. > > The Mt. Gox bug was caused by a flaw in the way they designed the > software. It did not have anything to do with the programming language used > to create it. > > If you look at Apple's recent SSL/TLS/HTTPS vulnerability, the entire > problem was caused by a misplaced goto statement in their C code. > Interestingly, the LLVM compiler, which Apple evangelized in their > development toolchain, was even capable of detecting and removing the > error. Unfortunately, the advanced compiler feature wasn't used, and the > vulnerability persisted for a long time in their OS X 10.9 code, breaking > all SSL/TLS/HTTPS. > > The OpenSSL Heartbleed vulnerability that allowed encrypted SSL/TLS/HTTPS > sessions to be snooped upon was caused by a lack of bounds checking in the > connections heartbeat / keep-alive C code, not in any of the actual > validated crypto code. > > FreeBSD's recent TCP bug that allowed privileged arbitrary code execution > on servers was caused by C mishandling of memory references. > > The question we have to ask is: Would use of a (specific?) functional > language prevented these? My opinion: > > Probably not in the case of Mt. Gox because their problems had more to do > with their application design. > > As for Apple, I think the 'goto' feature is missing from at least Clojure. > Both Haskell and Erlang have 'goto', but it's use isn't encouraged. I'm > thinking that because these languages are functional, the goto feature > works in a safer manner that wouldn't have allowed Apple's code to work > with the failed certificate check. But that's just a guess. > > For OpenSSL's Heartbleed, I'm going to say that this wouldn't have been > prevented even with functional programming. The problem lies in the design > of the heartbeat code. One thing I do have to wonder about is whether or > not this heartbeat code would have been designed differently if it were > done in a functional programming language. It's worth keeping in mind that > the higher level of abstraction most functional programming languages have > would have contributed to a different design. > > FreeBSD's TCP bug *might* have been prevented if the functional > programming language's runtime did effective memory management. I'm going > to assume that everyone here agrees that functional programming languages > have well-designed memory management. > > > On Sun, May 4, 2014 at 5:40 PM, Magnus Therning > <mag...@therning.org<javascript:> > > wrote: > >> On Sun, May 04, 2014 at 09:24:08AM +0200, Cecil Westerhof wrote: >> > I heard the stand that functional programming made it difficult to >> > write secure programs. I do not know enough of functional >> > programming yet to determine the value of a statement like this. >> > What is the take here about it? >> >> It would be interesting to hear WHY functional programming would yield >> less secure programs. What would then be the paradigm that results in >> most security? Imperative, logical? >> >> Here is my take on it: >> >> It's widely acknowledged that writing secure programs is difficult. >> I'd even go as far as saying that it's an inherently complex problem >> in real-life applications. And as Brooke tells us, if we reduce >> incidental complexity we can concentrate on the inherent complexity. >> That would point us in the direction of high-level languages that >> dispenses with distractions like memory management.[^1] >> >> Many programs worth writing becomes large, size is in itself a >> contributor to complexity. So expressive languages will arguably aid >> reducing the size of the code. >> >> Security and correctness are related, and arguing about correctness in >> the face of shared state is tough, so even though Strachey tells us we >> can get referential transparency in imperative languages it is my >> experience that very few developers write imperative code with shared >> state that is easy to argue about. That means we want immutability as >> deeply rooted in the language as possible. >> >> I think this all adds up to pure functional languages being an >> excellent choice if you want to write secure code. >> >> There are of course exceptions, e.g. in some very specialised >> applications you need to have extremely fine control over the >> behaviour of the computation is carried out. In these cases you'll >> need languages that have a computational model that is closer to the >> CPU (i.e. imperative). Of course you'll restrict the use of that >> language to the "primitives" that require it and then make the jump to >> a higher-level language as soon as possible. >> >> /M >> >> [^1]: In a reverse-engineering course Halvar Flake told us that the >> first thing he looks for when starting to analyse an application is >> the memory management. If the developers have decided to roll their >> own memory management it's almost certain there's a security bug in >> there somewhere. >> >> -- >> Magnus Therning OpenPGP: 0xAB4DFBA4 >> email: mag...@therning.org <javascript:> jabber: >> mag...@therning.org<javascript:> >> twitter: magthe http://therning.org/magnus >> >> Heuristic is an algorithm in a clown suit. It’s less predictable, it’s >> more >> fun, and it comes without a 30-day, money-back guarantee. >> -- Steve McConnell, Code Complete >> > > > > -- > - EJR > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
