SQL injection
SQL injection can generally be scanned by fortify. Manual auditing usually directly search for select, update, delete, and insert keywords. If there are words like + append, $() # in the sql statement, if the SQL filter file is not configured, It is judged that there is a SQL injection vulnerability.
When finding a SQL injection vulnerability in a variable keyword, you can also directly search that keyword globally to find files with similar vulnerabilities, such as parameters involving SQL injection vulnerabilities, etc.
! ! Pay attention to the introduction of global filter variables
Frame injection vulnerability
Vulnerabilities like Struts2 remote code execution vulnerability
Check whether the version information of the struts plugin is a vulnerable version
Code execution
Code execution refers to executable script code. Command execution means that you can execute system commands (cmd) or application commands (bash). This vulnerability is also caused by the lack of strict filtering of parameters. Generally, we call PHP executable commands. The functions have these: system();exec();shell_exec();passthru();pcntl_exec();popen();proc_open();
The backtick is also executable, because it calls the shell_exec function. The shell_exec() function is actually just a variant of the backtick (`) operator
https://blog.csdn.net/whatday/article/details/54880851 How PHP calls external programs
File Upload
File upload can search for the following keywords: (note whether there is a whitelist for configuration file upload) upload, write, fileName, filePath
When checking, mainly judge whether there is a check suffix name, and check whether the configuration file has a whitelist or blacklist.
SSRF
SSRF vulnerabilities are generally located at functional points such as remote image loading and downloading, image or article collection functions, URL sharing, online translation via URL, and transcoding. When performing code audits, you need to pay attention to the classes and functions that initiate HTTP requests.
SSRF (Server-Side Request Forge, server-side request forgery)
The attacker makes the server initiate a specified request. The target of an SSRF attack is generally an internal network system that cannot be accessed from the external network. SSRF in Java supports all protocols in sun.net.www.protocol: http, https, file, ftp, mailto, jar, netdoc. Compared with php, the use of SSRF in java is more limited. Generally, the http protocol is used to detect the port and the file protocol is used to read any file.
SSRF vulnerability defense
Restricted protocol is HTTP, HTTPS protocol
Prohibit 30x jump
Set URL whitelist or restrict intranet IP
Limit the requested port to http commonly used port
Access control
When focusing on user operation requests, check whether there is a verification of the permissions of the currently logged-in user to determine whether there are vulnerabilities. Some manufacturers will use some mainstream permission frameworks, such as shiro, spring security and other frameworks, so you need to focus on the configuration of the framework Documents and implementation methods.
Deserialization
The Java program uses the readObject method of the ObjectInputStream object to convert the deserialized data into a java object. But when the input deserialized data can be controlled by the user, the attacker can construct malicious input to make the deserialization produce unexpected objects, and execute the constructed arbitrary code in the process.
Deserialization operations are generally in business scenarios such as importing template files, network communication, data transmission, log formatting storage, object data storage to disk or DB storage, etc. During code auditing, you can focus on some deserialization operation functions and determine whether the input is Controllable.
E.g:
ObjectInputStream.readObject
ObjectInputStream.readUnshared
XMLDecoder.readObject
Yaml.load
XStream.fromXML
ObjectMapper.readValue
JSON.parseObject
Audit auxiliary tools
Code auditing is to get the source code of a certain website and then conduct an audit to discover vulnerabilities. However, we do not necessarily have to look at it line by line when we audit, which would be a waste of time, so we need tools to help us.
When we are doing code audits, it is recommended that you first casually review the audited CMS and familiarize yourself with the functions. It is a good choice to conduct black box testing before code audit. Know where there is a problem, and then find out the problem code.
Pay attention to variables and functions:
Variables that can be controlled [All inputs are harmful]
Variables reach useful functions [All variables entering the function are harmful]
Automatic audit tools are getting less and less able to support various frameworks, not as good as the editor's search function
https://cloud.tencent.com/developer/article/1039610 Comparison of three tools
Code audit summary
Combining the three orientations, we can only deepen through continuous learning and understanding