book is only about Web applications, and it doesn’t touch the installation and configuration of server software, the use of firewalls and antiviruses, vulnerabilities in executable files, and other issues that relate to preventing hackers from obtaining privileges on a server without authentication. Therefore, this book is for Web programmers rather than system administrators responsible for the security of a server.
I demonstrate that improper Web programming results in vulnerable Web applications that can become the weakest components in server protection. “Holes” in these components can allow a hacker to bypass a complicated protection and obtain privileges on the server to investigate the server from the inside.
By protection I mean two types of protection: against changes to information and against unauthorized access to information.
Imagine a small Web site that contains only static data. You could say that the owner of this site has nothing to hide. There are no passwords or access rights. According to HTTP, the server sends data to a client without processing.
Leakage of information about the files located on the site or the server wouldn’t be crucial. Even if an attacker accessed the files using File Transfer Protocol (FTP), rather than HTTP, he or she wouldn’t benefit from it.
In this situation, the ability of an unauthorized user to change information is more dangerous than that person’s ability to access it because the server doesn’t store private data. The only exception might be directories protected with a password using the Web server tools.
Now imagine a more complicated system such as an e-shop. Server scripts are accessing a database that stores private data about clients, suppliers, and so on. In addition, this database can store confidential information such as users’ credit card numbers.
Disclosure of the source code of the server scripts would also be dangerous. These scripts are likely to contain information sufficient for access to the database, that is, the login and the password. Even if they aren’t stored unencrypted, the attacker would be able to disclose them. The source code of the scripts could be analyzed for vulnerabilities that would allow the attacker to obtain high privileges and control the server.
Therefore, leakage of information from this site would be more dangerous than from the static site. A hacker who has found a hole in this system is unlikely to change data in it. Rather, he or she would try to remain unnoticed and obtain commercial secrets to benefit from them.
So, the attacker would first decide whether he or she wants to change information on a server (deface the server, replenish his or her personal account, destroy a database, etc.) or collect information (dump the database, copy system files, etc.).
In any case, the attacker’s goal is to obtain as much information about the server as possible and to obtain privileges on it.
A Web programmer should understand, against which type of attack he or she should protect the system. In most cases, the programmer has to protect the data both from changes and from theft.
You, the programmer, should also be aware that a hacker can use holes in Web applications to gain control over the server. You shouldn’t neglect protection even if the information on the server isn’t valuable and its leakage or compromising wouldn’t do harm. Be aware that a hacker’s goal can be to control the server to use its computational resources. For example, a server can be used as a relay computer to send spam, scan vulnerabilities on other servers, or find passwords from hashes.
So, the main principle of Web programming is that you should always write Web applications protected as well as possible. This isn’t difficult. I hope this book will teach you how to write protected applications and turn vulnerabilities to your advantage.