Home site for the Start Programming with Python ebook.
Learn basic and intermediate programming skills in an easy-to-learn and fun-to-use language. Many of the ideas you will learn will carry over to other programming languages and ideas.

Facebook SDK

Saturday, December 28, 2013

Programming Security-Part 1 (General Thoughts)

As part of thinking about updates to my
book, if I ever get around to making another revision, I've thought
that a chapter on programming security would be good. It is also
helpful that part of the requirements to maintain my Security+
certification can be met by writing security-oriented blog posts.
Thus, I will start writing a number of posts about programming
security in general and how Python deals with some of these issues,
if it does. If I ever make a new version of my book, I will include
these posts into a new chapter. Hopefully this information will be
useful.

The big thing to remember when it comes
to programming security is that it just takes one mistake to create a
security vulnerability. While Python alleviates a lot of the problems
other languages have, e.g. memory allocation, it doesn't mean the
Python is invulnerable. In fact, one of the points against Python is
the fact that it isn't compiled; because Python programs are
frequently provided in their raw .py files, anyone can open them up
and view or modify them. Thus, if a person looks at the file for
nefarious purposes, it's very easy for him or her to identify
vulnerabilities that the programmer left in the code.

Another problem with Python is the
incompatibility between Python 2.x and Python 3.x. If a programmer is
converting a file from 2.x to 3.x, and not using the 2to3 converter
(or doesn't look at the resulting code), there is a chance that
vulnerability snuck through.

Secure programming, regardless of the
language, involves some assumptions on the part of the programmer.
Essentially, the programmer never assumes the system is in a
particular state or that functions, methods, libraries, etc. will
work as advertised. The programmer attempts to handle all possible
errors and conditions within the code.

For example, buffer overflows occur
when too much data is put into a buffer (a portion of memory). If the
buffer fills up, any additional data spills over into adjacent memory
areas, potentially causing system malfunctions, memory corruption, or
exploiting the system. C and C++ are famous for buffer overflows, as
they have no inherent protection against accessing or overwriting
data in any memory location and do not automatically check the input
data against the boundaries of a buffer.

As a programmer, you should develop the
habit of validating any input data, whether it be ensuring the type
of data (character strings vs. numbers), the length of the data
(ensuring too much data isn't put into a buffer), allowed characters,
etc. Many SQL attacks are performed due to poor or non-existent data
checking.

One of the reasons there are so many
languages available for programming nowadays is because of the
inherent lack of security in C and C++. For decades, those languages
dominated programming; they are still the go-to choice for many
programmers, especially for low-level work on hardware devices, such
as video cards. Newer languages, like Java, Python, Ruby, or the
various .NET flavors have some safety features built-in.

One example is garbage collection.
Traditional C/C++ programmers have to be aware of memory allocation
and ensure that, once a data object is no longer in use, all
references to it are removed from memory. If not, the memory remains
allocated for that non-existent object and can't be used for another
purpose. If this happens too often, eventually there will be no
memory available for legitimate data objects and the program fails,
the system crashes, or other problems arise. If a malware writer
wanted to create a denial of service, simply providing a program that
eats up memory will do it; once the system or program crashes, no one
can use it until it is reset.