Intro to infosec

For the past several months I’ve been pursuing a self-directed education in information security and immersing myself in a wealth of amazing topics. It’s an incredibly broad field, and daunting in its complexity but then what isn’t. I figured writing about it would solidify some concepts and organize my thoughts.

My time is currently mostly devoted to reading while I collect tools and provision a sandbox. I settled on this amazing free course from the University of Helsinki for a more structured approach

The way I use, write and reason about code has changed significantly. This paper categorizes software flaws into two groups

Implementation flaws

The classic bug. This could be an error throw due to an invalid reference, missing resource or just faulty logic. The list is extensive.

Design flaws

This is where it gets interesting. These flaws are deeper yet all encompassing and include things like error pages leaking information, offloading auth to the client, poor sandboxing and assumption of trust between services or just plain old misconfiguration and leaving things exposed.

  • Design systems assuming they will eventually be compromised, limit trust and live/die by the principle of least privelege

  • Don’t mix data and control instructions. Allowing untrusted input data to be executed like any other code leads to injection vulnerabilities and control-flow hijacking.

Reflections on software development consulting

It’s been about a year and a half since quitting my job to become self-employed and for the most part it’s been swell. Having said that, I think it’s time to cycle back into a team.

Consulting was great because I got to

  • Broaden my non-technical skills. Managing people is a completely different job from building software, but one I enjoyed immensely. What people say and what they actually mean or want are often at conflict, and the ability to help reconcile the two is invaluable.

  • Make design/architecture/development decisions and manage my own projects.

  • Focus on other areas of my life. I am generally smarter, stronger and more well-balanced than ever. Just having the time to think or be bored allowed me to figure out how to lead a more meaningful life, and clarified my goals and priorities.

Joining a team is becoming a priority because

  • My technical skills are stagnating. As the saying goes if you’re the smartest person in the room you’re in the wrong room. Working from home alone I am by default the smartest in the room :(

  • I need access to a different set of challenges that align with my long-term career trajectory. For the most part clients require the same set of services when it comes to web development: new features or bug fixes. While I got to kick-off some fun green-field projects, much of the work remains of the same nature. Unfortunately this means I haven’t had exposure to complex systems at scale, or infrastructure and security management.

  • I haven’t been marketing (nor do I super enjoy it). Luckily all of my work has come through word-of-mouth and referrals, but that’s drying up.

Multi-user git

Modify your ~/.ssh/config file as such to seamlessly utilize multiple git users on the same machine

Host user1
  User git
  IdentityFile ~/.ssh/username1_pubkey
  IdentitiesOnly yes

Host user2
  User git
  IdentityFile ~/.ssh/username2_pubkey
  IdentitiesOnly yes

Then for your repo ensure git remote -v is of the form

[email protected]:<username1>/<username1-repo>.git

Of course, ensure your ssh key is added to the respective repo.

emacs vs vim

After spending the better part of last year using emacs (specifically the spacemacs distribution) before switching to neovim I can safely conclude I’ve shaved enough yaks to last me a lifetime. I’m switching back to Atom because configuring editors is a waste of time that could be better spent actually building things. I could be meticulously installing and configuring packages for crucial features like fuzzy project search, OR I could just use a modern editor.

Luckily most of the emacs navigation keybindings work in atom. God bless.

Rails and default_scope

It should be common knowledge by now NOT to use default_scope unless you know what you’re doing. I thought I knew what I was doing but was wrong, which is often the case.

Imagine having a model with a boolean :finished attribute. And in your schema for this table default: false. You want to only ever retrieve instances that are marked finished, so you write

default_scope {where(finished: true)}

Great, but guess what? New instances of this model will have their :finished default to true, contrary to the schema definition. Crazy right? Don’t use default_scope.

<< 3 of 6 >>