1. Explanation
You have to ask me what items I have audited and find any loopholes. I remember the boss of the first company asked me, “can you read the code?” I don’t know how to answer it. To understand that I’m not sure what the definition of code auditing is; to understand that I understand ECSHOP and the company’s code framework,I don’t think there is any difference between understanding code and source code auditing. Now, to tell you the difference, I think code auditing is a subset of “code understanding” just as penetration testing is a subset of testing.
Subset commutation means that basic abilities and basic ideas are universal, but because the points of attention are more concentrated, the general method can simplify and optimize the special method. Specifically to understand the code and code audit, understand the code pays attention to the overall flow of data and the function of each module, code audit can only beIf I look at char strdst [9]; strcpy (strdst,’0123456789′), for example, I don’t have to understand what the program’s functions are to determine that there must be an overflow.
Two, code audit ideas
2.1 Source of thought
As I said at the beginning, I didn’t understand the difference between “code auditing” and “understanding source code,” so I bought this book, Yin Yi’s “Code Auditing: Enterprise Web Code Security Architecture” (the name is awesome but thin, I often think less than 300 pages of books I do not want to read.) The details are largely forgotten.Just remember that there are probably two ways of thinking about code auditing: the first is forward tracing data streams, and the second is backward tracing data streams.
Recently, I read Wang Wei’s “Discovery of Home Router 0-day Vulnerability Mining Technology”, which also said that there are probably two ways of code audit: forward tracking and reverse tracing, in which fgets / read / recv and other input functions are suitable for forward tracking, strcpy / system and so on.Making functions is suitable for backward tracing.
Finally, look back at Marcus Pinto’s Hacker Attack and Defense Technology Book: The Web Actual Chapter, which says in Chapter 19, there are three steps to find the source hole in the source code: the first step is to determine the location of the user’s input, the second step is to find the vulnerability signature, and the third step is to analyze the vulnerability signature in detail.Let’s see if there are any loopholes. The so-called vulnerability signature is the feature code that vulnerabilities often appear, more simply, vulnerabilities often accompany the function, such as buffer overflow strcpy, such as command injection sehll_exec and so on.
2.2 Summary of ideas
I’ve looked at all the theories, and I feel they make sense, but I still don’t know how to do code auditing. The main problem is forward tracking. Where does it start? What position is it to end? Where does the reverse trace begin? Where does it end up?
It wasn’t until I pondered over the three books that he got the user’s input function and the vulnerability signature function as a starting point for each other. Code audit thinking is summarized in the following four steps:
1. Determine what language (such as Java or. net) the code to audit, and what framework (such as SSH or other).
2. Determine the language and framework, get user input functions or forms from get / post (such as Java getParameter, PHP $_GET, and $_POST); and identify signature functions for various vulnerabilities in the language (such as JAVA and SQL vulnerabilities related)Excute, executeQuery, createStatement, and command execution vulnerabilities related to getRuntime and exec, and so on.
3. Use Source Insight to open the items to be audited.
4. Search project is used to find the user input function and vulnerability signature function in the whole project. The forward tracing data stream is used to obtain the user input function to see if the data controlled by the user has entered the vulnerability signature function. The reverse tracing data stream is used to see the data for the vulnerability signature function.Does the source come from the function that gets user input?
In fact, when we look at the code audit tool, the first step is to find the user input function and the vulnerability signature function, and the second step is to track the variables of the function either forward or backward (the difference in tracing ability is the difference in the ability of the audit tool). For example, the two graph below is VCG (VisualCo).DeGrepper and Seay’s audit results for DVWA:
Generally speaking, forward tracing can cover more data stream branches, but most data may not get into the vulnerable signature function so it may be less efficient; backward tracing is much more likely to find vulnerabilities from the vulnerable signature function, but it is easy to miss some functions that do not have a vulnerable signature (such as backdoor secrecy).Code and so on).
Three, specific operation demonstration
Now let’s take a look at a graduation project written for my sister by retrospectively looking for SQL injections to illustrate what the idea of having a break is like (it’s a tragedy that my sister didn’t end up being her sister).
The first step is to use the language and framework —-java and Struts2.
The second step – – – getting the user input function and the vulnerability signature function – – – Struts2 getting the user input is achieved by inheriting the ActionSupport implementation getter / setter method, and the vulnerability signature function injected by SQL in Java is exEcuteQuery, executeUpdate.
The third step — use Source Insight to open the project to be audited — the result is shown in the following figure.
The fourth step — using search project to find executeUpdate and trace whether its variables originated from user input — is as follows
These are the locations listed using the executeUpdate function, which you can skip by clicking the red link button, and which we will audit one by one during the audit.
Let’s click the link button to go to the first place and look ahead at the SQL statement executeUpdate executes. You can see that most variables in the statement are precompiled (ps. setString) but the spliced side is used for user. getLoginPwd ().type
We want to track the source of user.getLoginPwd () to see if it comes from the function that gets user input. User is the parameter of the register function. Where do we go back to call register? Right click on register and click “Ju”.MP To Caller “
Enter the invocation position as shown in the following figure. We look ahead to user. setLoginPwd (), place the cursor on its loginPwd parameter, and see that loginPwd is a variable defined by this class in the definition window below
Double-click the “loginPwd” main window in the definition window below to jump to that location, and observe that the context loginPwd is exactly what the getter method (getLoginPwd) implemented after inheriting the ActionSupport class gets from the front-end form
So, in the SQL vulnerability signature function, the spliced loginPwd variable comes from user input; so there is SQL injection.