The promise of a CMS is as follows:

• You can update content on your own and respond to change whenever you like
• You don’t need to understand web development or HTML
• You can deploy changes at any time

Organizations are often tied up in the subtle nuances of selecting the right CMS solution and wrangling all the content that needs to end up on the web site. In my experience, there are a series of lurking issues that apply to any CMS solution. You would do well to get a handle on them up front.

Any CMS Uses Templates

The truth of the matter is that any CMS uses templates. That’s where they derive value. Just create 3 to 5 great templates, spread them out over your site and you’re golden; or so it would seem. Templates are great as long as you make use of them today, tomorrow and the next day. A template defines the layout of the page and how it looks.

If you want to move the large photo over a smidge and embed another transparent image on the page, you’re out of luck, unless the template accounted for it. One aspect that’s often overlooked is that templates are done before you launch. The developer has gone home and already cashed their check. Game over. Changes cost money. Perhaps organizations take those changes in house or return for a refresh, either way, its time and money.

If you can force yourself to live with the decisions of today for the next six to twelve months, then you’re doing better than most. It can be tough to explain to your boss why editing content “over here” is easy, but moving content “over there” costs money and requires a developer.

Good HTML/CSS is Hard

In my years here at Pop Art, I’ve worked with some seriously good HTML/CSS developers. Experts you might say. They’ve honed their craft and work continuously to stay sharp. It’s not easy; especially with the wicked cool designs emanating from our creative folks.

These experts use complicated text editors with lots of features to help them work, but it really all comes down to understanding how those angle brackets work in a variety of browsers. That takes time to learn and attention to detail. You’re not going to be able to hold a candle to what they can do with the flimsy HTML editor provided in most CMS solutions, so you need to have the proper expectations.

One point I like to make is that the system we provide is a “content” management system. You’re managing content. You’re not managing other aspects such as layout, style and design. Content means you can change “the quick brown fox” into “the lazy dog”. If you start your expectations from that point, you’ll be headed in the right direction.

You Have to Buy Into the CMS Framework

No matter what CMS you pick (Ektron, TeamSite, Drupal, DotNetNuke, Umbraco, etc), you have to buy into that framework. The story of the CMS you picked has to resonate with you because every change from the vanilla installation costs you money and generally causes maintenance concerns over time.

For example, you’ll have to buy into the way your given CMS does the following tasks:

• Author HTML content with an editor
• Create a new page
• Update an existing page
• Retire/Delete a page
• Restore a prior version of a page
• Deploy a change to the public
• Authenticate and authorize a new editor/reviewer
• Reviewing and approving changes
• Manage large amounts of images, audio and video content
• Integrate with 3rd party solutions (Twitter, Facebook, your own systems, etc)
• Customizations, additions and enhancements
• Security updates
• Backup and recovery

Every CMS does these tasks a little different. You’ll have to find one that resonates with you and matches the way you want to operate for the next couple of years. Swapping out your CMS in less than a 24 month period should give you pause require a pretty good business case.

For that matter, how long to plan on using this CMS? In my experience, you should plan on replacing it (or installing the next version) every three to five years on the long side. New features come out all the time. The developers of your CMS might release features weekly, quarterly, or annually. You should plan for ways to take advantage of these new features in a reasonable and effective manner that suits your organization.

You Need Training

The reason you’re interested in a CMS is because you want to make changes on your own and your people don’t know how to edit HTML directly. In many cases, if they did know HTML, you would be better off installing Visual Studio and showing them how to use your favorite source control repository. But they don’t know HTML, and its not practical to spend all that time learning it, so that’s why we’re here in the first place.

Since you’re people don’t know HTML, its probably fair to say they also don’t understand web development in general. That’s fair, they’re probably focused on delivering your products and services to your customers. You can’t be all things to all people.

So, the salient point here is that you’re people are going to need training. They’re also going to need mentoring and standards enforcement. It’s just too easy to deploy a page using Comic Sans font after a couple of months. Furthermore, when you encounter turn over, you’re going to need more training. You should account for these costs in time, money and productivity.

Patches Should be Installed

Every system worth installing and running for a couple of years will have patches. The developers of the CMS will discover flaws, fix them, and make a patch available to you. You’re expected to install the given patch before (1) the bad guys discover you run the given CMS and (2) your system is vulnerable because you haven’t installed the patch yet.

This isn’t a tough thing to do, but it does consume time and requires a consistent process. You should have a plan for installing these patches as they become available. Don’t be ignorant and think the system you launched two years ago is as secure as it was two years ago.

Whoops!

You’re likely to deploy something to your public site that you need to fix ASAP. Its the nature of a CMS. It’s so easy to deploy changes, even when you have a serious reviewer/editor policy in place. Something will happen where you say “Whoops! We need to fix that ASAP.”

You should have a plan in place that states how to handle changes that need to happen immediately; even if it’s just a service level agreement (SLA) with yourself. How are you going to restore the previous version of the page? Is that even possible? How often can you publish changes? How long does it take for them to appear. These are all questions that you should know the answer to before you need to execute them.

Summary

So, to be clear, content management systems are good, but make sure you’re aligned with what they can do. Don’t get too caught up in those common challenges of gathering copy and providing feedback on the graphic compositions without spending sufficient time understanding the total cost of ownership and the capabilities of your CMS.

• Awesome online banking
• Free ATM withdraws (no matter which one you decide to use that day)
• An iPhone app
• Check deposit at home (on your scanner or iPhone)
• Customer service that can’t be beat.

This is how to do business on the web.

Case in point: I use online bill pay. I paid someone in September and I just got a nasty-gram about not paying my bill. I was able to sign into USAA, see the bill I paid, find and click a button for “payment inquiry”, select one radio button, one drop down list item and click submit. This is something I do once a year on average and it was super easy to figure out.

From that simple action, I set some grand wheels in motion. USAA is going to contact me in 24 hours and they’ll probably contact my nasty-gram author on my behalf (This has happened before). Make no mistake, that’s how to do business on the web.

Greg didn’t coin the term. Wikipedia says Ronald Regan used it and others before him. The term indicates you should trust what people are doing or saying, but verify it nonetheless. I had one such opportunity recently and I’m sorry to say that I failed miserably.

The check-engine light went on in my car last Friday. I took it to a repair shop early Saturday morning and left it there. They called back in a couple of hours with an estimate to fix this, that, and the other thing. I winced, but said sure, go ahead. This is over the phone, mind you.

They called back a few hours after that and said there’s one more thing. I asked for the total, winced again, and said sure, go ahead. Again, on the phone. This time, the part was offsite and the delivery truck couldn’t arrive until Monday. No worries, we had the spare car thing worked out.

I get a call on Monday. The truck arrived, but not the part; weird. Apologies were offered by the repair shop, but I say, no problem, I’ll get the car on Tuesday.

Tuesday arrives and I get a call in the late afternoon. The car is ready, please come and get it. I was in a meeting, so I learned this by listening to the voice-mail the kind man left on my phone. I leave work, pick up the H-man from daycare, drive home to get the wife and drive over to the dealership.

We’re less than a mile from the repair shop when I notice I have another voice-mail from them. In this one, the kind man explains that they close at 6pm, but I have until 8pm to pick up the car before the gates close. He explained that I can call him back and pay over the phone if I plan on picking up the car between 6pm and 8pm tonight. He also says the amount on the call. It’s two times the amount he quoted me on Saturday. I’m instantly furious.

I park and walk into the repair shop, the service desk directs me to the cashier. The cashier grabs my file and asks for the 2X amount. I respond politely with “I can’t pay that amount”. She furrows her brow, understandably at 15 minutes to closing time, and returns with the service desk representative.

I ask for the amount he quoted me over the phone and he points to the 2X amount. Again, with all the politeness I can muster, as if I’m speaking to my grandma, I ask if he quoted me the 1X amount. He scratches his head and explains, it’s all right there. His document identifies who called, when they called, who they talked to, and the amount of the estimate.

I’m baffled and I begin to doubt myself. But I’m also resilient and tell myself that if the man estimated 2X for the repairs, I surely would have declined and pursued other options. It’s an old car and we’re thinking of trading it soon. I was very sure, even now, that I asked him for the full amount. I was also sure that he never said anything resembling 2X in response to my question about the full amount. Under no circumstances could 1X be mistaken for 2X, even on a bad phone connection.

He explains that he’ll have to get the manager, so he’s off and I stand around for a few minutes perusing the repair sheets he left on the desk. It’s all right there on the documents, how could two parties be so far apart on an essential matter?

A large burly man in a nice looking suit emerges from the back offices, introduces himself and asks me about my problem. I explain the situation and he takes it all in. Then he turns to the service representative and repeats what I said. Then he turns to me and repeats what the service manager said. Then, he repeated what the service manager said two more times, then he repeated what I said one more time followed by repeating what the service manager said and ending with a finale of “in all of my 20 years here…”, you get the idea.

Those of you who have met me will know that I have a pretty good face for these types of things. I’m not too pretty, it’s hard to tell what I’m thinking if I don’t let you and the whiskers don’t hurt either. Plus, for whatever reason, I decided to wear a nice button-down blue shirt and dockers today. I looked professional and not like some punkass kid trying to skip out on part of the bill. Plus, I sincerely felt that I was right.

In any case, 2X is a lot of money to screw up.

The manager explains that the documents with the who-what-when-and-how-much are legal documents in the state of Oregon. I don’t bite. I’m not in any mood to debate the matter. My position is clear and so is his. No quick, witty comment or sly argument from me is going to win him over. My only rebuttal is that estimates over the phone are inherently prone to these types of mistakes. He picks up on this nibble of an argument and thoroughly explains that in all his years, they’ve never had a problem like this. Again, I refuse to argue the point. It’s futile to do so.

So, he explains that he has to go to the general manager of the repair shop. Again, I’m left alone near the cashier’s desk. This time for about 15 minutes, the standard time one would sit in an office of a car dealership, waiting to see if the manager would accept your offer on the car. The old wear-you-down trick.

In the mean time, I think about what to do. I really do like jury duty. It’s a lot of fun. I wonder of small claims court would be as much fun. There’s the anxiety of getting over the problem, the possibility of losing my first case (I was a business law major until I took my first computer science course in college) and just the general hassle. Plus, I’m beginning to doubt myself. Did that guy really tell me the full amount on the phone and I just wasn’t paying attention? I decided that they would offer to split the difference and I’d accept it.

Damn!

So, the manager returns, right on time. He repeats what I told him; then he repeats what the service representative said one more time. Finally, the manager then says the general manager offered to split the cost with me. I asked if he was offering me 1.5X and I’m corrected. The general manager is offering it and the manager is merely saying it to me.

Whatever.

I put up the stop hand and said, I think this is the best solution for both of us. The manager knows to stop selling when the sale is over, so he turns to the cashier and firmly states that this customer is going to only pay 1.5X of the amount on the bill.

I’m relieved that the issue resolved, yet still disappointed that it happened at all. I’m out 0.5X, but I do have a few extra repairs on the car. Upon further review, I think some of the repairs are a little suspect. For example, my car is perfect on oil. It doesn’t burn oil and my drive way is void of any oil spots. Why didn’t I think of that when the guy said the oil pan gasket was leaking on the phone? Arrrgg!!

This is when Greg’s term “trust, but verify” really became clear to me. My super smart wife pointed out that I could have asked him to e-mail me the estimate. I also could have asked him to call me back and leave the full estimate as a voice-mail on my phone if they were email-impaired. The amount of money is large enough and use of my car is important enough that I really should have been more diligent. I should have verified the estimate instead of just trusting what I heard on the phone.

Rats. Well, they say the awesome people can tell you all about their mistakes and the incompetent never see their own mistakes. Here’s one more thing on the pile that I can learn from. I’m going to be riding the “trust, but verify” horse into the ground for the next couple of weeks. Apologies, in advance, to all my teammates.

I don’t explain the identity of the repair shop or the amount here because you’re going to trust, but verify next time right? So, in that case, it doesn’t matter who I dealt with.

Now This Is New

As a technologist, I’m often asked to do something that I’ve never done before and have no specific competency in performing; tasks which I’m completely unqualified to execute.

The more palatable way of saying the same thing is:

As a consultant, technical lead, solutions engineer or a business analyst, I’m given challenges that require me to identify the “how” part of the solution in addition to the “what”. My job requires me to learn new things today so I can leverage that knowledge when I learn something new tomorrow.

It seems odd to lay it out there like that, but that’s what I deal with on a regular basis and I absolutely love this part of my job. I use the skills and experience I’ve gained over time to tackle new challenges. There is no manual that describes how to assemble a new business process or software application for my clients. I take a guess at what has a good chance of working, test it, and then make a decision to trash it and start over, optimize it, or brush off my hands and ask for what’s next. I love innovation.

Sometimes the new challenges are just clones of old problems cloaked in a new buzz word (social media anyone?). I couldn’t work in a job that does the same repetitive task every day. I’d get yelled at too much for trying to optimize it. That’s just how I work; I can still respect those that love repetition. That’s just how they’re wired; but it ain’t me.

Here are a couple of tips for how to execute a task that you’ve never done before:

Communicate

You have to be transparent. Look for ways to express the work item you’re solving now and what the queue looks like for the hours or days ahead. The worst possible action you can take is to “go dark” for a period of time and head down the rabbit hole without telling anyone. Chances are that one or more people know various bits and pieces about the proper way to perform your task. You have to elicit that information wherever it exists. Sometimes I might even ask your mom.

Search

Google, Bing, Yahoo, email, shared folders on the network, books, magazines, subject matter experts, Word documents, opinion polls and the backs of Cracker Jack™ boxes. You have to do some leg work. The reason we’re asking you to do it is because we don’t want to. Learn how to use advanced search engines queries to search for web pages after a certain date, from a specific URL, contain a specific phrase or don’t contain a certain keyword. Don’t show up empty handed without a really good sob story of how you worked super hard and didn’t find anything even close to what you were looking for.

Show Your Work

Its one thing to rattle off what you did and let your communication chops shine, but you need to turn in your homework too or we might call your bluff. In addition to the correct answer, write down the dead ends you went down or where the trail went cold. This lets us know you’re thorough and you’re thinking at the appropriate depth. I know I gave you a task that you’ve never done before, so I need to see some warts along with the elegant answer or I’ll feel like I might get blind-sided later by something you didn’t consider. I need to see some opposing views that give flavor and context to the situation. Most importantly, you’re going to forget some details in 3 to 6 months, so just write it down now while its fresh.

Learn my Language

So you’re given a challenge and you solve it. Now it’s time for the final report. You have to tailor your story to my language. You lose points if you make me feel lost or beneath your greatness. You earn bonus points if the story keeps my interest and I can explain key points to my constituents later when you’re not around. This story you tell depends greatly on who I am. You might have to explain it to my constituents too, and they might not speak the same language as me.

Listen

Make a conscious effort to listen instead of waiting for the other person to pause so you can start talking again. Read that previous sentence again a few times.

Know the Down and Yards to Go

That’s American football parlance for knowing the objective. Your end game has to be aligned with the stakeholders, even the mystery stakeholder that pops up unexpectedly at the end of the project. Don’t be surprised, you know it’s going to happen. Done means done. Do you know what done is? You better have a document to prove it because I’ll choose my opinion over your opinion any day of the week.

Have Fun

If you’re not enjoying the work, then get out or change your attitude. You have to find something interesting in the challenge to keep you motivated and smiling through the day. Otherwise, I’ll pick up on your loathing and I’ll start to reflect your demeanor. This isn’t about faking a smile; you sincerely have to be the type of person who can motivate yourself and others. You have the ability to be the bright spot of my day. Do your best Tony Robbins performance and set the positive tone with your sheer will power.

We’re the second largest Mac development shop in the world behind Apple.  We have more Mac developers than anybody except Apple.

Who is “we”? Well, Microsoft of course!

This seemed counter-intuitive at first, but after you consider everything Microsoft does and who else might possibly be capable of holding second place in the measurement, it all fits together. Now I can feel just a little more smug developing Microsoft .Net applications on my MacBook Pro.

Don't Get Pinched by JavaScript Injection Attacks

A little over a week ago, I described Cross-Site Request Forgery attacks and how they can damage your site with just a simple website request using any modern browser available today. This time, I’ll describe another type of JavaScript attack that can cause equal harm to your site.

Lots of sites, including blogs, accept user input. Visitor are invited to enter values into fields and click a button to submit the web form. This might be a simple as leaving a comment on a blog or purchasing a t-shirt with a stolen design.

The fundamental rule in website development is to NEVER TRUST USER INPUT. To say that another way, you should always assume the data on a web form is intended to harm your site. The bad guys have some clever ways of doing this with a plain ordinary browser; they don’t need elaborate tools to try this type of attack. Furthermore, you only need to fail in one spot on your website and you’re done. The shared computer at the local coffee shop will do just fine for their attack vehicle.

Let’s take a look at a simple blog comment. Imagine that your blog contains a form that takes a name and a comment. You’re expecting visitors to enter a value in both fields and click a button. You might even implement some validation to make sure that both fields have a value before the form can be posted.

Now let us put the fundamental rule described above into play: You should never trust user input. While the form will warn the user when the field is missing, visitors can still enter gibberish and there’s little you can do to stop them. It’s a web form, they’re on the website you gave them, and that’s why you moderate comments on a blog. While it’s healthy to see comments from people who agree and disagree with you, you still try to keep the signal-to-noise ratio at a reasonable level.

JavaScript injection attacks are one of the primary reasons should never trust user input. Let’s suppose the blog saves the web form fields to a database. When subsequent visitors request the blog page, all of the comments are shown in chronological order under the blog post. Pretty typical so far, right?

Herein lies the rub: suppose instead of a comment, our nefarious visitor entered the following JavaScript:

<script>alert('hello world');</script>

Everyone who visits the blog page containing the previous JavaScript is going to see a message box that say’s “Hello World”. This is an example of one of the most dangerous attacks on the web today. The attack is easy to try and you only need to miss one place on your entire web site to be vulnerable.

If a visitor is able to get your web page to execute the their JavaScript, they can do some really bad stuff. For example, they could write a JavaScript that let’s them impersonate you and perform every task you can do on the website. All you need to do is visit the page (on your own website) that contains their JavaScript. You’re likely to read the comments on your blog, so that part is fairly easy, right?

Here’s how they do it: After you sign in, lots of web sites will issue a temporary token to you in the form of a cookie. Your browser sends this cookie along with each page request in order to validate who you are. If you close your browser, you might have to sign in again and get a new cookie. Alternatively, the website might have issued a more durable cookie. In this case, the website might have instructed the browser to store the cookie for several days. This is how Google keeps you signed in for several days.

Since JavaScript has access to cookies, the JavaScript written by the bad guys can be written in such a way that it sends your cookie to their website. They’ll be waiting for cookies to come in and looking for a juicy one that has a lot of authorization. Once they have it, there’s nothing much you can do, short of turning off the web server. They own your site. Furthermore, there’s no email notification of this event. You won’t know about it.

Scary stuff huh?

You need to protect your site from these types of attacks. The best practice is to process every byte from a visitor. You should never show raw content provided by an untrusted user. In this case, untrusted users are everyone but you. Since your at it, why not protect the site from yourself too, just to be sure.

One way of implementing this best practice is to encode fields before they are displayed on the web page. Encoding text will convert turn a “<” character into to safer eqivalent of “&lt;”. The JavaScript example above will appear like this:

<script>alert('hello world');</script>

This encoded JavaScript will not execute in the browser. If you’re aware of the potential danger here, you’ll delete the comment immediately and review your website for holes. Again, you only have to forget to plug one hole and they’ve got you.

JavaScript injection attacks are a nasty threat to any website that accepts input from visitors. The bad guys already know this, so training the good guys is how we’re going to plug these holes. No doubt they’ll come up with more clever ways of bring down you’re site, so keep you’re skills up to date and spread the knowledge.

Let’s start with some agonizing realities:

• About 50% of software development projects fail
• About 60% of off shore projects fail, but they’re cheap, so people keep trying
• Agile methodologies improve success, yet about 30% of those projects fail

Patrick lays out some fundamental principles that resonated with me. These principles tend to leave deep scars when you deviate from them. I encourage you to listen to the podcast the next time you’re on a drive, riding the bus, or washing the dishes after a meal. Just to whet your appetite, here are some of the high points.

Status
No status, no check. The team needs to communicate status to the project manager. If you don’t report on your status, Patrick assumes you were not working and fires you for job abandonment. What doesn’t get checked doesn’t get done. Most people do a status check, but not until late in the project when things are hard to fix. Do them early and often.

Never Assume
When you assume, you make an ass out of you and me. When you make a statement and have no proof, then I’ll pick my opinion over yours any day of the week. You must have evidence to back up your statement.

Don’t Be Wishful
A project is not done until after the coding is done, followed by *lots* of other things. When Patrick asks if something is done, the answer is either “yes” or “no, and this is why”. There are no “yes, buts”. Everyone needs the same definition of “done”. If you haven’t confirmed it with the customer, then it’s not true.

No Spec, No Estimate
Patrick will happily work for you from now until the end of time to rewrite, redesign, or recode anything you ask of him on a T&M basis. A lot of people want a fixed bid price when they give a T&M spec.

Here’s a great analogy for when a client might bring you onsite, walk you through their existing application, explain what they didn’t like about it, and then expect a fixed price bid proposal for the new system:

Suppose I asked you to build my next house. I show you my current house, and explain what I hate about the doors, the stairs and windows. Can you give me a fixed bid on my new house? Of course not. You only know what annoys me. I haven’t told you what type of materials I do like or what type of building would make me happy. Software applications are a close analog to this.

And here’s what I found most inspirational in Patrick’s statements:

“If we can reign in that failure rate, so that we fail just 5% of the time, think about the productivity boost to the country and the world.”

The techie guys gave it an acronym: CSRF, because that’s one of the things that give them pleasure. All spelled out, CSRF looks like this:

Cross-Site Request Forgery

Myself: Sounds like a big technical mumbo-jumbo thing. Do I really care?

Me: Well, would you normally change the email address of your account to that of a hacker that lives three states over and you’ve never met? Probably not.

Myself: Ok, I’ll take the first bite, but don’t lose me, got it?

Me: Sure, no problem. Bad guys can try to get your information or trick you into doing something you wouldn’t ordinarily do through a CSRF attack. I’ll lay it out so you can see how it works. It’s not that complicated.

Me: Let’s say you open your favorite browser and surf away like you normally do. You find a site that you’ve never been to before, but it looks interesting enough so you sign up for a newsletter. You enter your email address and click the submit button. Wham! You’re done.

Myself: Damn! Done, eh?

Me: Yep. Those little buggers are quick.

Myself: So, what happened?

Me: Ok, let’s replay that attack. You browsed a site you didn’t know, or have reason to trust, for that matter. When you submitted that web form, you didn’t know it was actually posting information to your favorite social media website. This is to say, directly from your browser to the social media site. It wasn’t really adding your email address to their newsletter list as you assumed.

Myself: Well, that’s weird, but so what?

Me: I’ll say this again a different way: instead of posting info from your browser to Site A, it was actually posting info from your browser to Site B, where A is the hacker’s site and B is your trusted social media site.

Myself: Web pages can do that?

Me: Yep, it’s just an HTML <form> tag, you can point them wherever you want.

Myself: Ok, so if this is true, then why isn’t the sky falling right now?

Me: Well, there are ways to help prevent this attack, plus it’s somewhat new in terms of main stream threats, and most importantly, not every hacker in the world is out to get you at this very minute.

Myself: So what did it post to my favorite social media website and why do I care?

Me: Well, it posted your email address.

Myself: Great! I got news for you. My email address is already on my social media website. I don’t think I’ve lost much.

Me: Well, it posted some other stuff too. Actually your current email address isn’t what you think it is.

Myself: Uhmmm, go on.

Me: The hacker took a chance that you might actually be logged into your social media website at the time you submitted the form on his site.

Myself: Is this like the phishing thing I’ve been hearing about?

Me: Kind of, but let’s not muddy the waters by introducing new terms.

Myself: Fair enough, keep going, forget I said anything.

Me: Ok, so you were logged on to your favorite social media website when you submitted this form on the other site. This means that the social media site makes several features available to you like updating your status, posting a photo or interacting with a friend. You can only do that stuff when you’re signed in, right?

Myself: Yep. Got it.

Me: The hacker’s site posted your email address to the CHANGE EMAIL ADDRESS FORM on the social media site. In addition to your email address, he posted his email address as the new email address. When your browser posted that form, you sent the cookies and everything else along for the ride to the social media site. It looked like a totally legit request from the point of view of the social media website. All the form fields lined up and there was no reason to suspect it.

Myself: Well that little piece of..

Me: Hold on, G rated audience here.

Myself: Sorry.

Me: No worries, you’re right to be upset. You see, the social media website should have been anticipating this type of attack.

Myself: Huh, go on.

Me: Well, because this type of attack works in any browser, it’s very likely that it will happen.

Myself: So, how can CSRF attacks be prevented?

Me: Well, one way is with the anti-forgery tokens inside Microsoft ASP.Net MVC.

Myself: One sec, you said you wouldn’t get technical.

Me: I’m not; it’s just a brand name, Microsoft ASP.Net MVC. You like brands don’t you?

Myself: Well, yeah. Sorry.

Me: No problem. Ok, we were going over anti-forgery tokens. Let’s say your cookie contained a long number. Let’s call that number a GUID.

Myself: Oh! Oh! Oh! A GUID is a globally unique identifier, right?

Me: Yes, very good. So the cookie contains a GUID, or a long number, right?

Myself: Yep. GooooooooooID. It’s fun to say.

Me: Focus please.

Myself: Sorry.

Me: Ok, the programmer who built the web form for the social media website’s change email address form could have placed another long number, or GUID, in the web form as a hidden field. The person filling out the form doesn’t need to know about the field, so it’s hidden and sent back to the web server when the form is posted. Just to clarify, the web form consists of all the fields you can see, plus the values in the cookie and the token value inside the hidden field.

Me: When the web server receives a post, it evaluates posted fields and looks for normal problems. Of course it makes sure required fields are populated and stuff like that. The web server also performs a mathematical computation on the two GUIDs that it received. One GUID came from the cookie and the other from the token.

Me: It’s really hard for a hacker to have both numbers. The hacker can’t successfully guess the numbers either. They might as well guess your password. If the numbers don’t jive, then the web server stops processing the request, because it’s probably fraudulent. In the first case where the hacker won, they got you to give up your cookie. However, they wouldn’t be able to post a valid token because that second number changes all the time. Wait, you’re using a complex password right?

Myself: Um, yeah sure.

Me: Ok, we’ll talk about that one next time. For now, it’s just important that you’re aware of where you’re surfing on the net and to think about your actions. It takes everyone to help secure the Internet.

Myself: So, maybe I do need a stronger password, but if I understand you right, you’re saying that developers can help protect the sites they build from this type of shenanigans by using the anti-forgery tokens inside Microsoft ASP.Net MVC right?

Me: Yep. It’s really easy.

Myself: Cool, thanks for explaining how a CSRF attack works and how to prevent them.

Building software involves rational thoughts. This presumes the point that you have a compelling interest in building software. I suspect that if you’re reading this blog post, then you have some stake in the topic. With a few pointers in the right direction, you too can be a contributing member of the software development team.

Let’s start with a fresh project, contrived especially for us. Software automates tasks that you might otherwise do with pen and paper, right? So begin by asking, or more importantly, writing down some questions. Here’s 20 to start; all related to the pen.

1. Who would hold the pen?
2. Where does the pen belong?
3. How many pens are there?
4. What color is the ink in the pen?
5. What do you do when the pen runs out of ink?
6. What if its too dark to see what you’re writing?
7. How can you tell if the pen fits your hand?
8. How long do you have to use the pen?
9. Who is protecting the pen from thieves who like to steal pens?
10. What happens if you lose the pen?
11. Are you using the right pen?
12. What kind of pens do others use?
13. Should your pen have a clip for your pocket?
14. Should you be wearing a pocket protector in case your pen drips ink?
15. Is a clicker pen better than a pen with a cap?
16. Why is a pen better than a pencil?
17. Can this pen write upside down?
18. How long should you expect this pen to last?
19. How much do I have to write to make a profit?
20. Should my pen make check marks from left to right, or from right to left?

Building software is a lot like this type of interrogation, rationalization, recollection from prior experiences that went well or poorly and the overall willingness to ask questions. You might apply the questions about the pen to a web site, an order form, or a new iPhone application. Curiosity is a good, succinct requirement for building software. If your goal is to build good software and your curious about your subject matter, you can be a valuable member of the project team.

It’s not really about deciding between ”for loops” or “do while loops” or even about calling complex database queries. Don’t get me wrong, we still do that and gosh, its one of the coolest things I do, but today’s technology makes that such a sweet and pain-free experience that the real job is understanding your problem domain. This has always been the problem domain. You reach an understanding of the problem domain by asking questions and writing down answers. You don’t need to be a developer to have an impact.

Lastly, the document that asks and seeks to answer these questions really ought to be written in the domain of the given business problem. It won’t have any technical implementation details, so by definition, anyone familiar with the business should be able to read this document. Again, this presumes you have an incentive or interest in reading documents. If you dislike documents, contracts, processes or business rules, then you’ll probably self-select out of the situation. If you’re wondering where to get started, imagine that your the prosecuting attorney on a case and the business problem is in the witness chair. What questions would you ask them?