Django has had lots of time invested in its security, but I want to go with an all Julia stack. Is it a bad idea to select Julia (specifically genie.jl) for a web application if security is a potential concern? can one or two people reasonably secure the code themselves?
@essenciary as the author of genie, i’d love to get your input.
and @anon94023334, as someone previously touched on Julia security issues, can you please chime in aswell?
thanks!
@datnamer, I’m afraid I don’t have a whole lot to contribute here. I haven’t done anything with respect to webapp development in Julia – I’m using it mainly as an interactive research tool right now.
One thing you’ll probably want to be aware of, though – https://github.com/JuliaLang/julia/issues/9147 could result in sensitive data being exposed if you’re allocating memory this way. I say “could” because I can’t recall the subtleties of this behavior, and don’t know whether the framework(s) you plan to use take this into account.
@datnamer Genie.jl has been built with security in mind from day one. Some of the most important features in this regard are:
SearchLight’s query builder - use the provided types, SQLInput and SQLColumn to wrap user input and have it properly escaped before sending it to the SQL server. Even if you don’t use this wrapping explicitly, the query builder will do it for you, eliminating the risk of rookie mistakes like interpolating GET and POST vars directly into SQL query strings.Strings instead of other types).type) requirements.Cookies by default.Flax.jl view templates which are also compiled.GET and POST variables - they are made available through the @params() collection which can be sanitized (sanitization not happening right now as it’s a bad idea to do it by default, as seasoned web developers probably remember PHP’s magic_quotes fiasco – but it might be interesting to have a hook that would automatically trigger custom data sanitization rules if available).Cookie and Session variables - access to them is provided through helpers that could sanitize the data.At this moment, the single most important missing feature that I can think about, in terms of both security and developer happiness is a form helper that would know how to render models into forms and automatically escape input to block XSS scripting vulnerabilities. So at this moment, it’s the developer’s responsibility to escape user generated data upon rendering HTML to avoid XSS attacks (user inputted JavaScript code being injected and executed on the page).
That being said though, the codebase has not been audited explicitly for security vulnerabilities. Also, the project is very young, with very limited production usage. So if you ask me if the code is 100% secure (or bug-free in regards to security), based on my experience with other technologies, I’d say “probably not”.
You simply can’t compare Genie v0.7 with Django or Rails or Phoenix or any other framework that’s been in production for years, supported by thousands of contributors and tens of thousands of hours of development time. And that goes for security, bugs, performance and features. Let’s be realistic about it.
To conclude, if you’re thinking about developing security critical and performance critical products today with Genie.jl or any other beta software stack for that matter, my advice is obviously not to. Not only Genie, but Julia itself is still beta.
But if you have a side-project or you work on a lightweight web app MVP for your startup and you want to turn it into something fun, exciting and rewarding and can spare a few hours to contribute to Genie.jl by reporting and fixing bugs or adding new features, then by all means, yes, Genie would be great for that!
Even the longest journey starts with a first step. Django was once beta software too, with just a handful of contributors. It’s up to us to make Genie equally safe and feature rich. And eventually better, I’m sure, considering Genie’s unique strength: it’s built with Julia, which makes it easy to write performant and safe code! 
Since security was not a design goal of Julia AFAICT, I am not sure that we have any reason to believe that it is “safe” in the sense the term is understood for web applications. While most bugs are fixed, the focus of the community seems to be on speed, convenience, and experimentation with various language features (“getting it right”). This is probably optimal for scientific software, but I would not dismiss the possibility of a moderately determined attacker being able to exploit some issues.
Yes, absolutely. That’s why I said “safe” and not “secure”. By this, I meant language features that for example make it harder/impossible to access invalid or restricted memory locations, elimination of a class of bugs through explicit and strong types, etc. “Safe” in this sense: Meet Safe and Unsafe - The Rustonomicon
Language safety does promote security through clear code, the elimination of some classes of bugs and limiting lower level vectors of attack - but of course, does not guarantee it.
After the recently revealed, massive security issues in highly popular, established and heavily funded products, I would be very surprised and skeptical if anybody would claim that Julia, at v0.6 is 100% secure (assuming that such a thing exists at all!).
hi everyone,
thanks for all the input. It sounds like despite the immaturity of the language and ecosystem, Genie is engineered for security well enough for my usecase.
I would have been worried had there been less thought put into those vulnerabilities.
@essenciary how should i get started and what are the hosting options? Docker and any cloud service?
@datnamer Hosting Genie apps should be identical to hosting any HttpServer.jl based Julia apps.
I can think of 3 hosting options at this point - the first one I’ve used for a year now with good results. The other 2 are things that I recently picked up through my research - can’t comment as I’m currently looking into them. I will publish more updates/tools as I go. Hopefully, users will try things out and best practices regarding Genie hosting will emerge.
1/ “old school”
a) setup Julia on a VPS of your choice (I use a 2 GB DigitalOcean VPS with Ubuntu at $20/mo to host http://genieframework.com/packages)
b) setup your Genie app - which means just make sure you can start it via GENIE_ENV=prod ./genie.jl s. Make sure you can access it on port 8000.
You can host multiple apps by configuring additional ones to run on different ports (GENIE_ENV=prod ./genie.jl s -p 8001
c) use an app like supervisor, pm2 or forever to start your Genie app and automatically respawn it in case it crashes. I use supervisor but pm2 seems to be very good and it’s a lot simpler to configure.
d) setup Nginx as a reverse proxy to map port 80 to port 8000. This way your app will be accessible on the default web port. Also, setup Nginx to directly serve assets (css, js, images) - Nginx has great performance serving static files and there’s no benefit in streaming these through Julia.
Of course, you can also start the Genie app directly on port 80 and skip Nginx altogether. But be careful that this means serving static files through Julia and running the app with an elevated account (port 80 requires root privileges).
2/ Julia Heroku build pack
There’s a Julia Heroku buildpack: https://github.com/pinx/heroku-buildpack-julia (follow instructions for deploying apps with buildpacks)
3/ Docker hosting on Heroku or another provider that supports this (follow hosting provider instructions)