Improving Web Application Security: Threats and - CGISecurity

lxviiiImproving Web Application Security: Threats and Countermeasures●●●●How to write least privileged codeYou can restrict what code can do regardless of the account used to run the code.You can use code access security to constrain the resources and operations thatyour code is allowed to access, either by configuring policy or how you write yourcode. If your code does not need to access a resource or perform a sensitiveoperation such as calling unmanaged code, you can use declarative securityattributes to ensure that your code cannot be granted this permission by anadministrator.For more information, see Chapter 8, “Code Access Security in Practice.”How to constrain file I/OYou can use code access security to constrain an assembly’s ability to access areasof the file system and perform file I/O. For example, you can constrain a Webapplication so that it can only perform file I/O beneath its virtual directoryhierarchy. You can also constrain file I/O to specific directories. You can do thisprogrammatically or by configuring code access security policy.For more information, see “File I/O” in Chapter 8, “Code Access Security inPractice” and “Medium Trust” in Chapter 9, “Using Code Access Security withASP.NET.” For more information about configuring code access security policy,see “How To: Use Code Access Security Policy to Constrain an Assembly” in the“How To” section of this guide.How to prevent SQL injectionUse parameterized stored procedures for data access. The use of parametersensures that input values are checked for type and length. Parameters are alsotreated as safe literal values and not executable code within the database. If youcannot use stored procedures, use SQL statements with parameters. Do not buildSQL statements by concatenating input values with SQL commands. Also, ensurethat your application uses a least privileged database login to constrain itscapabilities in the database.For more information about SQL injection and for further countermeasures, see“SQL Injection” in Chapter 14, “Building Secure Data Access.”How to prevent cross-site scriptingValidate input for type, length, format, and range, and encode output. Encodeoutput if it includes input, including Web input. For example, encode form fields,query string parameters, cookies and so on, and encode input read from adatabase (especially a shared database) where you cannot assume the data is safe.For free format input fields that you need to return to the client as HTML, encodethe output and then selectively remove the encoding on permitted elements suchas the or tags for formatting.For more information, see “Cross-Site Scripting” in Chapter 10, “BuildingASP.NET Pages and Controls.”