Web Application Security : Formal Trust and Authentication :
Secure web application design is not product-specific: it is helpful in securely designing and implementing any web application, regardless of the platform. This article, part of a series of security-related, but many of these concepts are relevant to any application development cycle, including non-web applications.
1 Formal Trust.
2 External Resources (Including Users).
3 Client Applications (Including Users).
4 Authentication (Trusting Identification).
5 Summary.
Keeping computer security issues at bay is a full-time job. These columns provide general education, point out common security issues in implementations, and can aid you in both design and troubleshooting. However, they are not a substitute for a full-time security specialist individual or group in your organization.
Bear in mind that individual links are provided for reference; they may not be applicable to your specific architecture or configuration. Be sure to carefully check whether the procedures suggested or described apply to your configuration before implementing them. Also, be sure to test any change to your current configuration or process in a testing environment prior to applying them in any production environment.
1 Formal Trust :
Last month’s column, How to Design Secure Web Applications, briefly discussed formal trust in the context of input validation and architectural research and design. This column discusses formal trust as a general concept, including how it relates not only to input validation, but also to topics such as working with external data resources (including users), building client-server applications (both web-based and not), and most importantly, authentication.
The first thing to keep in mind about formal trust is that it barely resembles the personal act of trusting (such as,. the “Can I trust my friend Bob?” idea). Formal trust is usually a calculation based on existing policies and on informed opinion about the implementation environment and relevant architecture in which an application is intended to execute. When a security analyst calculates the formal trust relationships for a given application implementation, she examines the requirements of the policy and existing procedure, compares these resources to the facilities provided by the data and other supporting resources, and makes implementation and design decisions based on how closely the resources match the policy.
Perhaps a more approachable way to think of the process of calculating formal trust is comparing it to a hiring process. Candidates must be appropriate to the position that is open, but beyond reading their resumes, it is still necessary to do background checks, interview them, and perhaps test them. You usually do this whether or not you personally think that candidates are trustworthy. You do it both because your HR policy states proper procedure for hiring someone to fill the role you need to fill and because you cannot afford to take chances. In no way is the standard way your company hires resources meant to be a personal criticism of a candidate; it is just the way the policy says it must be done.
