Restful Development: Practical Design Guidelines for Web and Database Software

Restful Development is a management and architectural style advocating pragmatic practice with appropriate industry standards. The links provided below are cited as references and lead to supporting material on other websites.

Guidelines for Secure Processing

Web database applications accessible to the public Internet are guaranteed to be the target of random or focused attempts at mischief or abuse and Recovering From a Root Compromise [cert.org] is always painful. Secure web applications require the planned design and consistent implementation of diverse technologies based on realistic Threat Modeling [microsoft.com], education in the Most Critical Security Vulnerabilities [owasp.org], an understanding of the implications for Trusting Trust [bell-labs.com] and the potential for Risks To The Public In Computers and Related Systems [ncl.ac.uk]. E-commerce websites should also be familiar with PCI Security Standards [pcisecuritystandards.org] for payment card processing. Of course, all would-be security practitioners should also be aware that many in the industry more or less believe in The Complete, Unquestionable, And Total Failure of Information Security [securityabsurdity.com]

Use Least Privileges

Grant users and applications the minimum permissions required to complete a task and only for the time it takes to execute the task. Whenever possible, design for and configure the native Group and/or Role based permissions supported by all major web and database servers while minimizing the use of administrative accounts.

Validate All Input

By design, a web user agent can directly submit arbitrary input values for all HTML QUERYSTRING variables, FORM posts, COOKIE files, and HTTP HEADER information (such as the REFERER) to the server application. Secure web database applications consider all user input as inherently untrustworthy or "tainted". This tainted user input has a contaminating effect such that any value combined with it or otherwise derived from it becomes tainted as well. Saving this tainted input to persistent storage such as a database a text file will not magically remove the taint or increase its trustworthiness. All inputs must be checked for proper formatting, boundary conditions, and "white-lists" of allowable values when possible.

Although most popular browsers do not allow direct manipulation of REFERER information, it is a trivial task using any number of other tools including ASP, PERL, or TELNET. COOKIE files are just text stored on the user's file system and may be easily inspected and modified. FORM posts are easily submitted from any HTML page and not just the one you are expecting. QUERYSTRING manipulation requires only typing new information after the "?" character in the URL displayed in a web browser's address bar. The relative difficulty of spoofing the REFERER header versus typing a new QUERYSTRING in the browser does not make the REFERER header significantly more secure.

Client side validations using JavaScript or VBScript cannot ensure the integrity, format, or trustworthiness of user input. The results of client-side validations must eventually sent back to the server using untrustworthy FORM, QUERYSTRING, or COOKIE values.

Sanitize All Output

References