Asp.net| attacks Web site security, many times, almost represents the security of a unit network. For the site as a corporate external image of the enterprise or Government, the site security is more important. Now many sites have installed a firewall and other security equipment, but some simple offense, but rather nerve-racking. For example, through the site, the submission of malicious code, which is more difficult to prevent an attack, a relatively simple specific examples, in need of users to submit email address data items, if the user submits the following information: <script>alert ("Hello from SCRIPT") </script>, what will be the result? When other users enter the page containing this information, you will see a pop-up message, which is the result of the direct operation of the malicious code submitted above, if such code changes slightly, more complex, the effect of natural damage is even more amazing. Programmers in the design of the program, if not better consider the user to submit information for appropriate testing, it is easy to because the program is not sound and lead to unpredictable consequences. In ASP and asp.net1.0 or any other development tool, we have to use some techniques in the program to guard against malicious code submitted by users, and the principle of programming is "to assume that every user submits a malicious message", Programmers have to come up with some energy to do the testing of submitting information. In the latest release of the asp.net1.1, such a test is simple or even unnecessary. Now, let's look at a concrete example:
The above code is very simple, that is, the user input information to the reality, after the operation is such:
The above we enter a simple "Hello world", you can see that the page is very normal to display, then, if we enter "<script>alert (" hello! ") </script> "What will happen?" Now let's look at the results of the operation:
Obviously, it is an error message: "Potentially dangerous request.form value was detected ..." means that the information submitted by the user is potentially dangerous, so it is not submitted. This is one of the newest features of ASP.net, which excludes the potential danger of submitting information to the user, and, of course, it's easy to use this latest feature, which can be set directly on the page:
<%@ Page validaterequest= "true"%>
Alternatively, you can set it in the Web site configuration file web.config:
<configuration>
<system.web>
<pages validaterequest= "true"/>
</system.web>
</configuration>
Of course, to cancel this feature is also possible, directly in the above set false to true. We strongly recommend that the above features be opened and set to TRUE to detect each user's input. Now, let's see what happens to the page if the user closes the above features now:
As you can see, after the above page runs, there is the result of user input running directly: Pop up a hint message.
Then, if the user does not want to use the new features of asp.net1.1, but also want to be able to better implement the security of the program, what should be done? You can use Server.HTMLEncode (string) directly to convert all users ' input to HTML format, which is the information entered by the actual user (as it is realistic and typed) without running the malicious code. Now, let's look at an example:
The only difference between the above code and the preceding code is HTML encoding the user input, and the results are as follows:
We can see that users with potentially dangerous inputs have been completely avoided. What is the difference between the above and the new features of adopting asp.net1.1? The above approach still accepts user input, only modifies the dangerous code, while using the new features of asp.net1.1, the dangerous code is completely shut out and does not process the data.
We've experimented with the latest features of asp.net1.1 and compared it to other technologies. In programming, we recommend using the new features provided by asp.net1.1 directly to implement hazard exclusions, rather than using HTML encoding.
