OWASP Talk - WriteupReading time: 6 mins
Why the need to blog? And more importantly, why is that all the more important for security-researchers?
That was one of the central questions that I tried to answer during my talk yesterday at OWASP@UCF. I strongly believe in the philosophy of Do things and talk about them. Let me clarify what that means, I don’t mean for someone to do a trivial task and then just boast about it to everyone and their brother. The idea here is more simple, when you work on projects, it is usually helpful to write your ideas down. In addition to that, if you are going to write them down, why not write them down somewhere others can see?
With platforms like Medium where a user can sign-in just using their Twitter account and just get writing, there is no excuse to not get started. Writing online does a few things but the most important one is that you can use it to leverage your online presence. This has much more profound effects than one might suspect. The first one that I understood was just how connected I became to the world, it’s not that I wasn’t before but knowing that I would have to make a blog-post made me read more vicariously. I know I need to write about something interesting, and just knowing that pushes me to write more and communicate my ideas more effectively. The skill of communicating good ideas is incredibly important in information security. Just think about the example of shell-shocker, I wrote about it here but most of the information I got was from other blogs. A lot of information security people love solving CTF-style problems but I think what’s more important is to write about how you did it. That will not only reinforce your own learning but also it will help others understand how to solve them too - Who knows someday a future employer or a business partner might see that write-up and be interested in you or offering you a position. The key take-away from this is that you will 100% of the shots that you don’t take, there is no risk in writing: It doesn’t matter if anyone sees it, or how many viewers you have, or even if your writing isn’t the best around. Start small but start something.
Another positive side-effect is that my writing skills have improved tremendously - We all have lots of ideas in our heads but to explore our own position on a lengthy and sophisticated question, writing is so powerful in making long-lasting connections in your own brain. As developers, we always want our brain ticking. Stability is boring, that’s why adding features and improving existing code is incredibly enjoyable. Jekyll provides that kind of comfort to create your own blog that you can host on github, getting started with Jekyll is incredibly easy and all you need to do is fork an existing repository that contains a theme you like and voila your blog will be up and running!
Let’s dive a bit into this process. We can start by looking for a nice theme to use, I think it’s important to get an idea of the look and feel of the blog before we dig into the basics. One way is to look at other blogs that you might know of who use jekyll, or we can just go to Jekyll Themes and see some interesting themes available. I have a few in mind all made by Michael Rose These are simply incredible to start off and they obviously have the core features all built-in:
So how does Jekyll work and what is it really? Jekyll takes your static defined files written in markup and converts those into html files and your blog-site which can then be hosted. Jekyll is a static-site generator at it’s core. To generate the static sites, it follows certain rules which the rest of this post will touch on. Those rules allow Jekyll to create any of those incredible sites by Michael Rose that I linked above. It’s powerful, isn’t it?
What makes Jekyll powerful for me is to take a theme like one of those and use it as a layer to build something upon. I have much more control over my blog than any other engine. More importantly, this allows me to treat my whole blog as an app: It’s modular and has an object-oriented-esque A lot of files inherit their CSS and other elements from pre-defined templates. Just like any other app, Jekyll has an intuitive structure:
Let’s go through these files in turn. The first thing to notice is anything starting with a _ is a folder or file that gets compiled by Jekyll directly (along with its contents). Config.yml is the first file in the structure, it contains the global settings for Jekyll that you can define, such as if you want to use any plugins. The information generally varies from theme to theme but it’s very straight forward input variables that control the look of your blog and sometimes other your social accounts.
Let’s skip includes for a moment, we’ll come right back to it. The next folder is layouts, this folder contains the templates where you define post-types. More precisely, this folder contains all the templates that you’d like to use. The most generic one is called default.html, the blog-post text template inherits the basic meta properties from default. Think of this as the post template has a layout of default. In this manner, we can define more templates that can then be used as layouts to render the static pages as beautiful blog-post types.
So what about includes? The files in the includes folder are the code that can be included into any of the templates. This makes sense from a modularity standpoint where you want common elements to render on all of a particular post-types but not some others. So instead of defining them over and again each time you write a post. The posts folder, as the name implies contains the post names. The names are written in a particular format: The year-month-date-file-name.md
The next folder is the site. This is relevant if you have a local jekyll install. Jekyll compiles all the _X folders into the _site. So the _site basically contains your whole static blog compiled by jekyll that can be then deployed to github or S3 for instance. To get a better overview, I advise the interested reader to see the following video:
Lastly, here are my slides from the OWASP Talk: