Home Biblioteca Aprender Galeria Downloads Suporte Comunidade Fóruns
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.
Tradução
Original
0 de 1 pessoas classificaram isso como útil - Avalie este tópico

Visão geral de scripts maliciosos

.NET Framework 4

From the perspective of a browser, a Web page is simply a long string of characters. The browser processes the string sequentially, displaying some characters while interpreting other characters, such as <b> and <script> according to special rules. If a malicious user can insert some of those special characters into a page, the browser will not know that the characters are not supposed to be there, and it will process them as part of the page.

A simplistic script exploit might work as follows. If an application allows users to post comments about the latest movies for other users to read, the exploit steps might be:

  1. The application displays a form where users enter comments. The malicious user writes a comment that includes a <script> block in it.

  2. The form is posted and the malicious user's comment is stored in a database.

  3. Another user visits the site. When the page is constructed, it reads comments out of the database and puts them into the page. The malicious user's <script> block is written into the page as if it were a text comment.

  4. When the second user's browser displays the page, it gets to the <script> block and executes it.

There are other ways that malicious users can exploit script. Most script exploits require the application to accept the malicious input and inject it (or echo it) into a page where it will be executed by the browser. The potential damage from such an exploit depends on the script that is executed. It can be trivial, such as an annoying message that pops up in the browser. But it can also do serious damage by stealing cookies, stealing user input (such as a password), and, if Internet security is lax, running native code on the user's computer.

For information about preventing script exploits, see Como: proteger contra scripts maliciosos em um aplicativo da Web aplicando a codificação HTML a sequências de caracteres.

ObservaçãoObservação

ASP.NET ajuda a proteger contra script maliciosos disfarçados como URLs verificando cadeias de caracteres potencialmente perigosas, como "<!", "< /", e "<?". For more information, see HtmlEncode and ValidateRequest.

A variation on a script exploit is one that causes malicious SQL statements to be executed. This can occur if an application prompts users for information and then concatenates the user's input into a string representing the SQL statement. For example, an application might prompt for a customer name with the intention of executing a statement, such as the following:

Copiar 
"Select * From Customers where CustomerName = " & txtCustomerName.Value

But a malicious user who knows something about the database could use the text box to enter an embedded SQL statement with the customer name, resulting in a statement like the following:

Copiar 
Select * From Customers Where CustomerName = 'a' Delete From 
Customers Where CustomerName > ''

When the query is executed, the database is compromised.

The primary defense against scripting exploits is to never trust information coming from a user. Assume that any data posted to your application from a browser can contain malicious script.

Similarly, any time that you write a string into a page, you should assume that the string could contain malicious script (unless you programmatically created the string yourself). For example, when you read strings out of a database, you should assume that they can contain malicious script. The most security-conscious developers distrust even their own databases, on the theory that a malicious user might have found a way to tamper with the database.

ASP.NET provides you with several ways to help protect against scripting exploits:

  • ASP.NET performs request validation against query-string and form variables as well as cookie values. By default, if the current Request contains HTML-encoded elements or certain HTML characters (such as &#151; for an em dash), the ASP.NET page framework raises an error.

  • If you want to display strings in your application but do not trust them, apply HTML encoding to them when the strings are written back in a response. For example, with encoding, the tag <b> becomes &lt;b&gt;. You might do this if the strings that you are displaying are from a database whose contents you are not sure that you can trust.

  • If you want your application to accept some HTML (for example, some formatting instructions from users), you should encode the HTML at the client before it is submitted to the server. For more information, see Como: proteger contra scripts maliciosos em um aplicativo da Web aplicando a codificação HTML a sequências de caracteres.

  • To help protect against SQL statement exploits, never create SQL queries using string concatenation. Instead, use a parameterized query and assign user input to parameter objects.

  • Always validate form input against a set of expected values and string formatting/type validation. Por exemplo, se umavariável de formuláriode específico deve ser um inteiro, use o TryParsemétodo para verificar o que realmente o valor é um inteiro e usar o intervalo de verificação para ajudar a garantir que o valor está dentro do intervalo aceitável.

Isso foi útil para você?
(1500 caracteres restantes)

Contribuições da comunidade

ADICIONAR
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Politica de Privacidade
© 2013 Microsoft. Todos os direitos reservados.
|
Comentários sobre o site
© 2013 Microsoft. Todos os direitos reservados.