Web Security Solution List
Release Date: 11/29/2004
| Update Date: 11/29/2004
See all security guidelines theme
Microsoft Corporation
In this unit
This unit includes a roadmap that summarizes the security: threats and countermeasures. This guide provides links to the corresponding materials of this guide, making it easy to find the information and specific problems required. This unit is based on role, covering solutions for designers and architects, developers and administrators.
aims
Use this unit:
• Rapidly find solutions for specific security issues. • Fast and easy navigate this guide.
Use
This unit does not have any technical information, only guidelines for the following products and technologies:
• Microsoft® Windows® Server 2000 and Windows ServerTM 2003 operating system • Microsoft .NET Framework 1.1 • ASP.NET 1.1 • Microsoft SQL ServerTM 2000
How to use this unit
You can use this unit to find the security solution and reference to the Web application security: threats to the security solutions covered with the countermeasures.
The security solution introduced in this guide applies to the entire life cycle and a variety of roles. The solution roadmap described in this unit is organized for architects, developers and system administrators.
• Architect:
• "How to identify and evaluate threats?" • "How to create a safe design?" • "How to perform an architecture and design review?" • Developer:
• "What is .NET Framework Security?" • How to write secure managed code? "•" How to securely handle exception? "•" How to perform the security review of managed code? "• How to ensure the security of the developer workstation? "•" How to combine code access security and ASP.NET? "•" How to write code with the least authority? "• How to limit file I / O?" • "How to prevent SQL injection?" • "How to prevent cross Site scripting? "• How to manage confidential?" • "How to securely call unmanaged code?" • How to perform security input verification? "•" How to ensure the security of the form authentication? "• For administrators:
• "How to implement patch management?" • How to make the settings in Machine.config and Web.config? "•" How to ensure the security of the WEB server running .NET Framework? "•" How to ensure the security of the database server Sex? "•" How to ensure the security of the application server? "•" How to safely carry multiple ASP.NET applications? "•" How to ensure the security of Web services? "," How to ensure the security of corporate services ? "•" How to ensure remote processing security of Microsoft .NET? "•" How to ensure the security of the session state? "• How to securely manage the application's configuration?" • "How to prevent the service attack?" • " How to limit file I / O? "•" How to perform remote management? "
This page
Architecture and design solution development solution management solution
Architecture and design solutions
In order to help you design a secure web application, this guide provides architects with the following solutions:
• How to identify and evaluate threats to use threats to model system identifying threats, rather than applying security in any way. The threat is then evaluated according to the risk of attack or security damage and the possible potential loss. This allows threats to handle threats in order. For more information on creating a threat model and assessing the risk of threats, see the Threat Modeling unit. • How to create a secure design using an attempt or tested design principles. Concentrate in the critical area, in these areas, the method is correct and often there will be errors. This guide calls them as application defects categories. These include input verification, authentication, authorization, configuration management, sensitive data protection, session management, cryptographic system, parameter processing, exception management, and audit and logging. Pay special attention to deployment issues, including topologies, network infrastructure, security policies, and steps. For more information, see "Guidelines for Designing Security Web Applications" units. • How to perform architecture and design review of application design is related to the target deployment environment and related security policies. It is necessary to consider the limitations of the underlying infrastructure layer security (including boundary network, firewall, remote application server, etc.). Use the application defect category to help you classify your application and analyze methods suitable for each area. For more information, see the "Security Architecture and Design Check" unit. Back to top
Development solution
This guide provides developers with the following solutions:
• What is .NET Framework security? .NET Framework provides users and code security models that allow the operations that can be performed on users and code. To program a role-based security and code access security, you can use the type from the System.Security namespace. The .NET Framework also provides system.security.cryptography namespace, open symmetry, and asymmetric encryption and decryption, hash, random number generation, digital signature support, etc. To understand. NET Framework security basic settings, see ".NET Security Basics" units. • How to write a secure managed code to digitally sign the assembly with a strong name so that they cannot be changed at will. At the same time, you need to pay attention to the problem of strong name when combining the assembly and ASP.NET combined with the Strong Name. By following the sturdy object-oriented design principles, reduce the assembly attacker, then use code access security, and further limit which code can call your code. Use structured abnormal processing methods to prevent sensitive information from spreading to the current trust boundary, and develop more reliable code. Avoid routine problems, especially if you enter a file name and URL. For information on how to improve managed code security, see "Build a secure assembly" unit. For more information on how to effectively use code access security, see the Code Access Security Practice unit. For information on executing a managed code review, see the Security Code Review unit. • How to securely handle exceptions not to display detailed information for internal systems or applications, such as stack tracking, SQL statement pieces, etc. Make sure that such information is not allowed to spread to end users or current trust boundaries. Safely fail in an abnormal event, make sure the application refuses access, and does not stay in an insecure. Do not record sensitive or private data, such as passwords, to avoid harm. When the recording or report is abnormal, if the user's input is included in the abnormal message, it verifies or cleans it. For example, if an HTML error message is returned, you should encode the output to avoid script injection. For more information, see "Building a Security Jack" and "Building Security ASP.NET Page and Control" two "Exception Management" section. • How to perform a secure review of managed code Use analysis tools (such as FXCOP) to analyze binary sets, make sure they meet .Netframework design guidelines. Repair all security defects identified by the analysis tool. Use the text search tool to scan hard code confidential (e.g., password) source code library. After that, review the specific application elements, including web pages and controls, data access code, web services, service components, and more. Pay special attention to SQL injection and cross-site scripting to write defects. Also reviews the use of sensitive code access security technology, such as link declarations and assertions. For more information, see the "Code Review" unit. • How to ensure the security of the developer workstation You can use a set of methods to ensure the security of the workstation. Guaranteed your account, protocol, port, service, sharing, file and directory and registry security. Most importantly, keep your workstation have currently the latest patch and updates. If you run Internet Information Services (IIS) on Microsoft Windows_ XP or Windows 2000, run IISLOCKDOWN. ISLockDown applies secure IIS configuration and installs the URLSCAN Internet Security App Programming Interface (ISAPI) filter, which is used to detect and reject potential malicious HTTP requests. For example, you may need to modify the default Urlscan configuration so you can debug web applications during development and testing.
For more information, please refer to "How to Do" "How to Be" Safe for the Safety of Developer Workstations "in this guide. • How to combine using code access security and ASP.NET to use .NET Framework version 1.1, you can set the ASP.NET's trust level in Machine.config or Web.config. These trust-level use code access security to limit resources that the ASP.NET application can access, such as file systems, registry, network, database, etc. In addition, they also provide applications isolation. For more information about using code access security, development part trusted web applications and Sandbox privilege codes, see "Using Code Access Security" units in ASP.NET. For more information on the basis for code access security, see "Code Access Security Practices" unit. For more information on access security issues that need to be considered while developing hosting code, see "Building a Security Service Components", "Building a Security Web Services", "Building Secure Remote Components", and "Building Security Data Access "The" Code Access Safety Precautions "section of the unit. • How to write code with the lowest authority can limit the operation of the code to be executed, which is independent of the account used to run the code. By configuring strategies or how to write code, you can use code access security to limit the resources and operations to be accessed. If the code does not need to access certain resources or perform some sensitive operations (such as calling unmanaged code), you can use declarative security properties to ensure that the code will not be granted to this permission by the administrator. For more information, see "Code Access Security Practice" unit. • How to limit file I / O Use code access security to limit the assembly access to the file system area and perform I / O ability. For example, a web application can be restricted so that it can only perform file I / O under its virtual directory hierarchy. You can also limit file I / O on a specific directory. This can be done by programming or configuring code access security policies. For more information, see "File I / O" of the Code Access Security Practice "and" Media Trust "in" Using Code Access Security "in ASP.NET. For more information on configuring code access security policies, see "How to Use the CAS Policy Constraint Settings". • How to prevent SQL from injecting parameterized stored procedures using data access. Use parameters to make sure that the type and length of the input value are checked. The parameters are also considered as a secure code that is not executable within the database. If you cannot use a stored procedure, use the SQL statement with parameters. Do not build a SQL statement by connecting the SQL command and the input value. Also make sure the application logs in with a lowest authority to restrict its functionality in the database. For more information on SQL injection and further institution, see "SQL Injection" of "Building a Security Data Access" unit. • How to prevent cross-site scripts from verifying input type, length, format, and range, and encodes the output. If the output includes input (including web input), the output is encoded. For example, encoding a form field, query string parameter, cookie, and the like, and encodes an input read from a database (especially shared database) that cannot assume its data. The field is entered on the free format that needs to return to the client with HTML, encodes the output, and then selectively clears the encoding on the license element (such as or tag). For more information, see "Building Skating Scripts" for Building an ASP.NET Page and Controls. • How to manage confidentiality to look for alternatives to avoid storage confidentiality. If you have to store them, do not store in a clear text in the source code or configuration file. Use the Data Protection Application Programming Interface (DPAPI) encrypted confidential to avoid critical management issues.
For more information, see "Sensitive Data" of "Building Security ASP.NET Page and Control" units "Encryption" and "Safety" units of "Safety" units for the ASP.NET application "ASPNET_SETREG.EXE and Process, Session and Identification". • How to securely call the non-hosting code to pass the parameters transmitted to the non-hosting API and the non-hosting API to prevent potential buffers from overflow. Verify the length of the input and output string parameters, check the array boundary, and carefully carefully the length of the file path. Use custom permission declare to protect access to non-hosting resources before asserting the non-hosting code authority. If you use SuppressunManageDcodeSecurityAttribute to improve performance, be careful. For more information, see "Build a Security Jack" and "Code Access Security Practice" two units in the "Non-Managed Code" section. • How to perform secure input verification to limit, reject, and clean up the input, as verifying that the data that is known and scope is much easier than verifying data by looking for known error characters. Verify the type, length, format, and range of data. Enter a string, use the regular expression. To use the execution type check, use the .NET Framework type system. Sometimes, you may need to clean your input. An example is to encode data to ensure its security. For input verification design policies, see "Input Verification" of the "Guidelines for Designing Safety Web Applications" units. For details, see "Building a Security ASP.NET Page and Controls", "Building Secure Web Services", "Building Secure Remote Components", and "Build a Security Data Access" section section. • How to ensure the security of the Form authentication Web site, isolating the public accessible page that anonymous users can access and the restriction page that requires authentication access. Use a Secure Socket Layer (SSL) to protect form authentication credentials and form authentication cookies. Limit sessional survival time and to ensure that authentication cookies are only transmitted on HTTPS. For authentication cookie encryption, do not keep it on the client computer, do not use it for personalized purposes; individual cookies are used for personalization. For more information, see "Safety of ASP.NET Applications" and "Building Security ASP.NET Page and Control" two "Authentication" section. Back to top
Management solution
This guide provides the administrator with the following solutions:
• How to implement patch management Use Microsoft Baseline Security Analyzer (MBSA) to check patchs and updates that may miss now. Run this operation regularly and keep your server now have the latest patches and updates. Before applying patches, back up the server; before the patch is installed on the product server, test it on the test server. Also use the security notification service provided by Microsoft and subscribe to receive security checks by email. For more information, see "How to Implement Patch Management". • How to make the settings in Machine.config and Web.config Do not store passwords or sensitive data in express formation. For example, use the ASPNET_SETREG.EXE utility to encrypt
On the Microsoft Windows Server 2003 operating system, you can use a separate process identifier with the IIS6 application pool. On Windows 2000 Server, multiple anonymous Internet user accounts are used and allow simulation. On both platforms, through the .NET Framework version 1.1, a partial trust stage and the use of code access are available, further application isolation is provided. For example, these methods can be used to prevent applications from accessing to each other's virtual directory and important system resources. For more information, see "Carrying Multiple ASP.NET Applications" units. • How to ensure that the security of Web services can use Microsoft .NET's Web Service Enhancement 1.0 (WSE) of Microsoft .NET to implement message-level security solutions with Microsoft .NET Web Service Enhancement 1.0 (WSE). Pass the authentication token in the Simple Object Access Protocol (SOAP) header. Use XML encryption to ensure that sensitive data remains private. Use the digital signature to ensure the integrity of the message. Inside the enterprise capable of controlling two endpoints, the authentication, authorization, and secure communication functions provided by the operating system and IIS can be used. For more information, see "Securing Your Application Server" and "Guaranteed ASP.NET Application Safety" two units. For information on developing secure web services, see "Building a Web Services" unit. • How to ensure that the security of the enterprise service is configured using a server application running on the minimum authority account. Enable COM based on role-based security and implement component level access checks. At least use call-level authentication to prevent anonymous access. To ensure the security of the communication to the remote service component, use the IPSec encrypted channel or use the Remote Process Call (RPC) encryption. Limit the port range of distributed COM (DCOM) dynamically allocated or using a static endpoint map to limit the port range within a specific port. Regularly monitor the Quick Fix Engineer (QFE) update of the COM running library. For more information, see "Security" units that guarantee the application server. • How to ensure remote processing security of Microsoft .NET mapping the .REM, and. SoAP extension to the ASP.NET HTTPFORBIDDENHHANDLER HTTP module in Machine.config, remote processing on the Internet-to-Internet server. Home Strike In ASP.NET, you will benefit from ASP.NET and IIS authentication and licenses using the HTTPChannel type name. If you need to use the TCPChannel type name, use IPsec to limit which clients can be connected to the server in a Windows service. This method can only be used in the case of trusted servers, where remote processing clients (e.g., web applications) authenticate and authorize the initial caller. For more information, see "Security" units that guarantee the application server. • How to ensure that the security of the session status is transmitted on the network and in the status storage area, you need to protect the session state. If you use a remote status storage area, use SSL or IPSec to ensure the security of the communication channel to the status storage area. At the same time, encrypt the connection string in Machine.Config. If you use the SQL Server status storage area, use Windows authentication when connecting the status storage area, and restricts the application to log in to the database. If you use the ASP.NET Status service, run the service using the minimum authority account and consider changing the default port of the service listening. If you don't need a status service, disable it. For more information, see "Session Status" of the "Security" unit that guarantees the ASP.NET application.
