Java code audit series

Preface

This article was originally a PPT, but it has been put without sharing, thinking that it is also idle, so it should be published instead. In fact, this article focuses on two knowledge points, one is the reverse thinking of code audit, the other is the second attack loopholes. I have omitted all the others, so let's write some important ones. As for the second attack, I have just studied it recently. I have studied some mistakes. Please correct the mistakes. Thank you.

Code audit learning journey

Some people always ask me how to learn code auditing and where to learn from. Now I reply uniformly, saying that I don't know...

But for the personal learning route, the journey is long and arduous. It is suggested to learn as follows (screenshot directly):

What I wrote above is "familiarity", which is just for the new students. As a code audit, it is necessary to be proficient in code programming. To develop in depth, it is necessary to be proficient in a language.

Knowledge one variable reverse tracking

In code audit, it is necessary to audit according to business process. The advantage of manual process audit is that it can find vulnerabilities more comprehensively, but the disadvantage is that it is inefficient to find vulnerabilities. If you want to find the targeted vulnerability, the reverse tracking variable technology becomes more prominent, such as finding XSS, SQL injection, command execution And so on. Reverse lookup variables can quickly locate whether the vulnerability exists. This time, SQL injection has been taken as an example.

What is reverse tracking

As the name implies, reverse tracking is the reverse search of variables. It starts to find out the trigger points that may have vulnerabilities globally, and then backtracks the parameters to the front end to see the processing process in the process of parameter source passing.

Reverse tracking process

How to locate quickly? Let's take a look at the process.

1. View global file web.xml

Web.xml is mainly used to configure the information loaded when the web project starts, such as < listener / > configure your listener, < filter / > configure filter, < servlet / > configure your servlet implementation. We mainly check whether the global filter filters the special characters. Obviously, it does not.

2. Find the vulnerability trigger point

This time, take SQL injection as an example. I won't talk about SQL injection. There are a lot of related documents. When we see the following SQL statements, there may be SQL injection:

Because security is written like this:

Then, there may be SQL injection vulnerability in the parameter "word". We can trace back the "word" parameter, see how the "word" value is passed in, trace back to the control layer, and find the "word" parameter:

Tracking to the control layer can basically determine the existence of the vulnerability, and no corresponding filtering has been done. However, to prevent the "search" method from being only called internally, continue to backtrack the "searchword" value to see whether it is passed in from the front-end page:

It is found that the "search word" is passed in from the front-end page, so it can be determined that the vulnerability exists. The sqlmap screenshot is as follows:

That's a simple back tracking variable tip. What? Too low? No way, that's the level.

Audit of knowledge secondary loopholes

Secondary vulnerability is also called secondary attack. There are few information on the Internet. I have studied it for a while and found that there are many situations of secondary attack, and I don't understand how much. This time, I will talk about the easy to understand vulnerability of secondary command attack. Don't like to spray it.

Definition of secondary vulnerability:

The malicious code submitted by the attacker is not directly submitted to the vulnerability function through a variable, but through variable conversion or transit, and finally submitted to the vulnerability function.

Characteristics of secondary vulnerability:

1. There is often a conversion of vulnerability types.

2. There are often variable transitions.

Type of secondary vulnerability:

1. Through SQL injection vulnerability conversion.

2. Transfer variables by encoding / decoding.

3. Other methods.

Secondary command attack

Secondary injection vulnerability is a form of security vulnerability widely existing in web applications. Compared with the primary injection vulnerability, the secondary injection vulnerability is more difficult to be found, but it has the same attack power as the primary injection vulnerability.

The basic process is as follows:

1. Construction parameters

In normal database insertion, update and other operations, special commands are constructed and stored in the database:

It's just convenient to show the principle of vulnerability here. The situation in the real code may be more complex. Here, "CMD" parameter is constructed as "ipconfig" and stored in the database.

2. Extract variables

When this parameter is called actively somewhere in the system, the command attack will occur after the corresponding command execution parameter.

After the runtime function, execute the command:

Seeing that there must be some people here, smart little friends can see the problem. Isn't this second attack the same as storage cross station, no difference?

However, strictly speaking, the storage type cross station is not a secondary attack vulnerability. Although the storage type cross station also uses the database as a transit, its execution mode can only take effect by human clicking, but the secondary attack is an active attack after storage, which is the fundamental difference.

conclusion

The above two points are purely personal understanding. If you have any mistakes, please give me more advice. I will not change them anyway.