Hacking Book | Free Online Hacking Learning

 Home

web vulnerability detection and repair

Posted by verstraete at 2020-02-27
all

Web vulnerability refers to the security vulnerability in CGI / Web services developed in various languages (PHP, JSP, C + +). The following is the definition of vulnerability, detection method and repair scheme.

Catalog

1. injection vulnerability

1.1 SQL injection vulnerability

Name: SQL injection vulnerability

Description: in the web program code, the parameters submitted by the user are put into the SQL statement without filtering, which causes the special characters in the parameters to break the original logic of the SQL statement. The hacker can use this vulnerability to execute any SQL statement.

Detection method: judge whether there is a vulnerability by modifying parameters.

Repair scheme: 1. Microsoft has a unified method for anti XSS Library of asp.net. For details, please refer to the following link: http://www.cnblogs.com/hcmfys/archive/2008/07/11/1240809.html 2 For other languages, it can be subdivided as follows: Escape or filter the external parameters brought into SQL statement at code level: (1) for integer, judge whether the variable conforms to the value of [0-9]; for other limited values, you can also check the validity; (2) for string, escape the special characters of SQL statement (single quotation mark into two single quotation marks, double quotation marks into two double quotation marks). In this regard, PHP has similar escape functions MySQL escape string and MySQL real escape string. Suggestions: (1) use Tencent CMEM storage scheme; (2) filter the user request data interacting with database to prevent SQL injection.

1.2 XSS vulnerability

Name: XSS injection vulnerability (cross site scripting)

Description: in the web program code, the parameters submitted by users are directly output to the page without filtering. The special characters in the parameters break the original logic of the HTML page. Hackers can use this vulnerability to execute malicious HTML / JS code, construct worm propagation, tamper with the page to implement phishing attacks, etc.

Detection method: judge whether there is a vulnerability by modifying parameters. For example, when users input content: '< U > a < / u >', the legal display is: '< U > a < / u >', and the legal display source code is:

The vulnerable page shows: 'a'

The source code is:

Repair scheme: 1. Developers should strictly follow the verification rules of openid and openkey to determine whether openid and openkey are legal, and judge the validity of other parameters. If they are illegal, no content will be returned.

2. Strictly restrict the format of the URL parameter input value, which cannot contain unnecessary special characters (% 0d,% 0A,% 0d,% 0A, etc.).

3. For the anti XSS Library of asp.net, Microsoft has a unified library. For details, please refer to the following link: http://msdn.microsoft.com/en-us/library/aa973813.aspx

4. The specific JS methods are as follows: (1) when the parameter value entered by the user is displayed in the HTML body or attribute value, for example: displayed in the HTML body: < a href ='http: / / www.contoso. Com '>

UN trusted input < / a > is displayed in the attribute value: < input name = "searchword" value = "UN trusted input" > at this time, the following transcoding should be done in the red untrusted content (that is to say, convert "'"' to HTML entity):

(2) When user input falls into the content of < script >, for example:

<script type="text/javascript">… var mymsg="Un-trusted input";var uin=Un-trusted input;… </script>

1.3 command injection vulnerability

Name: command injection vulnerability

Description: in the web program code, the parameters submitted by the user are directly executed by the shell without filtering, and the attacker can execute arbitrary system commands.

Detection method: judge whether there is a vulnerability by modifying parameters.

Fix: when calling the shell at the code level, escape the special characters (|, &,; etc.) in the command line to prevent other illegal commands from executing. In PHP, escapeshellarg and escapeshellcmd can be used to escape.

1.4 HTTP response header injection vulnerability

Name: HTTP response splitting (HTTP header injection)

Description: in the web program code, the parameters submitted by the user are output directly to the HTTP response header without filtering. The attacker can use this vulnerability to inject the HTTP response header, which can cause XSS attack, cheat the user to download malicious executable files and other attacks. In addition, according to the statistics of Acunetix of the Department of international security organizations, the following Apache has a header injection vulnerability: 1.3.34/2.0.57/2.2.1.

Detection method: judge whether there is a vulnerability by modifying parameters. For example, a famous website in China once had a header injection vulnerability, as follows:

http://www.YYYYYYYYY.com/YYYYWeb/jsp/website/agentInvoke.jsp?agentid=%0D%0AX-foo:%20bar

It was found that:

Repair scheme: 1. In the code for setting HTTP response header, filter carriage return line feed (% 0d% 0A,% 0d% 0A) characters. 2. Do not use the vulnerable version of Apache server, and check the validity and length of parameters. Carefully set the header of HTTP return package according to the parameters passed in by users.

1.5 jump vulnerability

Name: jump vulnerability

Description: the web program directly jumps to the URL in the parameter, or the page introduces any developer URL.

Detection method: modify the legal URL in the parameter to illegal URL. For example, test the following URL: http: / / * * *. QQ. COM / CGI bin / demo_es. CGI? Backurl = http://www. * * *. Com, to see if it will jump to the injected http://www. * * *. Com site.

Fix: verify that the incoming URL is a trusted domain name at the place where the control page turns. For example, the following is a JS function to verify whether it is Tencent domain name:

function VaildURL(sUrl){return (/^(https?:\/\/)?[\w\-.]+\.(qq|paipai|soso|taotao)\.com($|\/|\\)/i).test(sUrl)||(/^[\w][\w\/\.\-_%]+$/i).test(sUrl)||(/^[\/\\][^\/\\]/i).test(sUrl) ? true : false;}

1.6 XML injection vulnerability

Name: XML injection vulnerability

Description: in the web program code, the parameters submitted by users are directly output to XML without filtering.

Detection method: judge whether there is a vulnerability by modifying parameters.

Fix: Escape XML special characters ("<", ">", ">]]") at code level output.

2. Information leakage

2.1 information disclosure vulnerability of phpinfo()

Name: phpinfo() information disclosure vulnerability

Description: some test pages of the web site may use PHP's phpinfo() function, which will output key information about the server. As shown in the figure below:

Detection method: visit http: / / [IP] / test.php and http: / / [IP] / phpinfo.php to see if it is successful.

Fix: delete the PHP file.

2.2 leak of test page on the Internet

Name: test page leak in the Internet vulnerability

Description: some test pages leaked to the Internet, which led to the company being hacked. As shown in the following figure: 1. Http://parts.baby.qzoneapp.com/

2. http://parts.baby.qzoneapp.com/test.php

3. http://other.baby.qzoneapp.com

Test method: check the content of the page to see if it is a test page.

Fix: delete the test page, such as test.cgi, PHP info.php, info.pho,. SVN / entries, etc.

2.3 the backup file leaks in the Internet

Name: backup file disclosure in the Internet vulnerability

Description: when an editor or a person edits a file, temporary files generated, such as VIM automatically saved as. SWP suffix, ultrliditor automatically saved as. Bak suffix, etc., will leak source code or sensitive information. As shown in the figure below:

Leaking the source code can let hackers fully understand the background development language, architecture, configuration information, etc. The following figure shows the source code leaks of a famous website in China:

Detection method: add suffix probes such as. Bak,. SWP,. Old, ~ after CGI file.

Fix: delete the backup file.

2.4 version management tool file information disclosure vulnerability

Name: version management tool file information disclosure vulnerability

Description: version management tools SVN and CVs will add special files to all directories. If these files are synchronized to the web directory, information such as path will be disclosed. As shown in the figure below:

Detection method: visit http: / / [IP] / CVs / entriesp and http: / / [IP] /. SVN / entriesp to see if they are successful.

Fix: delete the. SVN directory under each SVN directory; delete the CVS directory of CVS.

2.5 HTTP authentication disclosure vulnerability

Name: http authentication disclosure vulnerability

Description: the HTTP basic authentication is enabled in the web directory, but there is no IP restriction. As a result, the attacker can brutally crack the account password. As shown in the figure below:

Fix: restrict IP access to the directory.

2.6 management background leakage vulnerability

Name: management background leak vulnerability

Description: the account and password design of the management background is too simple and easy to be guessed, which leads to the attacker can brutally crack the account password. As shown in the figure below:

Repair scheme: 1. Bind the management background services to the intranet IP, and prohibit opening to the Internet. 2. If the management background must be provided for Internet access, do not display too much content on the page without login to prevent the leakage of sensitive information. The login account shall be authenticated, and the password setting rules shall be as complex as possible, and the verification code shall be added to prevent violent cracking.

2.7 leakage of e-mail vulnerability and extension number of employees

Name: leakage of employee email vulnerability and extension number

Description: leaking the internal e-mail address and extension number of employees is equivalent to leaking the internal ID of employees, which can provide valuable materials for hackers to carry out social engineering attacks, and also provide important account information for hackers to brutally crack backstage services.

Fix scheme: delete the place where Tencent employee email and extension number appear in page annotation and other places.

2.8 error details leak vulnerability

Name: error details disclosure vulnerability

Description: the page contains code level details of CGI handling errors, such as the reason for SQL statement execution errors, the number of error lines in PHP, etc.

Detection method: change the parameter to illegal parameter to see whether the error information returned by the page leaks the information of too detailed code level.

Fix scheme: make the error information transparent to the user. After CGI processes the error, it can return friendly prompt and return code. However, the user cannot be prompted for detailed reasons at the code level of the error.

3. Request Forgery vulnerability

3.1 CSRF vulnerability

Name: CSRF vulnerability (Cross Site Request Forgery)

Description: when a user browses to flash or developer's website as the current identity, JS / flash can force the user's browser to send a request to any CGI, which contains the user's identity. If there is no limit, CGI will operate as a user.

Test method: 1. In the actual test process, the tester needs to determine whether the operation is a save class operation, and whether it is forced to transfer parameters in post mode. The judgment method is to change all post parameters to get mode through the packet grabbing tool. It should be noted that this method can only prevent the picture jump type CSRF vulnerability. If there is XSS vulnerability on the page, the CSRF cannot be defended. 2. The simplest way is to check whether the CGI has unpredictable parameters, such as random strings.

Fix: you can use any of the following methods to defend against CSRF attacks: 1. Add form token (random string in hidden field); 2. Request referrer verification; 3. Use verification code for key requests.

3.2 JSON hijackin vulnerability

Name: JSON hijackin vulnerability

Description: CGI outputs data in the form of JSON. Hacker controlled developer sites force users' browsers to request CGI to obtain JSON data by CSRF means. Hackers can obtain sensitive information.

Detection methods: 1. Check whether the returned JSON data contains sensitive information, such as user ID, session key, email address, mobile number, friend relationship chain, etc. 2. Confirm whether the submission has unpredictable parameters, such as random string, etc. Fix: you can use any of the following methods to defend against JSON hijacking attack: 1. Add form token (random string in hidden domain) to the request; 2. Request the referrer verification.

4. Privilege control vulnerability

4.1 file upload vulnerability

Name: file upload vulnerability

Description: the web program that accepts the file upload does not verify the validity of the file type and format, which may cause an attacker to upload a file of webshell (. PHP,. JSP, etc.) or an unexpected format (. HTML file with JPG suffix)

Repair scheme: CGI of file upload shall be: 1. Verification of upload file type and format; 2. Download the uploaded file in binary form without direct access.

4.2 improper configuration vulnerability of crossdomain.xml

Name: crossdomain.xml misconfigured vulnerability

Description: the file crossdomain.xml in the root directory of the website indicates whether the remote flash can load the resources of the current website (picture, webpage content, flash, etc.). If not configured properly, it may cause CSRF attack. As shown in the figure below:

Detection method: visit http: / / [domain] / crossdomain.xml repair scheme: for websites that do not need external loading resources, change the domain attribute of allow access from to domain name white list in crossdomain.xml. Refer to the following for the general sample of repair (Note: in the example, please modify app10000.qzoneapp.com and app10000.imgcache.qzoneapp.com to the site you specify):

<?xml version="1.0"?><cross-domain-policy><allow-access-from secure="false" domain="*.qq.com"/><allow-access-from secure="false" domain="*.soso.com"/><allow-access-from secure="false" domain="*.paipai.com"/><allow-access-from secure="false" domain="*.gtimg.cn"/><allow-access-from secure="false" domain="*.pengyou.com"/><allow-access-from secure="false" domain="app10000.qzoneapp.com"/><allow-access-from secure="false" domain="app10000.imgcache.qzoneapp.com"/></cross-domain-policy>

4.3 improper flash label configuration vulnerability

Name: improper flash label configuration vulnerability

Description: when flash is introduced into a web page, it will pass the object / embed tag. When setting, if some properties are not configured properly, it will bring security problems: 1. Allowscriptaccess: whether flash is allowed to access browser scripts. If the untrusted flash is not restricted, the browser script will be allowed to be called by default, resulting in XSS vulnerability. Always (default), always allow; samedomain, same domain allow; never, not allowed 2. Allownetworking: whether to allow flash to access the network API in ActionScript. If we don't restrict the untrusted flash, it will bring problems such as flash pop-up window and CSRF. All, all functions are allowed, which will cause flash pop-up hazard; internal, which can send out requests / load web pages; none, which can not perform any network related actions (normal business functions may not be available)

Fix: for the untrusted flash source, allowscriptaccess is set to never, and allownetworking is set to none (the business needs can be relaxed to internal).

4.4 improper configuration vulnerability of embedded tag

Name: embedded tag misconfiguration vulnerability

Description: Web pages will introduce media files (such as RM, AVI and other video and audio) through the embed tag. If there are script instructions (pop-up / jump) in these media files, if there is no limit, there will be security problems.

Detection method: check whether there is an invokes tag in the embedded tag.

Fix: add property invokes with a value of - 1.

4.5 concurrent vulnerabilities

Name: concurrent vulnerability

Description: through concurrent http / TCP requests, attackers can achieve the effect that abnormal logic can trigger, such as sub award, multi harvest, and multi reward. The following is a simplified example to illustrate the potential parallelism in a transactional Web application, and involves two users (threads) in a federated savings account logging into the same account to attempt to transfer money: account a has 100 deposits, account B has 100 deposits. Both user 1 and user 2 want to transfer 10 points from account a to account B. if the transaction is correct, the result should be: account a 80 points, account B 120 points. However, due to the problem of concurrency, we can get the following results: user 1 checks account a (= 100 points) user 2 checks account a (= 100 points) user 2 needs to take 10 points (= 90 points) from account a, and put it in account B (= 110 points) user 1 needs to take 10 points (still think it contains 100 points) (= 90 points) from account a, and put it in B (= 120 points) Results: 90 points for account a and 120 points for account B.

Detection method: send concurrent http / TCP request to check whether CGI function is normal before and after concurrency. For example: before concurrency, the data should be counted first, and then the data should be counted after concurrency to check whether the data twice is reasonable.

Fix: lock the database operation.

4.6 cookie security vulnerability

Name: Cookie security vulnerability

Description: improper setting of cookie properties may cause security risks such as running errors of other SNS games.

Detection method: grab the packet to check whether the Cookie's domain attribute setting is reasonable.

Fix: set the domain attribute of cookie field strictly. The domain of openkey and openid can only be set to the child domain, and it is forbidden to set to the parent domain qzoneapp.com. As shown in the figure below:

4.7 frame proxy attack vulnerability

Name: frame proxy attack vulnerability

Description: in some older browsers (such as IE6), frame proxy attacks can exploit non resident XSS vulnerabilities in a resident mode.

Fix: the application under the domain name of qzoneapp.com can no longer embed the page under the domain name of qq.com through iframe.

The principle is as shown in the following figure. Assuming that there is no XSS vulnerability under the domain name xiaoyou.qq.com, then xiaoyou.qq.com embeds a xxx.qzoneapp.com domain name through iframe.

Assuming that there is a non resident XSS vulnerability in a certain sub domain of qq.com, when xxx.qzoneapp.com embeds vul.qq.com through iframe, users who visit the domain name of xiaoyou.qq.com will be attacked by the resident XSS vulnerability.

© 2023