Security | Security of database in ASP is a serious problem. Many code writers are aware of this type of problem and are careful to remedy what they think is problematic, but the common scenario is either not to exhaust all suspicious locations, or the remedy is logically incorrect. For a patient and sensitive attacker, there is no fundamental difference between remedial measures in this sense and no remedy at all.
Here are some of the possible problems: some are common mistakes, and some are logically problematic. See if you've written that too? For attackers, looking at these things upside down should be a bit of a help in finding vulnerabilities, a more complete detection method, please wait for my article on black/White box analysis and automated testing.
A confusing way to filter
A typical example is to remove single quotes from all input variables regardless, or to replace single quotes with valid two single quotes, such as:
id = replace (request.querystring ("id"), "'", "") str = replace (Request ("Someinput"), "'", "" "
It is now clear that the first approach is likely to be wrong. Because the SQL injection is not always single quotes, and then widened a little, causing problems is not any individual symbols, such filters, some of the wrong single quotes. The correct use of injection, the important point is to close the previous sentence of the SQL query--often have to correctly close the previous condition, because we may introduce new conditions in the same sentence, remedial measures as long as the damage to the injection conditions should be available, but given its complexity (as will be said below), It is best to limit the types of characters you enter.
The second seems to be no problem, but there are potential pitfalls. It's easy to create the illusion that I have been very effective in the input of the string has been processed, the future use of no problems. This sentence is not wrong, this is also true for strings, but he played a disgraceful role, just imagine, if the filtered string into the database, and the subsequent statements are directly out of use, this filter on the front of the dependency is not correct?
Perhaps a better approach would be to determine the criteria for filtering in specific cases.
There are three kinds of common input variables: numbers, strings, and collections. For digital input variables, a simple call to the judgment function can be seen in the code, all the checks of such variables, almost all correct. For a string type, basically there is a single quote before and after inserting into the generated SQL statement, and if only from the break injection condition, replacing the single quotation mark with the two single quotes should not be a problem. Similarly, if you are a collection of strings, you can simply use this method. And if it's a collection of numbers, the situation can be a little bit messy, at least you have to allow symbols such as numbers, commas, and spaces to appear normally in the input, so the filter rules may seem complicated, However, you can draw on the dvBBS6.1 after the patch version, in general, for the filtering vulnerabilities have been found, they still make a better complement.
For the second sentence, at least now can not say that it is wrong, we left behind to solve.
Second, the data obtained is trustworthy?
In fact, the scope of such a child is a bit large, all of a sudden involves a lot of aspects, an example of an example to look good.
The first is the question of choosing to filter the data. All along, we think that all user input of things, should be properly handled. Yes, but is the real thing done? Grab a bag of tools, like ethereal, and see what you're submitting when you submit your form with IE or open the connection. Or, simply, open netant edit a task, in the Protocol tab, look at the "Custom Submitter" and "User Agent" options.
I think you've learned that the other person can customize something more than just get or post the data! If all the users are using the browser properly, do not have to guard against such a strict, if the other side is not so honest, when the server variables or cookies to take care, no one can guarantee that the data you obtained is legitimate. For cookies, many programs have been problematic, so it has been emphasized a lot before, as for others, the person concerned may be less, but have you seen or written this 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 agent option you see in netant, which means you can forge, and also fake, Request.ServerVariables (" Http_referer "), which is the submitter option you see in Netant, and so on. When doing some projects, it is possible to add this class of variables into the database, this time to be careful, the neglect of this place, the consequences caused by other types of variables are not filtered results are the same.
Google search for Referer and request.servervariables Two keywords, you can also see a lot of problematic writing, or to see the May about the Internet forum invasion of the article, perhaps your understanding will be more profound.
Then there is a slightly deeper hidden problem, not the user's direct input to do not filter?
This goes back to the question we left behind, with the single quotation mark being replaced by a potential threat of two single quotes. When the SQL statement is constructed for the second time, if the data is taken directly from the database, most of the time people will think that what has been dealt with earlier seems to be unnecessary to deal with, or simply not aware that it should be handled. This is extremely wrong! From two aspects, first of all, when you are in the warehouse to submit data in the single quotation mark processing, only to ensure the correctness of the structure of a single SQL statement, and did not solve the problem once and for all; again, the reliance on data security checks is not guaranteed when the data is taken out, because the dependencies are not passed down , and the dependencies themselves are not yet available.
In the case of replace (Request ("Someinput"), "'", "" ", its unease is that this filter is only a compromise, in other words, only in a limited scope to cover up the problems that may arise, but not permanently disposed of. It also has a nasty place to give people an illusion, it seems that the processed data has been safe, it is easy for subsequent code writers to create a false sense of security. These two weaknesses, not by a change in the wording can be solved, because if you simply remove the single quotation mark, it will lead to another problem, the input data is really necessary and the correct single quotes do? From the very beginning I said that the single quotation mark itself is innocent, filtering it is only a solution, so let's write it, but we need to strengthen the inspection in the subsequent part.
This kind of question, if still use the dynamic Network forum to do an example, I suggest to look at the loophole article of June 8.
There is the location of the filter, which is a complex problem with a logical problem.
I have been very surprised to find a strange problem code in the release of the Joek forum, and if you're interested, flipping through the gallery.asp can see a specific sequence of actions (Action=flash_view), bypassing all checks for IDs.
In fact, speaking up, this kind of code is not likely to have too complex logical structure, when the code is reviewed, all branch coverage can be done by hand, as long as a little thought will find the check of the variables can effectively reach your destination-the place where the SQL statements are generated.
About the location of the filter, if you want to go deep, will come out some dazzling things, the middle of the analysis is very cumbersome and very formal, although there are algorithms to ensure the correctness of location selection, but I think here is to give some conclusive things. If you are interested, I think you can write and communicate with me.
The location of the filter depends on two aspects: you get the source of the variable and the location where you need to make sure to generate the SQL statement. The front one, whether it comes from direct or indirect input, think about the possible input characters first; for the back one, you have to make sure that no matter how the program is running, the process of filtering the statement will pass through the location of the SQL statement you need to ensure that it is a valid filtered statement. If you are not very clear about the process of judgment, my suggestion is if only to judge, if nested suites do not have superfluous things, filter statements immediately after the generation of SQL statements.
Back to the potential problems mentioned earlier, we can finally solve this problem: After the data is taken out, we still judge first. Because, according to the foregoing, this type of indirect input is still likely to be dangerous.
Here, insert an alternative filter location problem: Do not put the filter on the input to the client to solve, it can be bypassed! Who can guarantee that your vbscript/javascript will work if someone uses NC or a browser that doesn't support scripting?
The above two big aspects, with the eyes of software testing to understand, is clearly not exhaustive all the branches caused. Before using the data submitted by each other, make an analysis list of all possible characters, and then type an audit of each of the input branches, which is what every code writer should do. This is a very simple thing, because only the type of audit is OK, the problem of the semantic problems ...
Third, the type of correct means to release?
When it comes to semantics, if possible, I'd prefer to avoid it.
For example, for an integer number, you actually enter an integer, and through the filter, the potential problem is that your input is legal, or that you shouldn't get information from you at all? It was suggested many years ago that some of the registered modules had a problem: the IDs inside it were implicitly submitted through a Type=hidden cover-up, but I created the user in the first step, and the second step was the possibility of submitting an illegal ID to modify someone else's information. This kind of heterogeneous problem is very difficult to find, and almost all only rely on experience rather than a specific algorithm to deal with. We
