Shulou(Shulou.com)06/01 Report--

This article introduces how to use PHP open source white box audit tool, the content is very detailed, interested friends can use for reference, I hope it can be helpful to you.

Preface

After some research, this paper selects 13 white-box audit tools for PHP which have been updated continuously in the past three years for analysis. This paper mainly introduces the principle of these white-box audit frameworks and briefly analyzes the list of their rules, without evaluating the specific effect of digging holes. This mainly considers the following two reasons: on the one hand, the focus of different white-box audit frameworks is different, some are designed for digging holes, and some of the actual output must be manually reviewed; moreover, even if they are all designed to dig holes as the goal, some are specific to the framework, and some can be universal. Therefore, if you are interested, you can choose the corresponding framework for testing.

At present, the design ideas of the mainstream PHP open source white box audit tools are mostly based on the experience that some / all of the parameters of sensitive functions come from external inputs that are not handled by security functions. Finally, the specific implementation can be divided into the following two categories:

Based on the text features: that is, we often say the regular way, based on the manual code audit to find the source code rules of loopholes, thus summing up the corresponding regular expression, and then based on this regular expression to find such loopholes. The advantage of white-box audit tool based on text feature is that the audit speed is relatively fast and the cost of maintaining rules is low, but the disadvantage is that the accuracy is relatively low and the false alarm rate is relatively high.

Based on static analysis: that is, white-box audit is carried out with the help of traditional static analysis technology. The common technologies include data flow analysis, stain propagation and control flow analysis. Static analysis can more accurately judge whether the external input has been processed by the security function, which is difficult to achieve based on text features. In addition, the static analysis-based approach is also more advantageous in determining whether a variable comes partly / entirely from external input, especially when auditing against the framework.

However, there is a good side and a bad side, and the problem based on static analysis is:

1) it takes a lot of time to do a complete analysis, which is much longer than that based on text features.

2) the adaptation cost is high, so it is necessary to adapt the corresponding parser to generate the required AST tree and CFG information for different objectives. in addition, the adaptation of detection rules is also a relatively heavy cost.

As shown in the following figure, among the 13 white-box audit tools introduced in this article, there are 7 text-based audit tools and 6 static analysis-based audit tools.

Based on text feature grauditGithub: https://github.com/wireghoul/grauditLanguage: ShellLast commit on 2019.11.12

Graudit has been open source in Github for about 10 years since 2009, and it is still being updated constantly. The full name of graudit is grep rough audit, as its name implies, it mainly uses the built-in grep command of Linux to achieve white-box audit, and its core code is only a bash script with less than 200 lines. The languages supported by graudit are ASP, C, .NET, Java, JavaScript, Perl, PHP, Python, Ruby, etc.

Graudit selects the corresponding rule base according to the development language of the vulnerability mining object, and then uses grep to quickly locate in the source code to meet the suspicious locations of the specified rules, and then the security personnel check these suspicious locations manually to see if there are real vulnerabilities.

At the same time, graudit has been constantly updated after years of use, and has provided a very comprehensive vulnerability rule base (https://github.com/wireghoul/graudit/tree/master/signatures), which provides 24 databases covering different languages / vulnerability types, with a total of 1256 rules. The rules are mainly for the inspection of hazard functions and their parameters. It is worth mentioning that graudit provides a lot of useful little scripts in the misc directory.

$ls signatures/*.db | xargs-I {} sh-c 'echo "{} `cat {} | grep-vE\" ^ $| ^ #\ "| wc-l`"' signatures/actionscript.db 10signatures/android.db 49signatures/asp.db 53signatures/c.db 280signatures/cobol.db 8signatures/default.db 12signatures/dotnet.db 134signatures/exec.db 17signatures/ios.db 39signatures/java.db 102signatures/js.db 8signatures/perl.db 33signatures/php.db 160signatures/python.db 67signatures/rough.db 43signatures/ruby.db 16signatures/seafruit.db 11signatures/secrets-b64.db 1signatures/secrets.db 8signatures/spsqli.db 4signatures/sql.db 74signatures/strings.db 64signatures/xss.db 13VisualCodeGrepperGithub: https://github.com/nccgroup/VCGLanguage: Visual Basic .NETLast commit on 2019.11.06

VisualCodeGrepper, referred to as VCG, is a white-box audit tool under window developed based on VB. Compared to other white-box audit tools, VCG also checks code comments for statements such as "ToDo", "FixMe" and "Kludge" to remind security personnel that there is unfinished code here and that there may be security problems. The languages supported by VCG are CCompact, Java, Java, VB, PL/SQL, COBOL.

VCG uses regular expressions to check whether each line of code meets predetermined vulnerability rules and alerts the auditor if so. The difference is that the rules are generated dynamically, that is, VCG extracts information such as variable names in the code to dynamically generate vulnerability rules for this piece of code.

VCG's vulnerability rules are located in the VisualCodeGrepper/modCheck.vb file, each language has a separate file, and there are some common detection functions between different languages. In the case of PHP, VCG detects 10 different types of vulnerabilities.

CheckSQLInjection: detecting SQL injection vulnerabilities

CheckXSS: detecting XSS vulnerabilities

CheckLogDisplay: detects whether the log contents are escaped before being written to the log

CheckRandomisation: check whether the generation of random numbers is safe enough

CheckFileValidation: detects whether the value of the $_ FILE array is directly used to determine the condition

CheckFileInclusion: detects whether there are user-controllable parameters in the path contained in the file

CheckExecutable: detects whether the parameters of the command execution function have been escaped

CheckBackTick: detects whether there is a user-controllable part of the parameter of the backquote

CheckRegisterGlobals: detects whether the modification of global variables is controllable by the user

CheckParseStr: check whether the parameters of parse_str are controllable by the user.

KiwiGithub: https://github.com/alpha1e0/kiwiLanguage: Python2Last commit on 2019.08.12

Kiwi is a white-box audit framework based on Python. At the beginning of the design, the author defines it more as a code search tool than a code audit tool. Its main purpose is to help security personnel locate possible loopholes more quickly, so as to carry out the next manual audit. The framework of Kiwi is completely separated from the detection rules, and security personnel can write specific detection rules according to their own needs. Kiwi can theoretically support most languages, and officials have provided detection rules for PHP and Python.

Kiwi traverses all the files of the source code, selects the appropriate detection rules according to the suffix of the file, and then locates the possible loopholes by regular matching. After finding the loophole, kiwi will not return directly, but will call the preset evaluate function for further detection, and then report it to the security personnel after the test has passed.

Kiwi officially provides detection rules for PHP and Python, which are located in the kiwi_data/features directory. Python covers 5 different types of vulnerabilities and PHP covers 10 different types of vulnerabilities.

WpBulletGithub: https://github.com/webarx-security/wpbulletLanguage: Python3Last commit on 2019.06.04

WpBullet is a white-box audit tool designed for WordPress plug-ins / themes. In addition to supporting local source code auditing, wpBullet also supports automatic download of source code for auditing based on the incoming plug-in / theme URL.

WpBullet traverses all the files of the entire source code and analyzes the files with the .php suffix. For each PHP file, wpBullet does two main analyses:

1) wpBullet regularly extracts the information about admin_action (admin_action_xxx), ajax hooks (wp_ajax_xxx) and admin initialization (admin_init) registered through the add_action function in the PHP file, and stores the corresponding global variables for subsequent display to the security personnel.

2) wpBullet analyzes whether there are vulnerabilities in the PHP file according to the predetermined detection rules. WpBullet first extracts all the user-controllable variables in the file by regular extraction, then dynamically generates regular expressions based on these variables, and then detects whether these variables are directly passed into the dangerous functions in the detection rules without being processed by the security functions in the detection rules. If so, a vulnerability report is generated.

The detection rules for wpBullet are located in the Modules directory. For each type of vulnerability, the detection rules contain dangerous functions that cause such vulnerabilities and a list of security functions for such vulnerabilities. WpBullet provides a general dynamic generation function of vulnerability detection regular rules by default, but security personnel can modify this function according to their actual needs. WpBullet officially provides detection rules for 10 different types of vulnerabilities in the WordPress framework.

SourceCodeSnifferGithub: https://github.com/frizb/SourceCodeSnifferLanguage: Python2Last commit on 2018.06.14

As the author said, SourceCodeSniffer is a beggar version of the white-box audit tool, the overall implementation is relatively simple, and has not been updated for almost 2 years.

SourceCodeSniffer detects the existence of dangerous functions in the source code in a regular way to determine whether there are vulnerabilities. It does not consider whether the parameters of the hazard function are user-controllable input.

SourceCodeSniffer has relatively few detection rules, but it provides a brief introduction and corresponding CWE information for each type of security vulnerability. It supports 7 different languages, with a total of 52 rules.

$ls * .ini | xargs-I {} sh-c'echo "{} `cat {} | grep-E\" ^ Regex\ "| wc-l`" ASP.ini 6C.ini 13CSharp.ini 17Custom.ini 1Default.ini 1Java.ini 6NodeJs.ini 3PHP.ini 5VBScript.ini 1drekGithub: https://github.com/chrisallenlane/drekLanguage: JavaScriptLast commit on June 29, 2017.026

Drek is a white-box audit tool based on JavaScript. Its goal is to achieve functions similar to grep, but its output format is HTML.

Drek traverses all the files of the source code, and then regularly detects whether there are dangerous functions in them to determine whether there are vulnerabilities in the file, without considering such problems as whether the specific parameters are controllable.

Unlike other tools, drek's detection rules are additionally stored in another drek-signaturs repository, https://github.com/chrisallenlane/drek-signatures. In addition to the detection rules for mainstream languages (PHP, C, JAVA, JavaScript, .NET), drek-signatures also provides detection rules for different frameworks (WordPress, Eloquent ORM). However, the detection rules basically provide only the name of the hazard function, without more qualification, and the most recent update was 3 years ago.

GrepBugsGithub: https://github.com/foospidy/GrepBugsLanguage: Python2Last commit on 2017.04.08

GrepBugs is also an older white-box audit framework based on Python. Similar to graudit,GrepBugs is the Python version of grep encapsulation. GrepBugs not only supports security scanning of local source code, but also supports scanning warehouse source code on Github through Github API.

GrepBugs traverses the source code, determines the file development language with the help of the cloc command, then selects the corresponding regular expression to detect vulnerabilities according to the language, and finally calls the grep command to detect whether there is a regular language in the file to determine whether there is a vulnerability in the file.

The inspection rules (https://grepbugs.com/rules) provided by GrepBugs cover 16 different languages, with a total of 179 different rules.

{'ASP': 6,' ASP.Net': 10, 'PHP': 37,' Python': 7, 'Ruby': 10,' Visual Basic': 7, 'Ruby': 10,' Visual Basic': 2}

Due to the length of space

Today, I only introduce the code audit tool based on text feature.

On how to use PHP open source white box audit tools to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.