Este artigo foi traduzido por máquina. Coloque o ponteiro do mouse sobre as frases do artigo para ver o texto original. Mais informações.
Práticas de segurança básica para aplicativos da Web
Observação For comprehensive and detailed security guidance which will help you to design, develop, configure, and deploy more secure ASP.NET Web applications, see the security modules provided on the Microsoft Patterns and Practices Web site. Back up often and keep your backups physically secure. Keep your Web server computer physically secure so that unauthorized users cannot get to it, turn it off, or take it. Use the Windows NTFS file system, not FAT32. NTFS offers substantially more security than FAT32. Para mais detalhes, consulte a documentação do Windows. Secure the Web server computer and all computers on the same network with strong passwords. Secure IIS. For details, see the Microsoft TechNet Security Center Web site. Close unused ports and turn off unused services. Run a virus checker that monitors inbound and outbound traffic. Establish and enforce a policy that forbids users from keeping their passwords written down in an easy-to-find location. Use um firewall. For recommendations, see Microsoft Firewall Guidelines on the Microsoft security site. Install the latest security patches from Microsoft and other vendors. For example, the see the Microsoft TechNet Security Center Web site has a list of the latest security bulletins for all Microsoft products. Outros fabricantes têm sites semelhantes Use Windows event logging and examine the logs frequently for suspicious activity. Isso inclui repetidas tentativas de fazer logon no seu sistema e um número extremamente elevado de pedidos contra seu servidor web. Não execute o aplicativo com a identidade de um usuário do sistema (administrador). Execute o aplicativo no contexto de um usuário com os privilégios mínimos praticáveis. Set permissions (Access Control Lists or ACLs) on all the resources required for your application. Use a configuração menos permissiva. For example, if practical in your application, set files to be read-only. For a list of the minimum required ACL permissions required for the identity of your ASP.NET application, see ASP.NET Required Access Control Lists (ACLs). Keep files for your Web application in a folder below the application root. Do not allow users the option of specifying a path for any file access in your application. Isso ajuda a evitar que usuários obtenham acesso à raiz do seu servidor. If your application is an intranet application, configure it to use Windows integrated security. That way, the user's logon credentials can be used to access resources. Para obter mais informações, consulte ASP.NET Impersonation. If you need to gather credentials from the user, use one of the ASP.NET authentication strategies. For an example, see Gerenciando usuários usando Associação. In ASP.NET Web pages, filter user input to check for HTML tags, which might contain script. For details, see Como: proteger contra scripts maliciosos em um aplicativo da Web aplicando a codificação HTML a sequências de caracteres. Never echo (display) unfiltered user input. Before displaying untrusted information, encode HTML to turn potentially harmful script into display strings. Never store unfiltered user input in a database. If you want to accept some HTML from a user, filter it manually. In your filter, explicitly define what you will accept. Do not create a filter that tries to filter out malicious input; it is very difficult to anticipate all possible malicious input. Do not assume that information you get from the HTTP request header (in the HttpRequest object) is safe. Use safeguards for query strings, cookies, and so on. Be aware that information the browser reports to the server (user agent information) can be spoofed, in case that is important in your application. If possible, do not store sensitive information in a place accessible from the browser, such as hidden fields or cookies. For example, do not store a password in a cookie. Observação View state is stored in a hidden field in an encoded format. By default, it includes a message authentication code (MAC) so that the page can determine whether view state was tampered with. If sensitive information is stored in view state, encrypt by setting the page's ViewStateEncryptionMode property to true. Use the inherent security of your database to limit who can access database resources. The exact strategy depends on your database and your application: If practical in your application, use integrated security so that only Windows-authenticated users can access the database. Integrated security is more secure than passing explicit credentials to the database. If your application involves anonymous access, create a single user with very limited permissions, and perform queries by connecting as this user. Do not create SQL statements by concatenating strings that involve user input. Instead, create a parameterized query and use user input to set parameter values. If you must store a user name and password somewhere to use as the database login credentials, store them in the Web.config file and secure the file with protected configuration. For details, see Criptografando informações de configuração usando configuração protegida. Do not write error messages that echo information that might be useful to malicious users, such as a user name. Configure the application not to show detailed errors to users. If you want to display detailed error messages for debugging, determine first whether the user is local to the Web server. For details, see Como: exibir mensagens de erro seguras. Use the customErrorsconfiguration element to control who can view exceptions from the server. Create custom error handling for situations that are prone to error, such as database access. For more information, see Tratamento de erro em páginas e aplicativos ASP.NET. If your application transmits sensitive information between the browser and the server, consider using the Secure Sockets Layer (SSL). Para obter detalhes sobre como proteger um site com SSL, consulte o artigo Q307267, "como para: Proteger XML Web Services com Secure Socket Layer no Windows 2000 " no Microsoft Knowledge Base em http://support.microsoft.com. Use protected configuration to secure sensitive information in configuration files such as the Web.config or Machine.config files. Para obter mais informações, veja Criptografando informações de configuração usando configuração protegida. If you must store sensitive information, do not keep it in a Web page, even in a form that you think people will not be able to see it (such as in server code). Use the strong encryption algorithms supplied in the System.Security.Cryptography namespace. Do not store any critical information in cookies. For example, do not store a user's password in a cookie, even temporarily. As a rule, do not keep anything in a cookie that, if spoofed, can compromise your application. Instead, keep a reference in the cookie to a location on the server where the information is. Set expiration dates on cookies to the shortest practical time you can. Avoid permanent cookies if possible. Consider encrypting information in cookies. Use error handling (for example, try-catch). Include a finally block in which you release resources in case of failure. Configure IIS to use process throttling, which prevents an application from using up a disproportionate amount of CPU time. Test size limits of user input before using or storing it. Put size safeguards on database queries. For example, before you display query results in an ASP.NET Web page, be sure that there are not an unreasonable number of records. Put a size limit on file uploads, if those are part of your application. You can set a limit in the Web.config file using syntax such as the following, where the maxRequestLength value is in kilobytes:
<configuration> <system.web> <httpRuntime maxRequestLength="4096" /> </system.web> </configuration>
You can also use RequestLengthDiskThreshold property in to reduce the memory overhead of large uploads and form posts.