Developers, Are You Sure That Payment Page is Secure?
Posted: about 1 month ago (2012-04-15 20:28:52 UTC ) / Updated: 20 days ago (2012-04-29 22:06:46 UTC )
Do you know a little JavaScript and HTML? Be sure the page is safe before you put in your credit card number -- especially if you want the product and don't know the vendor.
You can audit the page's security for yourself, especially if it uses Stripe. The early parts of the post are useful to check any payment processor.
I assume you know some HTML and JavaScript. We'll audit in order of importance. Start from the top.
Security
First, are they using HTTPS? Look for the green lock, green bar or equivalent for your browser.
Short version: no lock, no buy. You can skip to the next section if the lock is green.
No lock? They shouldn't be accepting your credit card number, full stop. Anything they send can be changed in transit without detection.
If they're using HTTPS but with a red or crossed-out lock, find out why. Mouseover or use WhyNoPadlock? (type the URL and hit "check").
A self-signed certificate is unusual but okay — especially if you're buying from another developer, who may not want to pay for an SSL cert. Insecure components on the page aren't great. It's hard for sites that scripts, ads and sharing buttons are often insecure. But the best sites have no insecure components, whether it's a developer running them or not.
Insecure components are a security liability.
JavaScript and Page Source
Now let's dig in.
We'll use https://rebuilding-rails.com/payment_page.html as an example.
See that green lock? So far, so good. Next, we check the code.
View the page source. Search for "stripe". Specifically, look for this:
1 |
<script type="text/javascript" src="https://js.stripe.com/v1/"></script> |
If you can't find it, even in any sub-pages, the merchant probably isn't using Stripe. Then the rest of this post can't help you. You can check dev tools like "Scripts" or "Resources" and double-check, though that doesn't work if they're combining all the page JavaScript.
If you're really hard core, check the combined page JavaScript for "stripe" to be sure.
The Form
Now that you're sure they're using Stripe, we'll compare what the page does with Stripe's how to build a payment form tutorial to make sure they got the important parts right.
Find the form where you type payment information. You can "Inspect element" to find it in most browsers. Then in the page source, find it by the id or class.
On rebuilding-rails.com, for instance, you should look for "submit_payment" in the page source.
Names Have Power
The really important thing in this form is: name is not set for sensitive information. Your card number and expiration date should not have a 'name' in the page source.
Normally with Stripe your credit card number is in your browser and gets sent to Stripe.com, but rebuilding-rails.com won't ever see it. Name in an input says "send this to the server". So if you see <input name='credit-card-number' in the form, that means the server is getting all your information. Not good.
No name means "you can use it here on this page, but nowhere else." That's the right way.
A class is fine for your credit card number, expiration and CVC (security code). The class is how this page will find them (only in your browser). Only a name or explicit JavaScript will send to the server.
Code, Code, Code
Let's dig in deeper.
What else does the page do with your information? You found the class of the inputs for your information. In rebuilding-rails.com, it's class "card-number". So look through the page source and see where else that gets used.
On rebuilding-rails.com, the code looks like this:
You can see that rebuilding-rails.com does some kind of "local validity checks" -- that's exactly the kind of thing to check, and we will later.
Stripe.createToken() is the one thing that every Stripe site should do with your information and you want them to. That makes sure that Stripe can bill you without the site seeing your info.
And as you can see, that's it. Once you've checked the token, the page is safe and doing the right thing... As far as you can see.
Malevolence
None of this means the page is really secure. But it means the part you can see is done right, and that's a good sign. It also means they aren't getting around Stripe to steal your information... If you did a good job auditing them!
Safety
In the end, none of this replaces checking your credit card statements. But it's nice to be able to see when something is done wrong.
If it's wrong, don't risk it!
Are you the kind of Do-It-Yourself Programmer that wants to be able to audit page source yourself? Or write your own framework? My book, Rebuilding-Rails, can help you build your own web framework. Nobody audits the code as well as the guy who can build it from scratch!
BigCo New Employee Training, Inside Voice
Posted: about 1 month ago (2012-04-17 03:19:39 UTC ) / Updated: 27 days ago (2012-04-22 22:30:32 UTC )
Hello, new software engineers! Welcome to the (slightly) dysfunctional BigCo family.
Some of you are coming from Ruby, some Java. A few of you still think we should rewrite everything in Node.js. The whole company, down to the last one-off script.
Good.
We've been doing things our way for a lot of years. We know why each thing is the way it is. Being so responsible beats you down over time, you know?
We know our coworkers, the battle-tested veterans we code next to each day. We know what they'll say to each of your naive, fun, uppity suggestions, alas. We got tired of arguing.
We remember the thrill -- "we should use this for everything!" Not just about Node.js. About every new technology. We love technology, just like you do.
We know all the reasons we shouldn't do the new exciting stuff at BigCo. We know them by heart. We throw buckets of cold water on the new exciting ideas just like our managers do. We don't hate new exciting ideas. We just feel like we should be responsible.
We really do care... I really do care about this code I'm writing. I can't spend all day on it without loving it a bit -- how could I?
You're looking toward a bright future. Unfortunately I'm going to dump cold water on your fun project ideas. So will the people around me.
I hope that you'll keep just a little of that precious perspective you have today.
Most of your ideas will go down in flames. I'll shoot some of them down myself.
But just like you're too naive to know all the reasons why not... We're too cynical to see the reasons why. Secretly, underneath where I don't tell anybody, I want you to convince me that it's the right thing to rewrite everything in Node.js. Everything. Not because I care about Node.js, but because hot damn would that be fun. I want to get up and do things, do the fun things.
Please. Convince me. Just a little.
I know I'm being a stick in the mud. I have to. Still, keep watch. Find, oh, I don't know, the three or four dumbest things we do here. Remind us that they're dumb. Show us how valuable your outside perspective is.
Perspective is precious. It really is. The old-timers here have long since lost it. Yours will trickle away, day by day, until you're like me.
Convince me that those three things are stupid. It won't be hard because they really are.
And in return, I'll let you rewrite one or two of them in Node.js.
Deal?
I love tech. A lot of what let me enjoy programming again was Ruby, Rails, and building frameworks. I'm writing a book to share the love. I hope it inspires you like I was inspired.
Starting Rails programming
Posted: 8 days ago (2012-05-11 23:08:00 UTC )
I tutored Rails at CMU West for a bit. They asked me for recommendations for what the students should be doing to prepare for Rails programming.
You know, that's advice I can share with anybody. Here's what I wrote:
Sure, I can help a bit with this.
Michael Hartl has an excellent free tutorial which is already given as a resource to the students. I'd definitely recommend sending them the link earlier so that can start looking at it sooner. It really is the best thing out there. Paper books exist but go out of date frequently, cost money and are otherwise less convenient. The Rails interface changes frequently and paper books haven't done a good job of keeping up with it.
I'd suggest a programming assignment rather than a reading assignment to get started -- don't tell them how much of Michael Hartl's tutorial to read, tell them what to accomplish and they can read what they need to get it done. That's better real-world practice anyway. Similarly, Google is a fantastically useful tool for Ruby and Rails programming and every sub-topic, so tell them they can and should use Google frequently, especially for error messages. It's miraculous how well it works for about 80% of programming and configuration errors. Again, an excellent habit for later real-world programming.
I'm pretty sure you also give them a link to the online "Pickaxe Book", Programming Ruby ("http://www.ruby-doc.org/docs/ProgrammingRuby/"), which should be thoroughly adequate to their early Ruby needs. There are at least some better paper books on Ruby than on Rails. It changes less frequently. The later edition of that same book, "Programming Ruby 1.9" is also good, and Ruby 1.9 has some changes from 1.8. But overall, the older free book online is fine.
I don't have a strong opinion about "Ruby then Rails" versus "Rails then more depth with Ruby". You can do Rails programming with very little Ruby sophistication in many cases, but eventually they'll need both. I haven't seen a compelling argument that one has to come before the other, in either direction. So make sure the students have access to online references for both and you're probably fine.
This probably all sounds very handwave-y. It should. Fundamentally, the most valuable skill you can teach them here is how to learn by constant online browsing supported only occasionally by partly-outdated "authoritative" materials. Programming languages are starting to move fast enough that traditional publishing can't support them properly, now that online publishing can at least attempt it. Online API references, language references, and eventually source code are the things that stay up-to-date, along with understanding of how to browse blogs, StackOverflow and so on for what they need. Google, in turn, will lead to those blogs, StackOverflow and so on.
Some fun possibilities for small, easy-with-Rails-type programming tasks:
Put together a blog. Example recommended feature list: format post with markdown-or-something, add keywords to each post, search by keyword. Extra credit: search titles by keyword.
Write a snippet-or-something rating program (examples: submit code and rate it, submit quotes and rate them). Example feature list: users can submit core-or-quotes-or-whatever, users can vote, program counts votes, show top 10 list of most popular quotes. Extra credit: allow a user to change their vote later, make sure votes only count one-per-user. Extra-extra credit: statistical confidence so that you can decide how a new quote with four up-votes and one down-vote should compare to an old one with 35 up-votes and 20 down-votes (an interesting question, with many fun possible answers!).
Feel free to cut those projects down if they sound too ambitious. They are specifically chosen to map well to what Rails offers, but especially with extra credit they're not necessarily easy. They are also chosen to be fairly free-form, which I think is good preparation but may be a little much for beginners...
Feel free to call me at XXX-YYY-ZZZZ if you'd like to discuss further. I just thought I'd put something in writing to start out.
(Already know Rails? Trying to get better? I have a book you can buy about that...)
