We're moving into section nine in which we're going to assess a mitigate vulnerabilities in web-based systems. So in this particular portion of our domain three, we're going to look at suggested protections for the web, Extensible Markup Language, SAML, the Security Assertion Markup Language and we're going to look at some comments and recommendations made by OWASP, the Open Web Application Security Project People. 

Now as a beginning point, we want to suggest that having a particular assurance sign-off process for web servers is one of the very best ways to begin. This means that we have a formalized process of review, that at its conclusion as the decisions made by the parties reviewing the web, the web application, the web servers and then having reviewed the code and its processes, if only at a functional level, signing off to say that yes, it's ready to go. Part of that process leading up to the sign-off should be hardening the operating system used on such servers. 

Now, system hardening is, of course, a very commonly exercised practice but it's one that we have to exercise with especial diligence because this particular system is going to be exposed on the web as opposed to being strictly internal. Being exposed on the webs means it's going to be available worldwide most likely. So we need to take various steps to ensure that it's prepared for that. Removing default configurations and accounts, configuring permissions and passwords and privileges correctly, keeping up to date with vendor patches and of course, removing all of the stored back doors and passwords that may be embedded in it during the development cycle. And we need to extend the web and network vulnerability scans prior to deployment because once it's out there, we're going to have to do them in a live-fire kind of an environment. Better we should do it before it goes there. We want to passively assess IDS and other forms of intrusion prevention systems. 

Now, on the web, the IDS or IPS type of platform may prove to be infeasible, nonetheless, it is something that we should investigate for application. Using application proxy firewalls in the appropriate usage case. Disabling any unnecessary code libraries or better yet, removing them if they're not necessary for its operation and then making sure that administrative interfaces are removed or secured. The basic rule here should be if it's not needed for the application to function properly on the web, why have it in there. It should simply be removed. Otherwise, just because it's been inactivated doesn't mean it couldn't be reactivated or in some way exploited by attacker. 

One mistake that is frequently made and unfortunately, attackers find this to be a fairly common occurrence is the hard coding of the authentication credentials into the application itself. This is a way that we are able to very effectively shoot ourselves in the foot and so going through the final pass before an application or a web server type system gets provisioned on the web, we need to pass it through configuration control one more time to make sure that these have all been identified and removed. If we're going to use certificates, we need to be sure that the security of the credentials using these certificates are of high trust qualities. 

There should be a function that does account lock-out and supplies extended logging and audit and protects all authentication traffic with encryption. And then, as we do with all parts of any application that are going to be exposed to an unknown or untrusted network or source of users, as the internet is, we need to be sure that there is no single point of failure or weak link in this particular chain. So we need to be sure that the interface is every bit as secure as the rest of the application itself. 

We need to be sure that we have verified the input validation, functions as, and only as, its design is supposed to. And due to the fact that this again going to be available worldwide, this becomes a critical factor. We have to be sure that the application proxy firewall is able to deal with the input problems of buffer overflows, authentication issues, various forms of unwanted scripting or disallowed scripting, any form of OS or SQL command injection that will pass through to the underlying platform and then making sure that URL encoding and translation is also a feature that cannot be subverted or spoofed. 

The Extensible Markup Language specified by W3C is the standard for structuring data in a text file so that the format of the data and the data itself can be shared. Now, the markup language that accompanies this, frequently HTML, is simply a system of symbols and rules to identify structures. Now, this may seem on its face like it has very little relationship to the topic of security that we're discussing but many of the things that get subverted are in a similar state. The relationship is not necessarily obvious but by proper encoding, we strengthen the security and the resistance to subversion of all the applications and processes that we put out on the web. So we do the Security Assertion Markup Languages or SAML and this XML-based standard is used to exchange and harmonize authentication and authorization information within and across multiple systems. It is, from its outset, designed to be secure and where we find it to be used is in the federating of systems with different identity management systems so that they interact quite possibly through a simplified sign-on or even single sign-on exchanges. 

One of the mechanisms for doing this is OpenID. OpenID acts as an interoperable authentication protocol based on the OAuth 2.0 family of specifications and is finding itself very widely used in web applications. Now, the Open Web Application Security Project provides a great deal of information, generally free of charge, in the areas that you see here. They have a Top 10 Project. Like many others, they identify the top 10 attacks that succeed most frequently. They have a Project Guide, they have a Software Assurance Maturity Model called SAMM and they have a Mobile Project guide.