Web security is paramount to the security of an organization as a whole. Almost every organization, company, or network has a public-facing web site or portal for accessing content, possibly logging in to an account, or receiving data from its users. But as with any application that a company uses, web applications pose a critical risk to the infrastructure of the network. Look at almost any attack that has been launched against an organization within the last few years. Chances are that those attacks either originated, or occurred entirely through a web application used by that organization.
In this series of posts, I have decided to take on the project of understanding more about web security, especially the area of web security that focuses on the direct, public-facing application (as opposed to attacking from the infrastructure side such as an Apache server). There are hundreds of guides online that talk about various areas of protecting web applications, but I wanted to describe my experiences from the absolute beginning.
Web Applications have greatly increased the availability and ease-of-use of common tasks. Think of Google Docs - it has taken a commonly used feature of computing (word processing) and moved it to a browser-based interface complete with almost all of the same functions. However, it can be run from any computer with a browser and an internet connection. The same documents can be accessed from smartphones and tablets as well, making our data practically universally available.
Besides the obvious drawback of having to have an active internet connection (which some applications are alleviating with local storage), web applications pose a number of risks - most importantly in terms of security. Unlike typical applications, which install and run from a user's computer, web applications run on the servers of the hosting organization and transfer the required data back and forth over the internet connection. Because of this, a wide array of vulnerabilities are exposed that never occurred with traditional applications. One vulnerability that keeps appearing time and time again (which I will be focusing on in this series) is the exploitation of the remote web server due to the "holes" that are made in the system by allowing web connections through an interface that allows user input.
In typical applications, bad user input (in other words, input that was not expected) could cause a program to crash, possibly force a reboot of the local machine, or, in some cases, allow it to be exploited (although this is much rarer). Web applications are much different because they are hosted elsewhere. When a user enters bad input, that input is being run against a remote web server, not necessarily against the local machine (with the exception of some vulnerabilities, which will be discussed later). This is a critical security issue because it can potentially allow an attacker to gain access to a remote web server.
In the upcoming posts in this series, I will be walking through the study of web application security, specifically through the use of sanitation of user input and the use of a web application firewall (both of which I will talk about much more). I will be writing this with the expectation that the reader has familiarity with web technologies and web server experience, but perhaps not with the security of web applications themselves. I will be walking through every step of the process that I am using to study this aspect of security because it is a major learning experience for me as well. One thing I find annoying in some tutorials is when the steps taken to arrive at a particular outcome are not explained. So more advanced readers, please bear with me as I attempt to bring everyone onto the same page.