Should I include CSRF protection on a login form?
By- November 20, 2018
Since I found Angel’s “Plain English” series of blog posts so helpful when I was first learning about different kinds of vulnerabilities on the web, I wanted to continue that series. I hope to expand into some of the nuances of more commonly known vulnerabilities, and touch on some of the less well known ones. Let’s get started with one special case that I often find questions about: CSRF on a login form.
To start, if you’re not familiar with the Cross Site Request Forgery (CSRF) attack, you should definitely give Angel’s blog post from a few years ago a read. In the typical way of thinking about a CSRF, an attacker is able to submit a form on behalf of a victim with data the attacker controls. In the classic example, you can imagine an online service that allows users to transfer money between each other, perhaps by first adding their credit card. In the absence of any protective measures against CSRF, the attacker can trick their victim into clicking a link that submits a form on their account, and transfers money into the attacker’s account. However, what if our humble service is aware of this risk, and includes some form of CSRF protection on all of their authenticated forms? Our attacker will have to get a bit more clever, and though the aforementioned example might often be the most dangerous case, it is not necessarily the only one.
Strictly speaking, a CSRF attack is one where an attacker is able to submit any request on behalf of the victim. So, the attacker begins looking for other ways to trick our poor victim, and finds that the login form is totally unprotected. Hatching a devious plan, our attacker crafts an attack that would submit the login form in the victim’s own browser, thus logging them into the attacker’s account. So our victim -- now perhaps only slightly confused as to why their credit card info is missing -- adds all of their personal information necessary to send money to their friend, and logs out, thinking nothing more of it. Now our attacker, having full control over their own account, logs back in to find that they have everything they need to siphon funds from our poor victim.
As you may have noticed, the impact of an exploit like this varies from site to site, depending a lot on how likely or possible it is for a victim to leave behind personal information. It also relies on tricking the users into completing at least one extra step, instead of just clicking a dubious link. However, the world of security frequently involves accounting for even very unlikely cases, because an attacker will often have hundreds or sometimes thousands of opportunities, and doesn’t need to succeed every time. It’s also worth mentioning that even seemingly harmless vulnerabilities can be leveraged to enable more potent attacks. You might already be able to imagine how one could use an attack like this to direct a user to a page with an injected XSS, but perhaps I’ll save that concept for a later blog post.
For these reasons, I like to err on the side of caution, and avoid giving an attacker the opportunity to exercise any functionality on another user’s behalf. For more information on how we suggest you implement your CSRF protection, you can refer to the article linked above.
I hope you found this short post helpful in understanding some of the nuance of one of the most threatening types of vulnerabilities on the web. I’m one of the support engineers here at Tinfoil Security, so if you have any thoughts, feel free to email me at firstname.lastname@example.org. I’d love to hear your feedback!
Today I Learned: Using SCSS in your Vue Components
By- November 13, 2018
If you haven’t yet looked into Vue.js, it might be time to. The front-end framework is a powerful, progressive alternative to its main rivals, Facebook’s React and Google-backed Angular, and has been continuously gaining traction among the open source community.
In this way, the CSS for a given component lives alongside the rest of its code, and with the
scoped attribute, will scope all style to only this component - preventing it from bleeding outwards and affecting global styling in unpredictable ways.
One might notice, however, that throughout much of Vue’s documentation and in countless tutorials, guides, and articles on all things Vue, the language used to this styling plain, vanilla CSS. In a world where SCSS exists, with it’s support for variables, mixins, and nested styles, can we do better? Yes we can.
Styling your Vue components with SCSS is incredibly simple - provided you have the right configuration.
Above is an example
webpack.config that makes use of
vue-loader. You’ll want to install both the
node-sass packages first, however.
npm install -D sass-loader node-sass
Once you’re configured, simply add a
lang attribute to the style tags in your components:
And you’re set! Enjoy all the features of SCSS in your Vue components.
When the unlimited vacation policy doesn’t work
By- November 06, 2018
Many of us startups provide what we call unlimited or flexible vacation policies, with the goal being to take as much time off as you need, as long as it’s manager approved and you can get your work done. There are so many pros and cons and I’ve seen so many people ask why to have or not to have an unlimited vacation policy in place.
Most people think that unlimited means people will take off all the time. And, yes, we have seen that happen on some very rare occasions. We do have a policy, for example, that interns no longer get vacation during their stint at Tinfoil. Internships are typically 3 months and have a set project. If an intern takes off too much time, they’re less likely to finish the project in the scoped out time. That doesn’t mean if all of their friends are going to Yosemite they can’t, but we don’t advertise vacation for them.
What we’ve actually found for the flexible vacation policy, though, is that usually we see the opposite of most founders’ concerns: employees don’t take nearly enough time off to avoid burnout. There are lots of different things we’ve implemented in order to make our flexible vacation policy work. The first thing we implemented was holidays. We try to have one holiday a month. Sometimes those are just fun, silly holidays like Pi Day, and other times they’re your standard federal holidays, like Thanksgiving. On occasion, they’re things we’re going to do together, like Tinfoil’s Anniversary. We try to make sure holidays are spread evenly throughout the year and allow time in conjunction with both weekend and weekdays throughout the year to break up the normal routine.
When we implemented holidays, the policy was that you could still come in to work, but shouldn’t expect anybody else to be in the office. Initially, many employees still worked holidays, but it eventually got to the point where we realized that we should really take those holidays off. We started to and we noticed a drastic drop in stress and burnout levels.
Once we implemented the holidays, we still had a couple of issues where some people were still going to the normal rhythm. They wouldn’t take longer vacation and, though the holidays helped a lot, they didn’t fix the entire problem. Part of what we noticed was that if someone did something outside of their normal routine on a weekend, for example, if they traveled or did something unique that they didn’t normally do, they typically got to the point of burnout way less frequently. This led to a solution: we took a handful of holidays (typically holidays such as Pi Day, that employees weren’t already traveling for or doing atypical events for) and called them special holidays. We’ve been beta testing special holidays for 2-3 years and they work wonderfully.
For a special holiday, we give you up to $60 to go out and do something outside of your typical routine. This could mean going camping, kayaking, skydiving, getting a fondue as a group… anything you wouldn’t normally do. Of course, we have had to create guidelines over time. We reimburse up to $60. If it’s under $60, that’s ok, but we ask our employees to be honest and we’ll reimburse up to the amount they actually spent. There are some things that we’ve rejected, as well. As always, you have to be flexible and revisit your policy over time. For us, we saw some employees doing the same thing every special holiday. We eventually made the rule of there needing to be at least a 12-month gap between repeating the same event or activity.
We did have to implement a few guidelines at the beginning, based off of questions employees asked. For example, if you want to host a party, that’s OK, but if you want to play a bunch of board games, you can’t buy six different games on the company and call it good. We wanted this to be for experiences, and not for physical items. We encourage employees to use it in a manner in which they can actually experience something that they wouldn’t usually do. We found that, when people actively partake in this benefit, they tend to come back refreshed and get excited about what they did, whereas those that didn’t do anything new don’t have the same level of “refresh.” People excitedly talk about the things they did and others end up wanting to do that experience the next time, so we have a page on our internal wiki to add fun weekend ideas to share with others. This is great for team bonding, great to make sure that people don’t hit burnout, and it’s one of the few things we’ve added to make sure our unlimited vacation policy works.
It’s true that every so often you’ll see somebody taking advantage of any policy you have in place that’s beneficial to them, but, on average, we believe our employees are honest, faithful, and act with integrity. Often, you’re going to see that unlimited vacation expectations are set by the top. If your management is not taking enough of a break, your employees won’t take enough of a break, and everybody will suffer. There are lots of little things you can do to make this policy successful. What have you found? Have thoughts on how we could improve our policies or new ideas we can try? Email me anytime with suggestions!
Pluses and Pitfalls of Repo.stream
By- October 24, 2018
Scenario: you are working on a phoenix app that has seen a good deal of use and need to do some transformations of some tables encompassing an exceptionally large number of rows and their relations. Obviously, some amount of considerations for performance are necessary; if you can avoid loading an entire table into memory in order to achieve this, that would be ideal right? Enter Ecto.Repo.stream, turn that giant list into a lazily evaluated enumerable and load rows as needed. Job done, right? Well, depends.
The good news is you will definitely address the issue of memory use, however it does come at the cost of time, which can increase greatly if, for instance, you need to access a number of rows in an associated table for every row you are referencing. For instance:
This might seem like a good idea, if there are large number Bar’s for every Foo entry, but since the stream must be inside a transaction, you have one connection you’re working with to finish enumerating over the stream. This can be adjusted with the :timeout option on Repo.stream which can be relaxed from its default at 15000 milliseconds all the way to :infinity, but if your streaming changes rely on a flaky connection or some other piece of code, you could run into an issue again on that side. Safer to avoid nesting streams if possible, or to find a different way of chunking data.
If memory is a more pressing constraint than time, Repo.stream is a pretty convenient way to manage how much is loaded into memory at a given time. Just remember to choose an appropriate timeout value before you start.
Dockerfiles for Phoenix
By- October 16, 2018
While a lot of our older software was written in Ruby and Ruby on Rails we've been expanding the past couple of years into Elixir and Phoenix (Elixir's batteries-included web framework). Docker remains our preferred mechanism to deliver our software in a well-tested and repeatable format. I'd like to share with you a simple Dockerfile for Phoenix, specifically supporting Phoenix >= 1.4 which uses webpack instead of brunch.
We're using a multi-stage to keep the image slim and nimble. In the first step we get a copy of the Elixir dependencies, mainly for the phoenix and phoenix_html Node modules that are co-located in the Elixir Hex packages. The second build file lets us build and emit the finalized assets with webpack. In the final step we're back to an Elixir base image and we can copy everything over, merge the assets, and set the command for starting the server.
This produces an image around 100MB. Compared to our Slim Dockerfiles for Rails that's a space savings of 50%! We've seen some pure-Elixir applications even smaller when you use Distillery to create an optimized release, which we'd recommend for heavier production use as it gives you a lot more control.
I hope you enjoyed seeing an example of building a slim Docker image for Phoenix. If you'd like to help build next-generation security software and work with Elixir and Phoenix daily check out our open job positions!