It's 2016, And You're STILL Doing Forms Wrong (And So Is Your Framework)! [Part 3]

Corey Pennycuff's picture

Defiant: A Proposal For Tool Unification.

Defiant is a Node.js module that I am writing to answer the problems that I will address in this post. First of all I must address the question: "Why the name 'Defiant'?" In order to do so, I must first make sure that you understand the mindset of current development (mainly addressed at the Node.js ecosystem, although it is not limited to such).

The Motivation For Tool Development

We should probably begin with the Unix tool philosophy. For the uninitiated, the philosophy states that programs should be small, accomplish a single task, and have a well-defined input/output mechanism. As many command-line warriors will tell you, knowing how the individual tools work saves them time and allows quick, powerful, bug-free productivity without having to reinvent the wheel for every task. It is one of the philosophies that has propelled Linux to be the powerhouse of development that it is today.

It's 2016, And You're STILL Doing Forms Wrong (And So Is Your Framework)! [Part 2]

Corey Pennycuff's picture

Forms—A better way

The better form processing that I propose is inspired by Drupal, but furthers the idea to improve on it. In order to properly understand the approach, though, you should understand how Cryptographic Signing (specifically, Authenticated Encryption) and the Galois Counter Mode (GCM) operate.

A quick overview of the GCM cipher goes like this: Given a secret key, a plaintext, and an initialization vector (IV), a GCM cipher should return a ciphertext and an authentication code. The ciphertext, IV, and authentication code is then given to the user. When the user returns, the GCM decrypt function takes in the secret key, the ciphertext, the IV, and the authentication code, and returns the plaintext. This may sound a bit complicated, so let me break it down a bit more.

The secret key is something that is stored serverside, and is preferably unique to each user. The IV is a short string that is unique to that encryption. The uniqueness is a requirement to a counter-type of encryption like GCM. In short, the IV must be different every time that the encryption is called, otherwise the ciphertext is vulnerable. Lastly, the authentication code is a string which validates that the contents of the encrypted text has not been tampered with. It does not matter if the end user is given the encrypted text, IV, and authentication code, because if the user changes any part of any one of these, then they will not validate when combined with the secret key.

It's 2016, And You're STILL Doing Forms Wrong (And So Is Your Framework)! [Part 1]

Corey Pennycuff's picture

What's Missing In Form Security

One day, a professor came to me with an interesting question: "Corey, my server is getting hacked! Can you figure out how?" "Can you tell me what exactly is happening?" "Yes," he replied. "Somehow, people are uploading files to my server, and trying to hack me." And with that, I delved into the world of form handling (a solved problem, I had assumed), and was appalled at what I found.

This professor was neither unintelligent nor shoddy in programming skills. What he was not, however, was an expert in web security, and therein lies the problem that this post is about. It's not about SQL injection. It's not about using the newest tools or the most recent library. It's about understanding how form submissions can be your Achilles' heel. The professor was qualified in his programming ability, but he was not a web security expert, and you are probably not an expert, either. He was doing everything right, according to the docs and numerous tutorials on how to work with his particular framework, but the information was wrong. The scariest thing is that it's very likely that the framework that you are using is getting it wrong, too.

Open Question: Is there a non-MVC node.js framework?

Corey Pennycuff's picture
nodejs-green.png
Image from nodejs.org.

tl;dr

Is there a non-MVC node.js framework with Drupal-like plugin power and flexibility? If not, is anyone interested in working on one?

A very quick background about myself.

I have developed websites professionally with Drupal since 2004. I have worked as a freelancer as well as salaried and hourly programmer (not just with Drupal, but you get the idea). I have worked on several HA projects and have worked on large dev teams. Academically, I am currently working on a PhD in Comp Sci (already have the MS, and am 2 years in to doctorate). Why do I say this? Just to establish that I'm not a noob suffering from NIH, neither do I think that all web apps are a nail. I do, however, have experience and opinions. It doesn't mean I'm right, but it doesn't mean I'm wrong, either.

My Git Cheat Sheet/Handout

Corey Pennycuff's picture
Git-Icon-1788C.png
The Git Logo
Image from git-scm.com.

I have had the opportunity to explain Git and the basics of its operation on more than one occasion. It's something that I enjoy doing, especially because I believe it is an indispensable skill for collaboration in industry and academia. I have always distributed a small "cheat sheet" with the most-used commands, and I am posting it here (for no reason other than I can find it quickly in the future). I will include the text in this post, but I will also provide the .txt file that I use. (Yes, I wrote it in a txt file. I like the way it looks, and when I print it out using Notepad++, the wrapped text is indented nicely.

Pages

Subscribe to CS Crunch RSS