Security for Web Developers Released!

My Security for Web Developers book is released and ready for your review! I’m really excited about this book because I was able to explore security in a number of new ways. In addition, I had more technical editor support than just about any other book I’ve written and benefited from the insights of a larger than usual number of beta readers as well. Of course, the success of this book depends on you, the reader, and what I really want to hear is from you. What do you think about this latest book? Do you have any questions about it? Please feel free to contact me about it at John@JohnMuellerBooks.com.

Of course, I’m sure you want to know more about the book before you buy it. Amazon has the usual write-up, which is helpful, but you can also find insights in the beta reader request for this book. Make sure you also check out the blog posts that are already available for this book in the Security for Web Developers category. These value added posts will help you better understand what the book has to offer. More importantly, you get a better idea of what my writing style is like and whether it matches your needs by reading these posts.

Make sure you also get the source code for this book from the O’Reilly site. I highly recommend using the downloadable source, rather than type the code by hand. Typing the code by hand often leads to errors that reduces your ability to learn really cool new techniques. If you encounter errors with the downloaded source, make sure you have the source code placed correctly on your system. When you get to the O’Reilly download page you also find links for viewing the Catalog Page for this book and reporting Errata.

Have fun with my latest book! I’m really looking forward to hearing your comments. Thank you, in advance, for your continued support.

 

Considering the Authentication of Credit Cards in Web Settings

While I was writing Security for Web Developers I considered a great many security scenarios that web developers (and those who work with them) have to face. It always seems as if the hackers are two steps ahead. Of course, one of the biggest problems is static technology. For example, the Credit Verification Value (CVV), a three or four digit addition to a credit card number, is supposed to help safeguard the credit card. It doesn’t appear as part of the card data accessible through the magnetic strip or the chip. The CVV is actually printed on the card as a separate verification for venues such as web applications. The only problem is that this number is static—it remains the same for however long you own the card. Therefore, once a hacker discovers the CVV, it no longer provides any sort of security to the card owner. Interestingly enough, some sites online will sell you both credit card numbers and their associated CVV. The hackers win again.

A solution to this problem is to change the CVV periodically. Unfortunately, trying to change a printed CVV is impossible without replacing the card. One possible way to overcome this problem involves the addition of an e-paper space on the back of the card that would allow the credit card companies to change the CVV, yet keep it out of the magnetic stripe or chip. A lot of devices currently use e-paper, such as Amazon’s Kindle. The technology provides a matte paper-like appearance that reflects light similar to the way in which paper reflects it, rather than emitting light like an LED does. The difference is that e-paper is often easier to read.

Oberthur, the inventor of the Motion Code technology used to create the updated CVV, isn’t saying too much about how the technology works. There must be an active connection between the card and a server somewhere in order to update the CVV once an hour as specified in the various articles on the topic. The only problem is in understanding how the update takes place. If the technology relies on something like a Wi-Fi or cell connection, it won’t work in rural areas where these connections aren’t available. Even so, the technology does promise to reduce the amount of fraud that currently occurs—at least, until hackers find a way to thwart it.

What is your feeling about credit card data protection? Does Motion Code technology actually provide a promising solution or is it another dead end? How do you deal with potential fraud when creating your applications? Send  your ideas to me at John@JohnMuellerBooks.com.

 

Web Apps and Outdated Software

A particular problem that developers face when creating web apps is that users are notoriously lax in updating their software. A problem piece of software may make it easy for a hacker to gain access to the system. In some cases, the user will blame your application because it depends on software that could be outdated on the user’s system. A recent InfoWorld article, 10 old, risky applications you should stop using, brings the issue to light. Many of these pieces of software see use in Web apps. You may think that the user will rely on the newest version of the software, but the user may, in fact, have a piece of software that’s several generations old, yet runs your web app just fine.

Most of my web development books at least hint at the issue of dealing with outdated libraries, APIs, and microservices. Security for Web Developers makes the strongest case for verifying that web apps rely on the latest third party products to ensure the web app is less likely to cause a security breach, but both HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies discuss the issue as well. The point is that you need to know that a user is relying on the latest software if at all possible. Otherwise, you may find your web app blamed for a security breach actually caused by another piece of software, such as a web browser.

The fear that many users have is that your web app will stop working if they upgrade to newer software. This fear has a strong foundation in broken applications of all sorts in the past. The problem can become quite severe. Looking at the InfoWorld article, you find several interesting bits of information. For example, many existing applications rely on Microsoft XML Core Services 4.x, despite the fact that the software is no longer supported and represents a huge security hole that hackers are only too happy to exploit. If the user removes this software to keep their systems safe, they may also have to give up on one or more mission critical applications. Testing is the developer’s tool of choice in this case. Make sure you test your web apps with the lasted software and then publish the results online. Keep users informed of potential problems and your plan for fixing them so that they can continue making required updates to keep their systems safe.

It may not be entirely possibly to fix every security problem immediately. The fact is that software today is so interdependent on every other piece of software that even when your web app has fully supported underpinnings, the software you depend upon may not. The dependencies cascade in convoluted ways that make it entirely possible that a hacker will find a way to breach your application despite your best efforts. Consequently, you not only need to maintain a firm grasp on testing, but also of potential problems with the software used to reduce your development effort and make the application perform better. In short, you need to have a contingency plan in place for those times when a hacker finds a way to break your web app because a determined hacker will fine a way.

Outdated software is the bane of developers everywhere, yet users remain clueless as to how much damage they invite by not making required updates. One of the issues that I’m constantly striving to solve in my books is this whole concept of software dependency and how it affects application reliability, security, and speed. If you find that some of the materials I’ve put together are especially helpful (or possibly not helpful enough), please let me know about them at John@JohnMuellerBooks.com. I want to be sure that the security features of my books really do help you past the whole outdated software issue because users really won’t be much help at all.

 

Getting Your Favorite Application on the Web

The world where users sit in front of a desktop system all day managing data is going away. Users won’t settle for just sitting in front of a computer any longer—they want to compute using their smartphone, tablet, and any other device that comes to mind. A time is coming when a user who has an idea in the middle of the night will talk to the alarm clock, which will make the required changes while the user goes back to sleep. For today, however, users appear content to make their changes using the interesting array of technologies that are already available. Who knows, perhaps someone out there is actually using their Apple Watch to make changes to a report they need to give in a few hours.

The point of writing HTML5 Programming with JavaScript for Dummies, CSS3 for Dummies, and Security for Web Developers is to make these technologies available desktop developers who have become a bit nervous about the future of their favorite language. It’s unlikely that any developer has failed to observe the movement from the desktop to everywhere else. Fortunately, many languages you use today will compile to JavaScript. All you really need is the right tool to make the move. In fact, a recent ComputerWorld article discusses six of these tools in enough detail for you to at least gain an appreciation of what they can do for you. Therefore, it’s possible for you to move some of your favorite applications to the new reality of computing. The applications may run a bit more slowly, but they should work well.

Of course, some developers are in denial. They point out the reams of code already in existence and how organizations around the world will refuse the give them up. The organization may very well refuse to give the desktop application code up, but the user has already done so. Applications require willing users. In the absence of willing users, no mandate will force anyone to use a broken application. Users will find a way around the mandate and it’s likely that no amount of coercion will force users to comply with the dreams of developers who have stuck by the desktop system.

We’re talking average users here. Any user who uses applications for mundane tasks that long ago became the essence of modern business. Developers will still find people who actually do need the power of desktop applications. it’s entirely possible that both engineers and scientists will continue to use desktop applications far into the future, but these applications are at the periphery. The days of the desktop are gone—it’s time to get used to the idea that your next application will probably be web-based and that you’ll use a language appropriate for that venue to create it. In the meantime, you do have options for moving your existing code. Let me know your thoughts about applications that run anywhere on any device at John@JohnMuellerBooks.com.

 

Beta Readers Needed for Security for Web Developers

Are you worried about your web-based applications, web services, and other web endeavors? Web security becomes a more serious problem on an almost daily basis as witnessed by the surge of truly serious hacking events, so developers are looking for a reference they can use to avoid becoming yet another statistic. Many books give you good advice about part of the security problem or provide solutions so generic they aren’t truly useful. Unfortunately, attacking only part of the problem leaves you open to hacking or other security issues. Developers also need specific advice because general advice will no longer meet current security needs. Security for Web Developers provides specific advice for the HTML5, JavaScript, and CSS developer on all areas of security, including new areas not found in any other book, such as microservices. Consequently, you get a complete view of security changes needed to protect web-based code and keep its data safe. Here’s what you’ll see in this book:

  • Part I: Developing a Security Plan
    • Chapter 1: Defining the Application Environment
    • Chapter 2: Embracing User Needs and Expectations
    • Chapter 3: Getting Third Party Assistance
  • Part II: Applying Successful Coding Practices
    • Chapter 4: Developing Successful Interfaces
    • Chapter 5: Building Reliable Code
    • Chapter 6: Incorporating Libraries
    • Chapter 7: Using APIs with Care
    • Chapter 8: Considering the Use of Microservices
  • Part III: Creating Useful and Efficient Testing Strategies
    • Chapter 9: Thinking Like a Hacker
    • Chapter 10: Creating an API Sandbox
    • Chapter 11: Checking Libraries and APIs for Holes
    • Chapter 12: Using Third Party Testing
  • Part IV: Implementing a Maintenance Cycle
    • Chapter 13: Clearly Defining Upgrade Cycles
    • Chapter 14: Considering Update Options
    • Chapter 15: Considering the Need for Reports
  • Part V: Locating Security Resources
    • Chapter 16: Tracking Current Security Threats
    • Chapter 17: Getting Required Training

This book is designed to meet the needs of a wide group of professionals and non-developers will definitely find it useful. If your job title is web designer, front end developer, UI designer, UX designer, interaction designer, art director, content strategist, dev ops, product manager, SEO specialist, data scientist, software engineer, or computer scientist, then you definitely need this book. I’d love to have your input on it as a beta reader because this book is meant to meet your needs. However, even people with other job specialties should send me an e-mail about reading the book because other perspectives are most definitely helpful!

As always, I want your input to help avoid making any errors in the book. If you have any desire whatsoever to work with any sort of web-based code, please contact me at John@JohnMuellerBooks.com. In consideration of your time and effort, your name will appear in the Acknowledgements (unless you specifically request that I not provide it). You also get to read the book free of charge. Being a beta reader is both fun and educational.

 

Review of HTML5 Step by Step

Microsoft has thrown developers yet another curve—Windows 8 will rely on HTML5 and JavaScript for a programming interface. The revelation has many developers horrified. For me, it means updating my HTML and JavaScript skills, which was one motivation for reading the book reviewed in today’s post. HTML5 Step by Step, written by Faithe Wempen, provides a quick method of getting up to speed on HTML5.

This book is designed to aid anyone who wants to know how to work with HTML5, which means that it starts out extremely simple. The book avoids the ever popular Hello World example, but the example it does provide is small and easily understood. The chapters don’t remain simple, however, so even if you have some experience with HTML, you can use this book to update your skills. You’ll likely want to start around Chapter 3 if you are experienced and skim through the material until you come to something unfamiliar, which could happen relatively fast given the changes in HTML5.

HTML5 Step by Step is light on theory and reference information, but heavy with hands on experiences. It relies on using Notepad as an editor, which may seem like an odd choice, until you read the “Why Learn HTML in Notepad?” section of the Introduction. The author’s reasoning is akin to the same reasoning I would use, which is to make sure that the reader types everything and understands why a particular element is required. If you really want to get the most out of this book, you have to do the exercises in Notepad as the author suggests. Otherwise, I guarantee you’ll miss out on something important. Faithe has made a great choice of teaching aids in this case.

Chapter 1 is most definitely designed for the rank novice. It even shows how to set up the examples directory as a favorite in Notepad. However, unlike many books, the rank novice should read the book’s Introduction because Faithe does provide some needed information there, such as the “Understanding HTML Tags” section.

Chapter 2 gets the reader started with some structural elements. Faithe covers everything that the reader is likely to need for a typical starter Web page. I wish that the chapter had covered <meta> tags in a little more detail, or at least provided a table listing them, but this book does have an emphasis on hands on exercises, so the omission isn’t a glaring one. As an alternative to including the information, an update could provide a URL that lists the tags so the reader knows where to go for additional information.

By Chapter 3, the reader is formatting text and starting to make the sample site look pretty. I really thought Faithe did a nice job of moving the reader along at a fast, but manageable pace. She shows the reader how to make effective use of tag combinations, such as the <kbd> (keyboard) and <b> (bold) tags.

There is the smallest amount of reference information in some chapters. For example, Chapter 4 contains a table on page 50 showing the list attributes. These references are very small and quite helpful, but the reader should understand that the emphasis is on doing something and that the reference material may not be complete. For example, the special symbols table on page 56 is missing the em dash, which is something most people use.

The book progresses at a reasonable pace. Never did I find myself rushed. The examples all seem to work fine and I didn’t find missing steps in the procedures. The author uses an adequate number of graphics so that the reader doesn’t get lost. I liked the fact that every exercise ends with a cleanup section and a list of the major points that the reader should have gotten from the exercise.

Readers who are only interested in new tags will need to wait until Chapter 9 to see one. The <figure> tag makes an appearance on page 141. However, even some professionals didn’t use all of the HTML4 tags and it really does pay to start at Chapter 3 and look for something you don’t recognize. It may surprise you to find that an earlier chapter contains a somewhat new (but not new to HTML5 tag) that you’ve passed by.

There are a few nits to pick with this book. The first is that the author places the accessibility information in an appendix where almost no one is going to read it. The information should have appeared as part of the rest of the book as appropriate. In addition, the author misses the big point that most people today have some sort of special need addressed by accessibility aids. The number of people who are colorblind alone is 8 percent of the male population and 0.5 percent of the female population. This book is unlikely to help you create a truly accessible sitenot that this is the reason you’re buying the book.

The second is that Appendix C doesn’t really help very much with the additions and subtractions for HTML5. For example, Appendix C doesn’t tell you about the new <aside> tag. If you want a quick list of the new tags, check out the www.w3schools.com HTML5 New Elements page. (I checked the missing <aside> tag against a number of other sites, such as About.com.) The point is that Appendix C won’t give you the complete picture. Again, this isn’t one of the selling points of the book, but the list should have been complete.

The third is that there isn’t really enough information about why something is done or why it changedsimply that it must be done or that it did change. The reader probably doesn’t want a full blown history of the change, but the why of something can make understanding and, more importantly, remembering a concept easier. Still, this particular nit is minor since the purpose of the book is to get you started with HTML5 quickly and not to explore it at a theoretical level.

Overall, HTML5 Step by Step is a great book for the novice who wants to learn how to create Web pages. It’s also an acceptable book for someone who’s experienced with HTML coding, but wants to get up-to-date on the HTML5 changes quickly. This book is definitely designed for someone who wants to do something, rather than simply read about it. If you don’t perform the exercises, you won’t get much out of the book.