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.

Drupal Cron: A Better Way

Corey Pennycuff's picture
BenBois_Clock.png
cron: The Unix clock daemon that executes
commands at specified dates and times according to
instructions in a "crontab" file.
Image from openclipart.org.

Drupal is an amazing system, there is no denying it. Every once in a while, however, small problems come up that no one anticipates, and your entire system grinds to a halt. This recently happened with me when needing for Drupal to run some heavy processes in cron. It croaked. Drupal got stuck in a loop of trying to run the same ill-fated task over and over, and my site stopped updating. Drupal needs cron, and all the normal ways of running cron were failing me.

Cron is an interesting creature. Many new sysadmins are mystified by its cryptic symbology and voodoo-like power, so they avoid it. Some shared hosting environments don't even allow users to set cron jobs! Back in the old days (Drupal 5 & 6), we solved this problem by using the Poorman's Cron module, which worked by starting the cron jobs at the end of a page load, after information was already sent to the user. It was virtually transparent to the end user, and this method was so popular that it made its way into Drupal 7 as a core module.

DMARC Policies are eating my Drupal emails!

Corey Pennycuff's picture
Spam_Mail.png
Spam is bad! Kill it with fire!
Image from openclipart.org.

Due to the irritating nature of spam email, companies have started hardening their policies for how they handle emails that originate from various sources. A recent change that has hurt a lot of sites and mailing lists lately is that email providers have begun to make their DMARC policies very strict. Specifically, email providers are saying, "If the email says that it is from one of our email servers, but it didn't come from our server, then deny the message." (I'm looking at you, Yahoo! and AOL!) This in and of itself is not the whole problem. The recipient email service must agree to respect DMARC policies. When they do, emails that say that they are from a domain, but are from somewhere else, are silently rejected.

"But wait," you say, "this sounds totally reasonable!" You're right. And wrong. And right. Let's just get this sorted out.

Pages

Subscribe to CS Crunch RSS