Write secure ASP code

The security of databases in ASP is a serious issue. Many code writers are aware of such problems and carefully remedy what they think is problematic. However, it is common that they either fail to exhaust all suspicious locations, either this remedy is logically incorrect. For a patient and sensitive attacker, the remedy in this sense is essentially different from the remedy without any remedy.
The following are some possible problems: some are common mistakes, and some are logical problems. See if you have written this? For attackers, looking at these things backwards should be helpful in finding vulnerabilities. For more complete detection methods, please wait for my article on black/white box analysis and automated testing.

I. Confusing filtering methods

A typical example is to remove single quotes for all input variables, or replace single quotes with valid two single quotes. For example:

Id = Replace (request. querystring ("ID "),"","")
STR = Replace (Request ("someinput "),"","")

It is clear that the first practice is likely to be wrong. Because SQL injection is not always caused by single quotation marks, and a little more, the problem is not any separate symbol. Such filtering may lead to some single quotation marks. Correct use of injection, the important point is to close the previous SQL query statement-usually first, the previous condition must be properly closed, because we may introduce new conditions in the same sentence, remedial measures should be enough as long as the injection conditions are damaged, but considering the complexity (which will be discussed below ), it is better to completely limit the types of characters entered.
The second one seems to be okay, but it may bring some potential risks. This can easily lead to the illusion that I have processed the input string effectively and there is no problem in using it in the future. This statement is correct. It is also true for strings, but he plays an unsightly role. If the filtered string is put into the database, the subsequent statements are used directly. Is this dependency on the previous filter correct?

It may be better to determine the filtering criteria based on specific conditions.
There are three common input variables: Numbers, strings, and collections. For numeric input variables, simply call the judgment function. As you can see in the code, almost all variables that have been checked are correct. For string-type SQL statements, there are single quotation marks before and after they are inserted into the generated SQL statement. If you replace single quotation marks with two single quotes only when the injection condition is damaged, it is not a problem. Similarly, if it is a string set, you can simply use this method. If it is a set of numbers, the situation may be a little troublesome. At least you have to allow numbers, commas, or spaces and other symbols to appear normally in the input. Such filtering rules may look complicated, however, you can refer to the version after dvbbs6.1 has been patched. In general, it is better for the detected filtering vulnerabilities.
For the second sentence, at least we cannot say it is wrong now. We will leave it for later solutions.

2. Are the obtained data trustworthy?

In fact, it seems that the scope is a bit large, and it involves many aspects at once. Let's take an example to illustrate it.

The first is about data filtering. For a long time, we have considered that all user input must be properly handled. Yes, but is it true? Find a packet capture tool, such as ethereal, to see what is submitted when you submit a form using IE or open a connection. Alternatively, you can open netant to edit a task. In the Protocol tag, check the options of "Custom submitter" and "User proxy.
I think you already understand that what the other party can customize is not just get or post data! If all users use browsers in a regular manner, they do not have to be so strict with each other. If the other party is not so honest, be careful when retrieving server variables or cookies, no one can guarantee that the data you obtain is legal. For cookies, many programs have encountered problems, so they have been emphasized a lot before. In addition, there may be fewer people interested, but have you ever read or written such code:

SQL = "showhot_com_inst_online_char 2," & statuserid & "," & membername & "," & memberclass & "," & request. servervariables ("remote_host") & "," & boardid & "," & request. servervariables ("http_user_agent") & "," & replace (stats, "", "") & "," & request. servervariables ("http_x_forwarded_for") & "," & usergroupid & "," & actcome & "," & userhidden & "," & userid &""

Request. servervariables ("http_user_agent") is the user proxy option you see in netant. That is to say, you can forge a request. servervariables ("http_referer"), that is, the submitter options you see in netant. When you are working on some projects, it is very likely that you need to add such variables to the database. At this time, be careful when you ignore these variables, the consequences are the same as those of other types of variables that are not filtered.
Search for Referer and request on Google. servervariables has two keywords: You can also see a lot of problematic statements, or you may have a deeper understanding of articles about the invasion of the Internet forum around July.

Then there is a hidden question. Do you want to filter the user input directly?
This is back to the question we left before. The single quotation mark is replaced with two single quotation marks, which is a potential threat. When constructing an SQL statement for the second time, if the data is directly retrieved from the database, in most cases, people will think that the previously processed items do not seem necessary to be processed, or you just don't realize that you should handle it. This is extremely wrong! From two aspects, when you import data into the database, you only process the single quotation marks in the submitted data to ensure the correctness of the construction of a single SQL statement, and do not solve the problem once and for all. Besides, the dependency on the data security check is not guaranteed when data is taken out later, because the dependency is not passed, and the dependency itself is not passed.
In the case of Replace (Request ("someinput"), "", ""), its uneasiness lies in that this filtering method is just a compromise, in other words, it only masks possible problems within a limited scope and does not permanently deal with them. It also seems to be an illusion that the processed data is secure, and it is easy for subsequent code writers to have an illusory sense of security. These two vulnerabilities cannot be solved by changing the writing method, because if you simply remove the single quotation marks, it will lead to another problem, what should I do if there is a required and correct single quotation mark in the input data? From the very beginning, I said that single quotes are not guilty, and filtering is just a solution. So let's write it like this, but we should strengthen the check in the subsequent sections.
If you still use the dynamic network forum as an example for this type of problem, I suggest you read the vulnerability article in June 8.

There is also the location of the filter, which is mixed with complicated problems including logic issues.
I was surprised to find that a piece of confusing code in the version released by the qiaoke Forum is very interesting. If you are interested, flip through the gallery. ASP can see a specific action sequence (Action = flash_view), bypassing all ID checks.
In fact, this type of code is unlikely to have too complex logic structures. During code review, all branch overwrites can be done manually, just think a little bit and you will find that the variable check can effectively reach your destination-where the SQL statement is generated.
As for the position of the filter, if you want to go deeper, something will be dazzled immediately. The analysis in the middle is very troublesome and very formal, although there are indeed algorithms that can ensure the correctness of location selection, I would like to give some conclusive information here. If you are very interested, I think you can come and communicate with me.
The location of the filter depends on two aspects: the source of the variable you get, and the location of the SQL statement you need to ensure. The previous one, whether directly or indirectly entered, first considers possible input characters. For the next one, make sure that no matter what the program is running, the process of filtering statements will surely go through the location where you need to ensure that the SQL statements are generated (to ensure that they are valid filtering statements and then necessary nodes ). If you are not clear about the process, I suggest that you only judge in If. There should be no additional items between if nesting. filter the statement and then generate the SQL statement.
Back to the potential problem we mentioned above, we can finally solve it here: we can judge the problem first after extracting the data. As mentioned above, this indirect input may still be dangerous.
Speaking of this, insert an alternative filtering location: do not put the filtering of input on the client, it can be bypassed! Who can ensure that your VBScript/JavaScript can work, if someone else directly uses NC or a browser that does not support scripts?

The two major aspects mentioned above are clearly caused by the failure to exhaust all the branches due to the vision of software testing. Before using the data submitted by the other party, first make an analysis list of all possible characters of the other party, and then review the type of each input branch, this is what every code writer should do. This is a very simple task, because the type audit is good, and it is troublesome to encounter semantic problems ......

3. Is the correct type permitted?

I chose to avoid semantic issues if possible.
For example, for an integer number, your input is indeed an integer. After passing the filter, the potential problem is that your input content is legal or you should not obtain information from you at all? Some people mentioned this many years ago that some registered modules have problems: the ID in it is implicitly committed after being masked by a type = hidden, but I have set up a user in the first step, in step 2, it is still possible to modify others' information by submitting an invalid ID of the content. Such heterogeneous problems are very difficult to find, and almost all of them are handled by experience rather than a specific algorithm. When we contact the previous one, we may be more clear when we think about it. For the input string, we feel that there is no filtering or error, because it is a set of numbers, A string can hold almost all possible input sets. In fact, it is common that the single quotation marks are incorrectly matched without filtering, resulting in SQL injection. Strictly speaking, this is also a semantic issue. However, in such special cases, you can ensure that the semantics is correct by processing single quotes in the input. So I have repeatedly stressed that single quotes are not guilty, but they are just a black box carrying semantics.
Unfortunately, if there is a semantic problem with integer data, nothing can be left blank for semantics, so there is no general solution to a certain extent. But don't be pessimistic. As we have mentioned earlier, we can avoid it if we can avoid it. Just pay off the salary and don't make variables that may have semantic problems as input.
If we only consider database security, almost all the semantic problems with threats occur in database operations, so we only need to pay attention to the update/insert statements, if you consider the security of data content, the SELECT statement must also be considered. In general, we pay special attention to the condition statements after the generated where statement. We always think that the semantics of the condition should be determined by the server side, rather than what the user input is. My suggestion is that all integer variables that may have semantic problems should be session variables. Of course, there is no in-depth research, some people may be able to propose effective methods like dealing with the semantic problem of strings. However, in terms of semantics, the filtering of strings does not prove unsafe, but more importantly, no one can prove its security, but it is no problem for everyone to use it now, this is the default value.
If you want to analyze the semantics in depth, a lot of strange things will pop up, so let's stop it. I really hope that there will be more exchanges between colleagues in this field!

The above mentioned may be used more to remedy existing code. If a software is built from the beginning, the above is only a reference for design. All vulnerabilities are due to design defects. A good software should prove that its model is correct, which is difficult but can be achieved. If you have proved the correctness of the software at the beginning, I don't think there will be any loopholes that can be drilled.