Questions about security vulnerabilities in project programs scanned by security detection tools?

The client company used evaluation software to evaluate our project and found several security vulnerabilities, including sql injection and xssattacks. I looked at the server-side program code where the security vulnerabilities occurred, and found that they were basically page-oriented services. A vulnerability occurs where the end sends get or post data. The backend uses the input class that comes with the CI framework to receive data, which can filter the information entered by the user, and CI's csrf configuration item has also been turned on

Testing tools:

Vulnerability overview:

There are a few headaches:

1. The original code for receiving get and postdata was written like this $this->input->get('section_id). This is how other places in the project receive it. It stands to reason that it has already been done. With filtering and security precautions in place, why do such loopholes still appear?

2. If there is a problem with the server receiving get and postdata, then all places in the project that use this method should have loopholes. Why do such loopholes appear in only a few places?

3. Customers only see test data, how should I explain and communicate to them?

Please give me some advice~

Reply content:

The client company used evaluation software to evaluate our project and found several security vulnerabilities, including sql injection and xssattacks. I looked at the server-side program code where the security vulnerabilities occurred, and found that they were basically page-oriented services. A vulnerability occurs where the end sends get or post data. The backend receives data using the input class that comes with the CI framework, which can filter the information entered by the user, and CI's csrf configuration item has also been turned on

Testing tools:

Vulnerability overview:

There are a few headaches:

1. The original code for receiving get and postdata was written like this $this->input->get('section_id). This is how other places in the project receive it. It stands to reason that it has already been done. With filtering and security precautions in place, why do such loopholes still appear?

2. If there is a problem with the server receiving get and postdata, then all places in the project that use this method should have loopholes. Why do such loopholes appear in only a few places?

3. Customers only see test data, how should I explain and communicate to them?

Please give me some advice~

1 The judgment of this kind of test software is not necessarily accurate. Generally, it only judges whether the character lengths of the results returned by connecting different statements are the same to judge whether there is injection.
2 Don’t put too much faith in any framework or not. You have to do the security aspect yourself. Global filtering
3 The xss he detects here are not stored, and the risk is not that high. This kind of report is most often used as a springboard
4 What the client wants is the comfort that there are no loopholes in the report.
5 If you just want him to not be able to scan the vulnerability. Write a log file at the program entry and record all requests and parameters to analyze how the scanning software determines whether there is a vulnerability.
6 Modify the vulnerability in the report of the scanning software. From personal experience, this should be that the parameters you pass do not have intval
7 Turn off mysql error prompts to prevent error injection
Prevention
1 Add global sql keyword filtering to the program
2 Enable PHP single quotes Escape (modify php.ini magic_quotes_gpc).
3 Apache/nginx/iis enables service logs, mysql slow query logs, and program entry record request logs
4 The server installs web application security software such as SafeDog
5 Use UTF-8 for database links to prevent gbk double-byte injection
6 Enhancements The complexity of the mysql password, prohibiting mysql external links, and changing the default port number
7 Reduce the rights of the program mysql account and only give ordinary addition, deletion, checking, and modification permissions. It is forbidden to give file operation permission

XSS cross-site attack solution
1 Use htmlspecialchars to escape where text is written
2 Use SSL to prohibit loading and referencing external js
3 Set httponly to prohibit obtaining cookies
4 The above is to ensure that there is no injection (if there is injection , you can use hexadecimal to bypass htmlspecialchars to achieve the effect of xss attack)
5 It is best to use 2 sets of programs with different routing rules for the backend and the frontend. Key backend operations (backup database) should set a secondary password and add request parameters. complexity to prevent CSRF

PHP Security
1 Add suffix filtering where files are uploaded, and do not make "logical negation" judgments when filtering.
2 It is forbidden to upload files with the suffix php and htaccess. Do not use the data submitted by the client to obtain the file name suffix. You should use the program to add the suffix and random file name
3 Unified routing to limit unauthorized access. The webroot directory can only have one index.php (entry file) for external defense. All other directories are prohibited from external defense. All resource (uploaded) files are added with the anti-leeching function in nginx
4. PHP decentralization processing, web directory Restrict the creation of folders and text (except for folders required by the program, there is usually a cache directory that requires writable permissions)
5 Filter IIS/nginx file parsing vulnerability exploits
6 Use the mobile phone verification code to retrieve the password. Additional servers should be used for mailbox retrieval. (Prevent the real IP from being obtained through the password retrieval function). The last link to reset the password sent to the user's mailbox needs to have complex encryption parameters
7 The user login system should have a single login function. If the user has logged in, other people should be prompted to log in again.
8

1 Security knowledge
1 Web applications use site-library separation and change the default path of the environment web directory
2 When using an integrated environment, you should delete the php probe, phpmyadmin, and phpinfo after the installation is complete (the probe can view your web path, phpmyadmin can be violently cracked)
2 The user password is best to use the md5 value after password salting
3 Add a verification code where the user logs in, how to add a limit on the number of errors to prevent brute force cracking
4 Use CDN acceleration to hide the real IP
5 When the user logs in, do not pass the plaintext account and password to prevent C-side sniffing and obtain the user and administrator plaintext account and password through ARP spoofing
6 Disable the php system command line number exec, system, etc.
7 Install security software such as Security Dog on the server
8 The web directory is prohibited from storing .rar and zip files

My understanding of RSAS and BVS means that if you don’t fix this problem, it will always be scanned. The most fundamental way is to solve these problems and discover the vulnerabilities yourself. The customer is worried that it may not be someone else attacking him, but insiders taking advantage of the vulnerabilities. When creating backdoor programs, some customers leave very little room for explanation.