Foundations of Python Network Programming 978-1-4302-3004-5

CHAPTER 6 ■ TLS AND SSL
Second, write as little code as possible. Rely on well-written and thoroughly tested third-party code
whenever you can, with a special emphasis on using tools that seem to be well tested and actively
maintained. One reason for using common technologies over obscure tools that you think might be
better is that the code with the larger community is more likely to have its weaknesses and
vulnerabilities discovered and resolved. Keep everything upgraded and up-to-date when possible, from
the operating system and your Python install to the particular distributions you are using off of PyPI.
And, of course, isolate your projects from each other by giving each of them its own virtual environment
using the virtualenv command discussed in Chapter 1.
Third, the fact that you are reading this book indicates that you have probably already adopted one
of my most important recommendations: to use a high-level language like Python for application
development. Whole classes of security problems disappear when your code can talk directly about
dictionaries, Unicode strings, and iteration over complex data structures, instead of having to
manipulate raw integers every time it wants to visit every item in a list. Repetition and verbosity not only
waste your time and cut your productivity, but also directly increase your chance of making a mistake.
Fourth, as you strive for elegant and simple solutions, try to learn as much as possible about the
problem domain if many people have tackled it before you. Read about cross-scripting attacks (see
Chapter 9) if you are writing a web site; about SQL injection attacks if your application talks to a
database; about the sordid history of privilege escalation attacks if your system will support users who
have different permission levels; and about viruses and Trojan horses if you are writing an e-mail client.
Fifth and finally, since you will probably lack the time (not to mention the omniscience) to build
your entire application out of perfect code, try to focus on the edges of your code where it interacts with
data from the outside. Several minutes spent writing code to examine a web form variable, checking it
every which way to make sure it really and truly looks like, say, a string of digits, can be worth hours of
precaution further inside the program that will be necessary if the bad value can make it all the way to
the database and have to be dealt with there.
It was a great day, to take a concrete example, when C programmers stopped thinking that their
servers had to always run as root—which had risked the compromise of the entire machine if something
were to go wrong—and instead wrote network daemons that would start up, grab the low-numbered
port on which their service lived, and then immediately drop their privileges to those of a normal user.
They almost seemed to consider it a contest to see how few lines of code they could leave in the part of
their program that ran with root privileges. And this brought about a vast reduction in exposure. Your
Python code is the same way: fewer lines of code that run before you have verified the sanity of an input
value, or tested for a subtle error, mean that less of the surface area of your program can harbor bugs
that enemies could exploit.
But, again, the subject is a large one. Read blogs like “Schneier on Security,” watch vendor security
announcements like those on the Google Online Security Blog, and consult good books on the subject if
you are going to be writing lots of security-sensitive code.
You should at least read lots of war stories about how intrusions have occurred, whether from
security alerts or on popular blogs; then you will know ahead of time to forearm your code against the
same kinds of disasters. Plus, such accounts are also quite entertaining if you like to learn the details of
how systems work—and to learn about the unending cleverness of those who want to subvert them.
IP Access Rules
During the 1980s, the Internet grew from a small research network to a large enough community that it
was unwise to trust everyone who happened to have access to an IP address. Prudence began to dictate
that many services on each host either be turned off, or restricted so that only hosts in a pre-approved
list were allowed to connect. But each piece of software had its own rules for how you specified the hosts
that should be allowed to connect and the hosts whose connections should be rejected.
In 1990, Wietse Venema introduced the TCP Wrappers, and suggested that all Internet server
programs could use this single piece of code to make access decisions. The idea was that rather than
requiring every piece of software to have a separate configuration file, which made it impossible for
88