Achieving protocol security: Gunter ollmann, x-force security assessment services. (Internet Focus).

Having assessed the security of several dozen commercial web applications personally, and overseen the assessment of many more, it is always surprising to see the number of high-risk security flaws that developers have left behind. Most worryingly, a major proportion of vulnerabilities are due to a basic misunderstanding of the Internet protocol and system software used to host or use the web application. As organisations have improved their perimeter defence systems and are in the process of rigorously applying the latest security fix from their operating system providers, attackers have been forced to focus their destructive attention on the security flaws lying within the organisation's custom-developed web applications. Many developers fail to understand the nuances of the HTTP protocol and assume that it is too difficult, or not worth the trouble, for an attacker to launch an attack at their custom application. Developers must assume that every packet of data not coming from the organisations hosts and servers, can be modified. Relying upon the REFERER field (a field present in almost all browser requests e.g. Referer: http://www.w3.org/DataSources/Overview.html) in the header of a clients page request or data submission, to have come from a legitimate link on the site is extremely dangerous, as it can be easily circumvented. Similarly, relying upon the HOST field in submissions from the application server in intra-server communications is equally dangerous.

Infrequently, "security aware" sites manage to correctly implement input validation rules for client data--unfortunately, all client-side checking and data validation processes can be bypassed by an attacker using commonly available tools and methodologies. The only safe solution is to validate all client content at the server-side before processing further within the application. Too often the input of unexpected characters (e.g. single quote, plus, etc.), numbers or data lengths to submission fields result in errors that reveal the inner workings of the application. Using this information an attacker can craft data payloads, tailored to the custom application, that can compromise the integrity of the organisation's data or hosts.

Most developers tend to assume that the data supplied to their application by the hosting software will be correct and safe. Many server compromises have been achieved when the hosting software has failed to identify and correctly restrict client URLs to directory paths related to the web applications data paths.

Custom applications largely assume that the directory information provided by the hosting software is correct, but the remote attacker often gains access to restricted files (such as password files and database volumes) using the permissions of the application administrator level. A lethal habit amongst too many developers is the use of whatever permissions they need to get the application running correctly, no matter what they are. Unfortunately, very little forethought goes into ensuring that the minimum level of system permissions are used, and there is no onus to invest time or resources in figuring out the minimum suite of permissions they really do need.

Having said all this, it must be pointed out that it is not only the developers of an organisations custom application that fail to understand the Internet protocols correctly. Commercial developers of popular operating systems and hosting software have failed to grasp a lot of the nuances themselves. Many of the disclosed vulnerabilities relating to alternative character representations (e.g. escape and Unicode encoding) could have been averted by following existing HTTP guidelines and multitude of RFCs on handling client-data -particularly the recommendation to ensure that data is only ever decoded once. Authentication processes have always been a pivotal point in securing critical applications. Organisations constantly fail to grasp the many different methods clients can access their web application, and the scope of functionality their browsers may possess. Fundamental security best practices are often not observed. Authentication failures such as `This user does not exist" or "The password is incorrect', while helpful to site clients, also help attackers compromise the authentication process through automated processes.

Many organisations have found themselves under Press scrutiny for not understanding the significance of browsers caching page content or the consequences of clients using their application from shared and untrusted hosts (e.g. Internet caf6!5). Had the application developers better understood the communication protocols and popular browser functionality better, most often simple amendments to the applications code could have averted disaster.

Unfortunately, the knowledge required to ensure a web application has been developed securely is currently confined to only a small proportion of developers and security professionals. Although there are a multitude of books and electronic documents detailing the specific risks of known security flaws, and advice on good programming techniques, information on developing secure web-based applications is difficult to find. While there are many courses on how to program in C, or develop ASP applications, courses providing instruction specifically tuned to system developers on the necessary security fundamentals are not currently available.

www.iss.net