TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Clojure web security is worse than you think

147 pointsby r4umabout 11 years ago

14 comments

ddellacostaabout 11 years ago
The talk he links to (<a href="https://www.youtube.com/watch?v=CBL59w7fXw4" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=CBL59w7fXw4</a>) is really fantastic. Kudos to Aaron Bedra for issuing a well-considered and practical wake-up call to the Clojure community.<p>I support a Clojure&#x2F;ClojureScript web app in my day-to-day work. I&#x27;ve also written an OAuth2 workflow for friend (<a href="https://github.com/ddellacosta/friend-oauth2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ddellacosta&#x2F;friend-oauth2</a> ...pull requests welcome), one library Aaron Bedra spends a lot of time talking about. The story really is exactly how he describes--Clojure web security could be better. I suppose you could argue that, at least, the defaults are generally not bad...but that&#x27;s because there aren&#x27;t defaults in many cases.<p>I think the main issue is, ironically, the same thing that makes Clojure development so great: you end up composing a bunch of small libraries together, each of which do one thing well. But as Aaron points out, there are things that aren&#x27;t taken care of and you can&#x27;t assume they are done for you, and a lot of security is something that you don&#x27;t technically <i>need</i> to get a web app working...<p>I wouldn&#x27;t want to give up the approach of composing a bunch of libraries to build concise, easy-to-reason-about web apps in Clojure--I think it helps with security in and of itself--but the community could really benefit from having more libraries which nail these things down and help developers build web apps more safely, with less work.<p>That said, I don&#x27;t think it&#x27;s all bad: you <i>can</i> build high quality, secure web apps in Clojure, it just requires you to really pay attention to security. And we should be doing that anyways, right?
评论 #7474778 未加载
评论 #7474744 未加载
评论 #7477022 未加载
moondownerabout 11 years ago
The title should be: Don&#x27;t assume security is happening automatically under the hood.<p>Even if using a web framework which supports security out of the box, don&#x27;t take it for granted either. For example: that&#x27;s a common error developers make when using Spring Security. It&#x27;s powerful and full-featured, and developers get security and everything in a breeze, but when doing things on the fly misconfiguration happens and vulnerabilities are out there in the open.
St-Clockabout 11 years ago
I believe this warning could apply to any young ecosystem or micro-framework (e.g., bottle). Could web applications written in Go, or to a lesser extent, node.js, suffer from the same shortcomings?<p>After working so much in Django, I&#x27;ve been interested in smaller, leaner solutions, but then, as my feature list keeps growing, I find I miss all the bells and whistles provided by larger frameworks. I did not think of the security implication before reading this article.
评论 #7473610 未加载
评论 #7473487 未加载
评论 #7473739 未加载
john2xabout 11 years ago
I felt some relief after watching the presentation. I thought I was just a whiny newbie who was spoiled by Python&#x2F;AppEngine (although I guess the spoiled part is true). Turns out it is a real issue with the Clojure ecosystem.<p>Another talk from the conference I&#x27;m glad was presented is &quot;How Clojure Works&quot;[1]. Towards the end, he shows the negative effects on tooling caused by Clojure&#x27;s dynamic + hosted nature. Clojure&#x27;s stacktraces are a nightmare. And the painful startup time kind of negates the excitement a newcomer might have towards REPL-oriented development.<p>Hopefully it won&#x27;t be too long until things improve.<p>[1]: <a href="https://www.youtube.com/watch?v=8NUI07y1SlQ&amp;list=PLZdCLR02grLp__wRg5OTavVj4wefg69hM" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=8NUI07y1SlQ&amp;list=PLZdCLR02gr...</a>
评论 #7473402 未加载
评论 #7473287 未加载
评论 #7476622 未加载
eudoxabout 11 years ago
Web development is very particular because of security. You can write, say, a console newsread with any programming language that has an XML parser and a curses binding. But if you want to write a web application that will actually see production, you need a web framework that has been sufficiently battle tested and audited by security-competent people.<p>Which is a shame, because I&#x27;d really like to be able to use Common Lisp for web development. But as much as I love the language, you have to be reasonable.
评论 #7473379 未加载
评论 #7476867 未加载
评论 #7474203 未加载
whymeabout 11 years ago
I&#x27;ve spent the last 3 years developing in Clojure and found I was quite happy not having an all encompassing framework. It forced me to learn all these issues and understand them well enough to be able to customize each and align them with a products design.<p>Sure it&#x27;s more work, but in my mind, it&#x27;s worth it.
评论 #7473570 未加载
manishsharanabout 11 years ago
Web Application is one of the places where Clojure&#x27;s java compatibility falls short. I have a ton of time invested in Spring + ACEGI security and it just works. I have been exploring on how to develop servlets, which can use servlet session, in Clojure and they all look very ugly compared to normal Compojure based apps. I am coming to the opinion that maybe its not ready for J2EE web apps , which is a shame as J2EE has a very rich ecosystem.
homakovabout 11 years ago
All non-mainstreem web frameworks are very immature in terms of web security. No CSRF&#x2F;XSS&#x2F;SQLi projections built in, don&#x27;t even say about security headers. If you use an unpopular framework you should do all protections yourself.
评论 #7475736 未加载
评论 #7474091 未加载
评论 #7476001 未加载
danneuabout 11 years ago
When I think of other developers like me that are building projects solo on top of Express&#x2F;Sinatra&#x2F;Compojure, the most helpful resource would be a simple checklist.<p>For example, the CSRF section could briefly explain what cross-site request forgery is, `&lt;img src=&quot;<a href="http://example.com/logout&quot;&gt;`" rel="nofollow">http:&#x2F;&#x2F;example.com&#x2F;logout&quot;&gt;`</a>, and recommend some approaches and good practices.<p>Code examples could be provided for various languages&#x2F;frameworks each in its own tab. The Clojure tab could demonstrate <a href="https://github.com/weavejester/ring-anti-forgery" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;weavejester&#x2F;ring-anti-forgery</a> and a `anti-forgery-form-to` macro that wraps `hiccup.form&#x2F;form-to` and inserts `(ring.util.anti-forgery&#x2F;anti-forgery-field)` into the form.<p>The XSS section could remind us to ensure that our templates are escaping user input. The Clojure tab could chart the safe vs unsafe templating libs. (Hiccup is unsafe)<p>The Sessions section could remind us to sign our cookies so that someone can&#x27;t just change a cookie from {:user-id 42} to {:user-id 1}. And that our never-expiring authentication cookie means that anyone with that cookie can log in as that user forever. It could explain an overview of the main solutions and their drawbacks like how to back sessions by a database or set an expiration within the signed cookie.<p>Just like convos about crypto, discussions about security too frequently turn into some abstinence-only pamphlet.
评论 #7476452 未加载
borskiabout 11 years ago
This presentation echoes a lot of what we&#x27;ve seen. For what it&#x27;s worth, we scan a lot of Clojure apps and find a lot of the types of vulnerabilities Aaron&#x2F;John are talking about. Feel free to run a free scan at <a href="https://www.tinfoilsecurity.com" rel="nofollow">https:&#x2F;&#x2F;www.tinfoilsecurity.com</a> if you want to try it out. :) Would love feedback.
jmnicolasabout 11 years ago
So what are the secure by default web frameworks apart Django and Rails ?
评论 #7479136 未加载
评论 #7475752 未加载
评论 #7476065 未加载
pc86about 11 years ago
FTA:<p>&gt; <i>and session cookies don&#x27;t default to http-only flags (allowing XSS attacks to steal them).</i><p>Can someone explain that to me?
评论 #7474262 未加载
评论 #7474241 未加载
stcredzeroabout 11 years ago
Perhaps a better title would be &quot;Complete beginner web apps in Clojure less secure than complete beginner web apps in other environments.&quot; (EDIT: Isn&#x27;t security a perfect example of a place where (good tech + good community) &gt; (miracle tech + bad community)?)<p>This brings to mind an incident, about which I&#x27;ll say: While I do find that the community is friendly and a source of satisfying discussion in person, the Clojure community online is notably less beginner friendly than other language communities. (tl;dr - Attempts to &quot;help&quot; newbs that are really opportunities to be a language weenie considered harmful.)<p>I find some parallels with the Smalltalk community, which had a reputation for an &quot;ivory tower&quot; attitude and a &quot;Not Invented Here&quot; snobbishness. When I was a beginner in Smalltalk, a coworker of mine had written a nice but arbitrary little DSL specification language using Array literals and symbols. So I made some sort of comment about the syntax she&#x27;d created, and which prompted a <i>knee-jerk reaction about how Smalltalk had a small non-ALGOL syntax</i> -- as if I were totally unfamiliar with Smalltalk syntax.<p>I&#x27;ve had experiences like this asking about the arbitrary function definition-like syntax of Compojure web application routes. Those look somewhat like function definitions, but they&#x27;re really macros. I had tried for some time to Google the answer, but no one had ever posted about the exact code to do what I wanted. (Which wasn&#x27;t at all abstruse. Something like getting access to the entire request map while modifying the returned session.) Well, it turned out that all I needed to know was to not refer to the request as<p><pre><code> [request] </code></pre> but as:<p><pre><code> request </code></pre> But instead, I got people hounding me on IRC, saying &quot;It&#x27;s all made out of functions&quot; - with what struck me as an almost cult-like zeal - <a href="https://www.youtube.com/watch?v=ZYTkSFRmKzM#t=5" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ZYTkSFRmKzM#t=5</a> One individual snidely comments he&#x27;d put me on &quot;ignore&quot; and others kept telling me to go read the source code, and how wonderful that it was all made out of functions, and how wonderful it would be once I finally understood. Well, I told them that I did understand that, and that &quot;everything being functions&quot; had little direct bearing on what I was asking about. I am reminded of how Smalltalkers got a chip on their shoulder from the circumstance of Smalltalk&#x27;s significant differences from mainstream. (Me included, I am afraid.)<p>Just what kind of community treats with newcomers by assuming that the newcomers are lying and then telling them to go read Lisp macros? Also, this is only the most easily related situation I&#x27;ve encountered while interacting with the Clojure community. There have been others.<p>No non-algol patterned language has ever gained more than a niche acceptance. If Clojure doesn&#x27;t want to commit long term mindshare suicide, some attention needs to be paid to avoiding inadvertent hostility to newcomers. (This includes unintentionally being a bad security-defaults minefield.) Smalltalkers had the same &quot;read the source&quot; knee-jerk. In the end, it didn&#x27;t work out so well. Care needs to be taken to understand exactly what the newbs are asking, because they know the least about how to formulate the question. Also, if you find yourself running a simplistic &quot;pattern match&quot; head-daemon eagerly looking for opportunities to bedazzle the newb with your wonderful, superior, and different way of doing things, just stop. You are giving your community a &quot;weenie&quot; reputation and your mental energies are better used elsewhere.
评论 #7476548 未加载
评论 #7477279 未加载
评论 #7476816 未加载
mantrax3about 11 years ago
Many things said in that video are kinda off.<p>He mixes password hashes and MAC (message authentication codes), saying we should HMAC our password hashes. There&#x27;s little to gain from that:<p>- Password hashes exist to hide passwords. The attack is to discover the original password by brute force, dictionary, rainbow tables etc. The protection against this is irreducibly slow hash algorithms and unique <i>public</i> salt per hash.<p>- MAC exists to authenticate message origin. Unlike passwords, the message is often public. The attack is therefore <i>not to discover the message</i>, but to manipulate the message, yet make it appear from the same origin as the original message. The protection against this is the HMAC algorithm with a <i>secret</i> key that only the original message author has.<p>HMAC-ing your password hash won&#x27;t stop, or even significantly slow down any of the attacks performed against password hashes, so it feels cargo cultish to claim it&#x27;s just magically more secure by using it. It&#x27;s even more WTF-y to claim a password hash library <i>should</i> offer HMAC, or it&#x27;s insecure.<p>Once a system is compromised, and the attacker doesn&#x27;t care to recover the original password, it&#x27;s far more trivial to just replace the hash or just directly read the data protected by the login directly in the DB, rather than play out a MAC attack on a pass hash. It makes no sense.<p>HTML escaping. You either escape for HTML or you don&#x27;t. There&#x27;s no sane way to escape <i>some of it</i>. His idea that we should be able to escape some tags, but skip (or &quot;strip&quot;) others is a huge vector of attack as HTML is notoriously filled with edge cases that your <i>selective escaping&#x2F;stripping engine</i> won&#x27;t have. It&#x27;s <i>not trivial</i> to parse what&#x27;s a tag and what isn&#x27;t a tag to a browser, trust me. It only looks trivial if you&#x27;re ignorant.<p>If you want to allow some tags, and disable others (say, allow bold&#x2F;italic on forums, but nothing else) you should go through a strict DSL allowing only those types of formatting, which are then <i>converted</i> to HTML. Just like HackerNews does it - I type star-word-star and I get &quot;word&quot; in italic. That&#x27;s a DSL. That DSL <i>could be made</i> to look like HTML, but it won&#x27;t be HTML. It&#x27;s fully parsed and rebuilt from the DSL syntax tree. So it can be made safe. Selective HTML escaping without those crucial steps is almost impossible to make safe by comparison.<p>His rant about &quot;there are too many templating engines - we should stop&quot; - yeah, good luck saying <i>we should stop</i> and this working out.<p>Likewise about databases. &quot;Let&#x27;s just stop&quot;. B.S. The thing he&#x27;s missing is that different DB engines have different strengths and weaknesses. That&#x27;s one major reason there are so many, and why many get used in the same project. PgSQL isn&#x27;t SQLite isn&#x27;t MongoDB isn&#x27;t Redis.<p>By enforcing one type of database for multiple separate project components, you don&#x27;t improve security, you just cripple architecture and performance.
评论 #7475859 未加载
评论 #7479412 未加载