Filter user data is a Web application security. It is to verify the legitimacy of the process data. Through all of the input data is filtered to avoid malicious data in the program to be mistaken belief or misuse. Most Web application vulnerabilities because no user input data for proper filtration caused.
We introduce filtering data is divided into three steps:
- the identification data, the data needs to be filtered to figure out from where
- the filtering data, we need to figure out what kind of data
- the distinction between filtered and tainted data, so if there is assurance attack data after filtering allows us to use a more secure data
"Identification data" as a first step because you do not know " what the data is, where it comes from," the premise that you would be unable to properly filter it. The data here is provided internally all from non-code data. For example: all data from the client, but the client is not the only external data source, a database interface data provided by third parties, also be an external data source.
The data entered by the user is very easy to recognize we Go, Go through the r.ParseForm after the user POST and GET data all on the r.Form inside. Other input is much harder to identify, for example, r.Header Many of the elements are manipulated by the client. Often difficult to identify which of these elements of the input, so the best way is to put inside all the data as a user input. ( Ex r.Header.Get("Accept-Charset") This is also seen as user input, although these most browsers manipulation )
Data sources in the know, you can filter it. Filtering is a bit formal terms, it is expressed in peacetime there are many synonyms, such as validation, cleaning and decontamination. Despite the apparent meaning of these terms are different, but they all refer to the same treatment: to prevent illegal data into your application.
There are many ways to filter data, some of which are less secure. The best way is to check the filter as a process, you have to check before using the data to see whether they meet the legal requirements of the data. And do not try to correct the illegal data kindly, and let the user presses the rules to enter your data. History has proved that the attempt to correct invalid data often lead to security vulnerabilities. Here an example: "The recent construction of the banking system after the upgrade, if the password behind the two is 0, just enter the front four can log into the system," which is a very serious flaw.
Filtering data using the following several major libraries to operate :
- Strconv package the following string into the correlation function, because the
r.FormRequest returns a string, and sometimes we need to convert it to an integer/floating point,Atoi,ParseBool,ParseFloat,ParseIntother function can come in handy. - String pack Here are some filter function
Trim,ToLower,ToTitleother functions, can help us to obtain information in accordance with the format specified. - Regexp package to handle some of the complex needs, such as determining whether the input is Email, birthdays and the like.
Filtering Data In addition to checking authentication, in particular, you can also use the whitelist. Assuming that you are checking the data is illegal, unless it can prove that it is legitimate. Using this method, if an error occurs, it will only lead to the legitimate data as it is illegal, and not the opposite, although we do not want to make any mistakes, but it is better than the illegal data as legitimate data much more secure.
If you have completed the above steps, data filtering work is basically completed, but when writing Web applications, we also need to distinguish between filtered and tainted data, because it can guarantee the integrity of data filtering without affecting the input data. We agreed to put all filtered data into a variable called global Map (CleanMap). Then two important steps needed to prevent contamination of data injection:
- Each request must be initialized CleanMap an empty Map.
- Join inspection and prevent a variable from an external data source named CleanMap.
Next, let's use an example to reinforce these concepts, see the following form
<form action="/whoami" method="POST">
Who am I:
<select name="name">
<option value="astaxie">astaxie</option>
<option value="herry">herry</option>
<option value="marry">marry</option>
</select>
<input type="submit" />
</form>In dealing with this form of programming logic, very easy to make the mistake that can only be submitted in one of three choices. In fact, an attacker can simulate the POST operation, name = attack submission of such data, so at this point we need to do a similar deal with whitelist
r.ParseForm()
name := r.Form.Get("name")
CleanMap := make(map[string]interface{}, 0)
if name == "astaxie" || name == "herry" || name == "marry" {
CleanMap["name"] = name
}The above code we initialize a CleanMap variable name is obtained when the judge astaxie, herry, marry after one of the three
We store data in the CleanMap being, so you can make sure CleanMap["name"] data is legitimate, and thus the rest of the code to use it. Of course, we can also increase the else part of illegal data processing, possibility is that the form is displayed again with an error. But do not try to be friendly and output data to be contaminated.
The above method for filtering a set of known legitimate value data is very effective, but there is a group known for filtering data consisting of legal characters when it did not help. For example, you may need a user name can only consist of letters and numbers:
r.ParseForm()
username := r.Form.Get("username")
CleanMap := make(map[string]interface{}, 0)
if ok, _ := regexp.MatchString("^[a-zA-Z0-9].$", username); ok {
CleanMap["username"] = username
}Data filtering in the Web security play a cornerstone role in most of the security problems are the result of filtering the data and validation of data caused by, for example, the front section of CSRF attacks, and the next will be introduced XSS attacks, SQL injection and so there is no serious cause for filtering data, so we need special attention to this part of the content.
- [Directory] (preface.md)
- Previous section: [CSRF attacks] (09.1.md)
- Next section: [XSS attacks] (09.3.md)