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.

 

Browser Support in My Books

A number of my books rely on browser output to show the result of various coding techniques, including Security for Web Developers, HTML5 Programming with JavaScript for Dummies, and CSS3 for Dummies. I try to keep up with changes in technology with my books and I’m currently testing the code in all three books with Internet Explorer 11. According to a recent ComputerWorld article, users of older version of IE only have six weeks to make an update to the new version. They can also use the Edge browser or move to a competitor’s browser. My books list the browsers I used for initial testing of the source code, but I do try to at least check the code with newer browsers to ensure you have a good reading experience. In this case, the check is critical because I can’t expect you to rely on unsupported software to use my books.

When I originally wrote each of these books, I had at least one technical editor and a number of beta readers checking my code under various conditions to ensure the code would run as advertised on the maximum number of systems. I no longer have the support, so I’m testing these updates on just my systems. If you encounter a problem with the source code of any of these books, please be sure to contact me at John@JohnMuellerBooks.com. Now, here’s the important part. Make absolutely certain to let me know that you’re using a newer browser—one not originally tested in the book so I can handle your query correctly and also provide an update on my blog. Your input will help other readers.

Whenever possible, I encourage readers to use the environment described in the book to write their own code. Doing so reduces the potential for problems because I know that the environment is tested by a number of people in a number of environments. However, sometimes using the original environment isn’t possible any longer, such as this instance where Microsoft is putting its collective foot down and forcing an update. Please be sure to write me if you have any questions about the source code for these book. Thanks, as always, 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.

 

Web Security, A Lot More Complicated Than It Seems

I recently finished writing Security for Web Developers. During the months that I worked on the book, I became aware of a serious problem in the reporting, handling, and supposed fixes for the problem of web security—everyone seems intent on making things fast and easy. Depending on the source, you also see a fair amount of finger pointing at play. Sources put the blame on just one or two entities in most cases. Unfortunately, the picture is far more complex than simply applying a bandage to one or two potential security problem sources. I started understanding the problem when I wrote HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies, but it wasn’t until I wrote this book that I began to understand the true enormity of the problem. It isn’t just one or two or three sources—it’s all the sources combined. In this latest book I explore a lot of different sources of security problems and provide advice on how to overcome these issues to some extent.

  • Users
  • Application Developers
  • Third Party Library, API, and Microservice Providers
  • Administrators and Other IT Staff
  • Product Distributors
  • Data Service Providers

Many other groups appear in the book as well. The more I dug, the more I found that just fixing one problem or educating one group wouldn’t solve anything. Hackers look for easy ways to gain access to applications and the current system provides them with plenty of opportunities. The current strategy of responding to just one potential threat will continue to fail simply because the hacker will move on to another threat. Unless an organization is willing to take a holistic approach to security, hackers will continue to enjoy overwhelming success without a whole lot of work. In writing Security for Web Developers, I attempted to provide a broader view of the security picture so that development teams that include all of the stakeholders involved in an application effort can finally work together to resolve the security issues in their individual areas of expertise (including users who are susceptible to too many kinds of attack to mention).

A reader recently asked me whether the strategies in my book will prevent attacks, which is a loaded question and one that is hard to answer. My view of security is that a determined hacker will always gain entrance to your system, so you must remain vigilant at all times. If someone wants your data, they’ll gain access, but if you’re equally vigilant, you can keep the damage to a minimum. For that matter, you might be able to prevent any real damage. However, you need to realize that no security measure you take is going to succeed all the time.

What my book does is help make your system less appealing. In other words, if a hacker is just looking for a system to invade and not specifically your system, then making your system less appealing will see the hacker move to other systems. Like anyone else, a hacker seeks to minimize effort and maximize gain. Making your system less appealing by employing a holistic security approach will increase the effort the hacker must employ and make it less likely that the hacker will continue probing.

Unless you really want to see your organization’s name join the victim list in the trade press, you really do need to employ security across an organization, which means vetting software fully, educating users, having appropriate policies in place, reviewing software before placing it in production, and so on. Using just one or two measures simply won’t work. Let me know if you have questions regarding my upcoming book at John@JohnMuellerBooks.com.

 

Source Code Placement

I always recommend that you download the source code for my books. The Verifying Your Hand Typed Code post discusses some of the issues that readers encounter when typing code by hand. However, I also understand that many people learn best when they type the code by hand and that’s the point of getting my books—to learn something really interesting (see my principles for creating book source code in the Handling Source Code in Books post). Even if you do need to type the source code in order to learn, having the downloadable source code handy will help you locate errors in your code with greater ease. I won’t usually have time to debug your hand typed code for you.

Depending on your platform, you might encounter a situation the IDE chooses an unfortunate place to put the source code you want to save. For example, on a Windows system it might choose the C:\Program Files folder (or a subdirectory) to the store the file. Microsoft wants to make your computing experience safer, so you don’t actually have rights to this folder for storing your data file. As a result, the IDE will stubbornly refuse the save the files in that folder. Likewise, some IDEs have a problem with folder names that have spaces in them. For example, your C:\Users\<Your Name>\My Documents folder might seem like the perfect place to store your source code files, but the spaces in the path will cause problems for the IDE and it will claim that it can’t find the file, even if it manages to successfully save the file.

My recommendation for fixing these, and other source code placement problems, is to create a folder that you can access and have full rights to work with to store your source code. My books usually make a recommendation for the source code file path, but you can use any path you want. The point is to create a path that’s:

  • Easy to access
  • Allows full rights
  • Lacks spaces in any of the path name elements

As long as you follow these rules, you likely won’t experience problems with your choice of source code location. If you do experience source code placement problems when working with my books, please be sure to let me know at John@JohnMuellerBooks.com.

 

Web Application Security Breach Commonality

If you follow the trade news for even a few weeks, you begin to see a recurring pattern of security breaches based on web application deficiencies, social engineering attacks, or some other weakness in the security chain. The latest attack that is making the rounds is the IRS security breach. However, I’m not picking on the IRS, you can find security breaches galore in every arena of human endeavor simply by performing the required search. Everyone gets hacked, everyone is embarrassed by it, and everyone lies through their teeth about the methods used for the attack, the severity of the attack, and the likelihood of dire results. The attacks serve to demonstrate a simple principle I’ve written about in HTML5 Programming with JavaScript for Dummies, CSS3 for Dummies, and Security for Web Developers—if someone wants to break your security, they’ll always succeed.

Later analysis of the IRS attack brings out some important issues that you need to consider as part of your development efforts. The first is that you really do need to expend the effort to create the most secure environment possible. Many of the successful attacks use simple methods to obtain the desired result. Training really does help reduce social engineering attacks, updates really do help close security issues that a hacker can use to access your system, good programming practices keep hackers at bay, make applications easier to use, and reduce errors that result in security issues. All of these methods help you remain secure. However, remaining vigilant is important too. Monitoring your application and the libraries, APIs, and microservices on which they depend are all important. Despite protestations to the contrary, the IRS probably could have done more to prevent the breach, or at least mitigate the results of the breach.

A focal point of the analysis for me is that the IRS currently has 363 people working security and a budget of $141.5 million to ensure your data remains safe. The author is a bit harsh and asks whether the IRS Commissioner Koskinen thinks his people are stupid because he keeps making the claim that these hackers are quite skilled. Yet, the hacks used are really quite simple. Breaches happen to every organization at some point, no matter how much money you want to throw at the problem. Organizations get blindsided because hackers attack from a direction that is unexpected in many cases or the organization simply isn’t keeping track of the current threats. Again, I’m not heaping insult on the IRS, simply pointing out a problem that appears common to most of the breaches I read about. What is needed in this case is a frank admission of the facts and a whole lot less in the way of excuses that simply make the organization look weak or stupid anyway.

The IRS, like many organizations, later came back and increased the tally on the number of individuals affected by the breach. This is another common issue. Instead of investigating first and speaking later, many organizations provide numbers at the outset that really aren’t based on solid facts. When an organization has a breach, the public does need to know, but the organization should wait on details until it actually does know what happened.

The application that caused the breach is now dead. It’s a demonstration of a final principle that appears in many of my books. If you really want to keep something secret, then don’t tell anyone about it. Breaches happen when data is made public in some manner. Yes, it’s convenient to access tax information using a web application, but the web application will be breached at some point and then the confidential details will appear in public. Organizations need to weigh convenience against the need to keep data secure. In some cases, security has to win.

The more I read about security breaches, the more convinced I become that they’re unavoidable. The only way to prevent data breaches is to keep the data in a closed system (and even then, a disgruntled employee could still potentially make a copy). Being honest about data breaches, providing the public with solid facts, and ensuring remediation measures are effective are the only ways to control the effects of a data breach. Let me know your thoughts on this issue at John@JohnMuellerBooks.com.

 

Applauding the Death of ActiveX – Maybe

I still remember when Microsoft first introduced ActiveX in 1996. The technology was supposed to greatly simplify web applications. I even wrote ActiveX from the Ground Up to provide simplified technical information on using ActiveX (the book helped a lot of people, but some developers were looking for something a bit more technical). The idea was to extend Microsoft’s Object Linking and Embedding (OLE) technology to the Internet to make it possible to reuse code and to allow applications to share data.

The problems with ActiveX are many. The simplest of these problems is that ActiveX only works with Internet Explorer and only on Windows and Macintosh systems. The limitation means that ActiveX really doesn’t have a place with modern application development where everything has to run everywhere. However, even with this limitation, ActiveX is a security nightmare because it’s literally an invitation for anyone with any sort of code writing savvy at all to invade your system. Because these controls have complete access to your system (they don’t run in a sandbox), a hacker exploiting them can literally do anything and get by with it. Even Microsoft spent a good deal of time telling you how to protect yourself from the security issues that come with ActiveX control use. In short, using ActiveX controls are a truly horrid idea.

That’s why I’m pleased to mention that ActiveX will soon be dead—at least, from the perspective of new browser development. The new Edge browser won’t include any form of ActiveX support. Unfortunately, Internet Explorer (IE) will continue to hang around for quite a while, which means that a lot of old browsers out there will continue to represent a potential and potent security risk. On the desktop, IE11 has about 27.22 percent of the market share, IE8 13.58 percent, IE9 6.76 percent, and IE10 5.55 percent, for a total of 53.11 percent of the market. There is a high chance that someone out there has ActiveX running and that ActiveX control is causing everyone else woe.

Unfortunately, Edge won’t be available for Windows 7 and older versions of Windows, so you know that those older versions of Internet Explorer will hang around forever. Given the security risk that ActiveX represents, you’d think Microsoft would want to save itself some trouble and make Edge available for everyone. Consequently, even though ActiveX is eventually going to go away, don’t look for it to die immediately. Let me know your thoughts on Edge, ActiveX, and the potential problems with older versions of IE at John@JohnMuellerBooks.com.

 

Security = Scrutiny

There is a myth among administrators and developers that it’s possible to keep a machine free of viruses, adware, Trojans, and other forms of malware simply by disconnecting it from the Internet. I’m showing my age (yet again), but machines were being infected with all sorts of malware long before the Internet became any sort of connectivity solution for any system. At one time it was floppy disks that were the culprit, but all sorts of other avenues of attack present themselves. To dismiss things like evil USB drives that take over systems, even systems not connected to the Internet, is akin to closing your eyes and hoping an opponent doesn’t choose to hit you while you’re not looking. After all, it wouldn’t be fair. However, whoever said that life was fair or that anyone involved in security plays by the rules? If you want to keep your systems free of malware, then you need to be alert and scrutinize them continually.

Let’s look at this issue another way. If you refused to do anything about the burglar rummaging around on the first floor while you listened in your bedroom on the second floor, the police would think you’re pretty odd. More importantly, you’d have a really hard time getting any sort of sympathy or empathy from them. After all, if you just let a burglar take your things while you blithely refuse to acknowledge the burglar’s presence, whose fault is that? (Getting bonked on the back of the head while you are looking is another story.) That’s why you need to monitor your systems, even if they aren’t connected to the Internet. Someone wants to ruin your day and they’re not playing around. Hackers are dead serious about grabbing every bit of usable data on your system and using it to make your life truly terrible. Your misery makes them sublimely happy. Really, take my word for it.

The reason I’m discussing this issue is that I’m still seeing stories like, “Chinese hacker group among first to target networks isolated from Internet.” So, what about all those networks that were hacked before the Internet became a connectivity solution? Hackers have been taking networks down for a considerable time period and it doesn’t take an Internet connection to do it. The story is an interesting one because the technique used demonstrates that hackers don’t have to be particularly good at their profession to break into many networks. It’s also alarming because some of the networks targeted were contractors for the US military.

There is no tool, software, connection method, or secret incantation that can protect your system from determined hackers. I’ve said this in every writing about security. Yes, you can use a number of tools to make it more difficult to get through and to dissuade someone who truly isn’t all that determined. Unfortunately, no matter how high you make the walls of your server fortress, the hacker can always go just a bit further to climb them. Headlines such as “Advanced Attackers go Undetected for a Median of 229 Days; Only One-Third of Organizations Identify Breaches on Their Own” tell me that most organizations could do more to scrutinize their networks. Every writing I read about informed security is that you can’t trust anyone or anything when you’re responsible for security, yet organizations continue to ignore that burglar on the first floor.

There is the question of whether it’s possible to detect and handle every threat. The answer is that it isn’t. Truly gifted hackers will blindside you can cause terrifying damage to your systems every time. Monitoring can mitigate the damage and help you recover more quickly, but the fact is that it’s definitely possible to do better. Let me know your thoughts about security at John@JohnMuellerBooks.com.

 

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.