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.

 

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.

 

Death of Windows XP? (Part 5)

Windows XP, the operating system that simply refuses to die. The title of this post should tell you that there have been four other posts (actually a lot more than that) on the death of Windows XP. The last post was on 30 May 2014, Death of Windows XP? (Part 4). I promised then that it would be my last post, but that’s before I knew that Windows XP would still command between 10 percent and 15 percent market share—placing it above the Mac’s OS X. In fact, according to some sources, Windows XP has greater market share than Windows 8.1 as well. So it doesn’t surprise me that a few of you are still looking for Windows XP support from me. Unfortunately, I no longer have a Windows XP setup to support you, so I’m not answering Windows XP questions any longer.

Apparently, offering Windows XP support is big business. According to a recent ComputerWorld article, the US Navy is willing to pony up $30.8 million for Microsoft’s continued support of Windows XP. Perhaps I ought to reconsider and offer paid support after all. There are many other organizations that rely on Windows XP and some may shock you. For example, the next time you stop in front of an ATM, consider the fact that 95 percent of them still run Windows XP. In both cases, the vendors are paying Microsoft to continue providing updates to ensure the aging operating system remains secure. However, I’m almost certain that even with security updates, hackers have figured out ways to get past the Windows XP defenses a long time ago. For example, even with fixes in place, it’s quite easy to find headlines such as, “Hackers stole from 100 banks and rigged ATMs to spew cash.”

What worries me more than anything else is that there are a lot of home users out there who haven’t patched their Windows XP installation in a really long time now. Their systems must be hotbeds of viruses, adware, and Trojans. It wouldn’t surprise me to find that every one of them is a zombie spewing out all sorts of garbage. It’s time to put this aging operating system out of its misery. If you have a copy of Windows XP, please don’t contact me about it—get rid of it and get something newer. Let me know your thoughts on ancient operating systems at John@JohnMuellerBooks.com.

 

Java 7 Patches and Future

It’s always important to keep your software updated with the latest patches. This is especially true with Java because so many hackers target even the smallest weaknesses. According to a recent ComputerWorld article, Java 7 has reached the end of its public life for updates. You need to upgrade to Java 8 in order to continue receiving free updates from Oracle. The rapid pace of updates that vendors rely on now is made necessary by hackers who apparently create malware updates even faster. Even at the fast release pace that Oracle is using, the malware just keeps rolling out. In other words, as a developer you need to exercise proactive coding to keep security risks at bay, in addition to relying on Oracle and other vendors for help.

A number of people have asked me about updates to Java eLearning Kit for Dummies. As far as I know, the publisher currently doesn’t have plans for an update. Of course, that could change at some point. Until the next update, however, the examples I’ve tested with Java 8 work fine on a Windows system. I’ll be performing additional testing on both OS X and Linux. However, I don’t have quite the number of people testing the book code as I had when I wrote it. If anyone does encounter a problem with the code, I’d greatly appreciate hearing about it at John@JohnMuellerBooks.com. I can’t guarantee that I’ll be able to fix absolutely every issue, but I’ll try to find workarounds and publish them on the blog for you.

As always, please don’t send me your personal code—I only work with book-specific code. Using the downloadable source is always the best way to get the most you can from a book. I’ve also created the Using My Coding Books Effectively post to help you get the most from my books. It’s important to me that you get the most you can from my books.

 

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.

 

Considering Threats to Your Hardware

Most of the security write-ups you see online deal with software. It’s true that you’re far more likely to encounter some sort of software-based security threat than any of the hardware threats to date. However, ignoring hardware threats can be problematic. Unlike the vast majority of software threats that you can clean up, hardware threats often damage a system so that it becomes unusable. You literally have to buy a new system because repair isn’t feasible (at least, for a reasonable price).

The threats are becoming more ingenious too. Consider the USB flash drive threat called USB Killer. In this case, inserting the wrong thumb drive into your system can cause the system to completely malfunction. The attack is ingenious in that your system continues to work as normal until that final moment when it’s too late to do anything about the threat. Your system is fried by high voltage sent to it by the thumb drive. Of course, avoiding the problem means using only thumb drives that you can verify are clean. You really can’t even trust the thumb drive provided by friends because they could have obtained the thumb drive from a contaminated source. The result of such an attack is lost data, lost time, and lost hardware—potentially making the attack far more expensive than a software attack on your system.

Some of the hardware-based threats are more insidious. For example, the Rowhammer vulnerability makes it possible for someone to escalate their privileges by accessing the DRAM on your system in a specific way. The technical details aren’t quite as important as the fact that it can be done in this case because even with repairs, memory will continue to be vulnerable to attack in various ways. The problem is that memory has become so small that protections that used to work well no longer work at all. In addition, hardware vendors often use the least expensive memory available to keep prices low, rather than use higher end (and more expensive) memory.

It’s almost certain that you’ll start to see more hardware threats on the horizon because of the way in which people work with electronics today. All these new revelations remind me of the floppy disk viruses of days past. People would pass viruses back and forth by trading floppies with each other. Some of these viruses would infect the boot sector of the system hard drive, making it nearly impossible to remove. As people start using thumb drives and other removable media to exchange data in various ways, you can expect to see a resurgence of this sort of attack.

The potential for hardware-based attacks continues to increase as the computing environment becomes more and more commoditized and people’s use of devices continues to change. It’s the reason I wrote Does Your Hardware Spy On You? and the reason I’m alerting you to the potential for hardware-based attacks in this post. You need to be careful how you interact with others when exchanging bits of seemingly innocent hardware. Let me know your thoughts about hardware-based attacks at John@JohnMuellerBooks.com.

 

Does Your Hardware Spy On You?

Every once in a while I encounter an article that talks about government intrusion into private organizations through means that seem more like a James Bond movie plot than reality. The latest such story appeared in ComputerWorld, “To avoid NSA, Cisco delivers gear to strange addresses.” These articles lead me to wonder whether the authors have an overdeveloped persecution complex or government agencies are really spying on the public in such overtly secretive (and potentially illegal) ways. The fact that some companies apparently believe the threat enough to ship their equipment to odd addresses is frightening. Consider the ramifications of the actions—is it even possible to feel safe ordering hardware you haven’t built yourself (or are the individual components bugged too)?

Obviously, government organizations do require some means of tracking bad guys out there. Of course, the term bad guys is pretty loose and subject to great deal of interpretation. In addition, just how much tracking is too much tracking? Would enough tracking prevent another terrorist attack or the loss of income caused by crooked company executives? There are many questions that remain unanswered in my mind (and obviously in the minds of others) over the use of various tracking technologies.

The topic of government spying, it’s legitimate and illegitimate uses, and just who the bad guy is demands a lot more attention than anyone is giving it. So, how do you feel about government tracking of everything and anything it sets its mind to spy on? Do you feel there should be limits? What do you feel about shipping things to odd addresses to avoid notice and circumvent the system (partly because the system is broken)? I’d love to hear your point of view about the use of modified computer equipment as a tool for spying on the private sector at John@JohnMuellerBooks.com.

 

Creating Effective Passwords

It’s like a recurring nightmare—the whole issue of passwords simply won’t go away. People continue to use really awful passwords like secret and password because they’re easy to remember and they view passwords as a pain. A user will rely on the same password for everything, so once a hacker figures the password out, every resource the user can access is wide open. To make sure everyone can access the user’s account, the password often appears on post-it notes and in other obvious places. Of course, the user never, ever changes the password so once a hacker gains access, the accounts will remain open forever. This is just the tip of the password complaint iceberg.

Microsoft and other vendors are trying to remedy the situation by using biometric data or smart cards. The problems with smart cards are that they’re easily copied and even easier to lose. A lot of organizations have tried smart cards and found them to be less than ideal. Biometric data is just as bad. There are ways of easily thwarting fingerprint scanners today. Of course, once a fingerprint is hacked, you can’t change it. Fingerprints are unique, but using just a fingerprint means that everyplace you log in effectively uses the same password. So, once someone does hack your fingerprint, they can access absolutely everything you can. To overcome the issues with a single biometric, some researchers are now suggesting the use of a Multi-Biometric Authentication System (MBAS), which is also called a Multimodal Biometric Authentication System. So, how you have a really expensive, overly complex system that is bound to have a high failure rate.

The problem with all the various lines of thought out there now is what I call the magic bullet syndrome. Someone thinks that there is a solution that will somehow thwart the bad guys. Unfortunately, history proves that the bad guys always come up with a way to storm the gates and that any wall you build will prove too low at some point. I’ve advocated the passphase system for years because you can create passwords that are both strong and easy to remember. Passphrases can be quite long, complex, and still make it easy for someone to enter correctly nearly every time. In addition, you can change passphrases with the same ease that you can a password. Changing your password or passphrase relatively often means that even if hacker does gain access to an account, it’s unlikely to remain open to them. Still, no solution is perfect, which is why security monitoring is an essential part of any security solution.

Of course, whether you use a password or a passphrase, you need to know that it’s strong enough to keep hackers at bay, at least for a while. Therein lies another problem. According a recent ComputerWorld article, many of the password strength meters out there are giving users a false sense of security. They really don’t tell you that your password or passphrase is strong enough to withstand easy attack. When creating a password or passphrase, avoid using words that are spelled precisely the same as they are in the dictionary. For example, you could replace the letter E with the number 3. Make sure the passphrase is relatively long and complex. It should include spaces (when allowed) and special characters (such as the ampersand, &). Use a combination of uppercase and lowercase letters. Include numbers. Misspell a word or two, such as “MiG00dPassphras3”. The point is that you want to make things hard on your attacker, but still easy to remember.

When all is said and done, your best defense against hackers is vigilance. It doesn’t matter whether you use passwords, passphrases, smart cards, or biometrics. If someone really wants to gain access to your account, you have to assume they’ll be successful. Don’t believe in magic bullet solutions because they really don’t exist no matter what someone might try to tell you. Make sure you change your login information on a regular basis and keep an eye on the resources you use. Report any suspicious activities that you find. In short, don’t assume that you’re safe because you really aren’t. Let me know your thoughts about passwords, passphrases, smart cards, and biometrics at John@JohnMuellerBooks.com.