SQL injection, XSS, XXE, CSRF, SSRF, unauthorized vulnerability, file upload, file inclusion summary

SQL injection

What is SQL Injection?

It means that the web application does not judge the legitimacy of the data input by the user or does not strictly filter it. The attacker can add additional SQL statements to the end of the defined query statement in the web program, without the administrator's knowledge. In order to deceive the database server to perform unauthorized arbitrary queries, and further obtain the corresponding data information

It is to use some means to add a malicious SQL statement and execute it on the basis of the original SQL statement, so as to achieve the purpose of not being allowed by the administrator

How to defend?

It is recommended to convert the numeric type parameters in the code first, and then substitute them into the SQL query statement, so that any injection behavior will fail. Also consider filtering some parameters, such as get parameters and post parameters for the part of the SOL language query.

filter special characters

Therefore, it is necessary to check the user's input when guarding against it.
Special characters, such as single quotes, double quotes, semicolons, commas, colons, hyphens, etc. are converted or overbuilt. The following are sensitive characters or statements that need to be filtered :
【1】net user
【2】xp_c«ndshel I
【3】add
【4】xec master.(fco. xp_cmdshelI
【5】net I oca Igroup administrators
【6】□select
【7】count
【8】Asc
【9 】char
【10】mid
【11】%
【12】,
【13】:
【14】-
【15】 insert
【16】 delete from
【17】 drop table
【18】 update
【19】truncate
【20】 from

Modify php.in

Modify the configuration in the default configuration file php.ini in PHP to reduce the risk of sql injection
safe_mode = on //Enable safe mode
magic_quotes_gpc = On 〃Enable the built function
display_errors = Off 〃Disable error message prompts Note: The JBnagic_auotes_gpc option is turned on, in In this case, all client GET and POST data will be automatically processed by addslashes, so SQL injection of string values ​​is not feasible at this time, but to prevent SQL injection of numeric values, such as using functions such as intvalO deal with. But if you are writing general-purpose software, you need to read the magic_Quotes_gpc of the server and process it accordingly.

Using the mysqli_real_escape_string() function

For MySQL users, the function mysqli_real_escape_string() can be used: escape special characters in strings used in SQL statements

Hardening the database

1. Do not connect to the database as a sysadmin. Instead use a specific database user with only the appropriate privileges to read, write and update the appropriate data in the database. This account is regularly checked to determine the privileges it has.
2. Create SQL in a secure manner. Let the database do the work of creating the SQL, not in code. Using parameterized SQL statements can also improve the efficiency of the query.
3. Ensure that the database user connection information is not stored in plain text.

Reinforcement management

1. Strengthen the programmer's good security coding awareness, systematically learn the knowledge of security coding, and reduce the risk of source code leakage.
2. Establish a good code review and review system. Special personnel are responsible for code audit and increase safety supervision.

Mybatis

[1] Precompile

【2】like
1.MySQL
2.Oracle

3.sql server

【3】in

firewall

XSS

What is XSS?

SS, as one of the OWASP TOP 10,
XSS is called cross-site scripting (Cross-site scripting), which should be abbreviated as CSS, but because of the same name as CSS (Cascading Style
Sheets, cascading style script), it was renamed XSS. XSS (Cross Site Scripting) is mainly based on javascript (JS) to complete malicious attacks
.
JS can operate html, css and browsers very flexibly, which makes the "imagination" space of XSS attack particularly large. XSS
achieves the effect of malicious attacks by injecting carefully constructed code (JS) code into the web page, and the browser interprets and runs this JS code.
When the user visits the webpage injected by the XSS script, the XSS script will be extracted, and the user's browser will parse the XSS code, which means
that the user is attacked. The simplest action for users is to use a browser to surf the Internet, and there is a javascrit interpreter in the browser, which can
parse javascript, but the browser will not judge whether the code is malicious or not. That is, the object of XSS is the user and the browser.

Where does the bug happen?

Servers, microblogs, message boards, chat rooms, etc. where user input is collected may be injected with XSS code, and there is a risk of suffering from XSS. As long as
the user input is not strictly filtered, it will be XSS.

The dangers of XSS

XSS uses JS code to achieve attacks. There are many attack methods. The following are briefly listed below.

1. Stealing various user accounts
2. Steal user cookie information and enter the website as a user
3. Hijack user sessions and perform arbitrary actions
4. Swipe traffic and execute pop-up ads
5. spread worm

XSS Platform generates XSS attack code according to various requirements, such as obtaining administrator cookie, etc. After
obtaining administrator cookie, you can directly access the background

Classification of XSS

XSS vulnerabilities can be roughly divided into three types: Reflected XSS, Stored XSS, DOM XSS
Reflected XSS (user-triggered)
Reflected XSS is a non-persistent, parametric cross-site scripting
Reflected XSS JS code in Web applications parameters (variables), such as the reflected XSS of the search box

Reflective

That is, by sending someone a URL with malicious script code parameters, when the URL address is opened, the specific code parameters will be parsed and executed by HTML.
It is deceptive, sending you an address with a reflective XSS vulnerability, and you click, causing an XSS attack.

storage type

Stored XSS is persistent cross-site scripting
. Persistence is reflected in the XSS code is not written in a certain parameter (variable), but written into a medium that can permanently save data such as a database or file.
Stored XSS usually occurs in message boards, etc. place. We leave a message at the message board location and write malicious code into the database.
At this point, we have only completed the first step, writing malicious code to the database. Because the JS code used by XSS, the operating environment of the JS code is the browser
, so the browser needs to load the malicious XSS code from the server to actually trigger the XSS.

DOM type

DOM XSS (using DOM events to trigger)
DOM XSS is special. owasp's definition of DOM type XSS is that DOM-based XSS is a type of XSS attack
. The payload of the attack is executed by modifying the DOM tree of the victim's browser page.
Its special feature is that the payload is difficult to detect
and may trigger attributes of DOM type XSS.
1. document.referer attribute
2, location attribute
3, innerHTML attribute

XSS defense

[1] Filtering input and URL parameters (whitelist and blacklist)
[2] Encoding
output Encoding and escaping potentially threatening characters before outputting data is a very effective measure to prevent XSS attacks. If used well, it can theoretically defend against all XSS attacks.
For all the content to be dynamically output to the page, perform relevant encoding and escaping. Of course, escaping is determined according to the context of its output.

1. Output as body text, output as attributes of html tags
2. URL attributes
   If the src and href attributes of tags such as <script> , <style> , <imt> are dynamic content, make sure that these urls do not perform
   malicious connections.
   Make sure: the values ​​of href and src must start with http://, whitelist method; no hexadecimal and hexadecimal coded characters.

HttpOnly and XSS Defense

XSS generally uses js script to read the cookie in the user's browser. If the HttpOnly attribute is set on the cookie on the server side, then the js script cannot read the cookie, but the browser can still use the cookie normally.
General cookies are obtained from the document object. Now browsers generally accept a parameter called HttpOnly when setting a cookie, which is the same as other parameters such as domain. Once this HttpOnly is set, you are in the document object of the browser. You can't see the cookie, and the browser is not affected in any way when browsing, because the cookie will be sent in the browser header (including ajax), and the application will generally not operate these sensitive items in js. For cookies, we use HttpOnly for some sensitive cookies, and we do not set them for some cookies that need to be operated with js in the application, thus ensuring the security of cookie
information and the application. If you are using a Java EE 6.0 compliant container, such as Tomcat 7, then the Cookie class already has a setHttpOnly method to use the HttpOnly Cookie property.
cookie.setHttpOnly(true );

XX

What is XXE vulnerability?

XXE (XML External Entity) refers to the xml external entity attack vulnerability. An XML external entity attack is an attack against applications that parse XML input. This attack occurs when XML input containing references to external entities is processed by a weakly configured XML parser.
By constructing malicious content, this kind of attack can lead to harms such as reading arbitrary files, executing system commands, detecting intranet ports, and attacking intranet websites
.

XXE defense

1. Check the underlying parsing library used, and the parsing of external entities is prohibited by default.
2. Enhance the monitoring of the system to prevent this problem from being exploited.
3. Use third-party application code to update the patch
in time 4. For PHP. Because of the sinpxml_load_string function The XML parsing problem is with the 1 ibxml library, so such a function can be called before loading the entity for protection

<?php // with the XM.Reader functionality: $doc = XMLReader::xml(SbadXml. ,UTF-8*. LIBXML_NONET): // with the DOM functionality: Sdom = new DOWocument 0 : $dom->1oadXML(SbadXml. L1BXML_DTDLOAD|L18XML_DTDATTR): ?>

5、6、 JAVA

7、python
8、.Net

9, ASP

10, filter characters

11. WAF
12. Filter XML data submitted by users
Filter keywords: !ENTITY, or SYSTEM and PUBLI

CSRF

What is CSRF?

CSRF (Cross-Site Request Forgery, Cross-Site Request Forgery) is a network attack method that can forge requests in the victim's name and send it to the attacked site without the victim's knowledge. It is very harmful to perform operations under the protection of permissions. Specifically, a CSRF attack can be understood as follows: the attacker steals your identity and sends a malicious request in your name. This request is completely legal to the server, but it completes an operation expected by the attacker, such as Send emails and messages in your name, steal your account, add system administrators, even purchase goods, transfer virtual currency, etc.

The principle of CSRF attack is relatively simple, as shown in Figure 1. Among them, Web A is the website with CSRF vulnerability, Web B is the malicious website constructed by the attacker
, and User C is the legitimate user of the Web A website.

1. User C opens the browser, visits the trusted website A, and enters the user name and password to request to log in to the website A;
2. After the user information is verified, website A generates cookie information and returns it to the browser. At this time, the user successfully logs in to website A, and the request can be sent to website A normally;
3. Before the user exits website A, in the same browser, open a TAB page to visit website B;
4. After the website B receives the user request, it returns some offensive codes and sends a request to visit the third-party website A;
5. After receiving these offensive codes, the browser sends a request to website A according to the request of website B, carrying the cookie information without the user's knowledge. Website A does not know that the request is actually initiated by B, so it will process the request with C's authority according to user C's cookie information, resulting in the execution of malicious code from website B.

CSRF Vulnerability Defense

1. Verify the HTTP Referer field
2. Add a token to the request address and verify it
. 3. Customize the attribute in the HTTP header and verify it
.
Defense and defense of security equipment.
5. Defense of the server

1. Verifying the HTTP Referer field
   According to the HTTP protocol, there is a field in the HTTP header called Referer, which records the source address of the HTTP request. In general
   , requests to access a security-restricted page must come from the same website. For example, the transfer of a bank is completed by the user visiting the http:
   //bank.test/test?page=10&userID=101&money=10000 page, the user must first log in to bank.test, and then
   click the button on the page to trigger the transfer event . When a user submits a request, the Referer value of the transfer request will be
   the URL of the page where the transfer button is located (in this case, usually the address starting with the domain name of bank.test). If an attacker wants to carry out a CSRF attack on a bank website,
   he can only construct a request on his own website. When a user sends a request to the bank through the attacker's website, the referer of the request points to the attacker
   's website. Therefore, to defend against CSRF attacks, the bank website only needs to verify its Referer value for each transfer request. If it is
   a domain name starting with bank.test, it means that the request is from the bank website itself and is legal. If the Referer is another website
   , it may be a CSRF attack, and the request will be rejected.
2. Adding a token to the request address and verifying that the
   CSRF attack is successful is because the attacker can forge the user's request, and all the user authentication information in the request exists in the
   cookie, so the attacker can use it without knowing the authentication information. In this case, the user's own cookie is directly used to pass the security verification
   . It can be seen from this that the key to resisting CSRF attacks is to put information that cannot be forged by the attacker in the request, and the information does not exist
   in the cookie. In view of this, system developers can add a randomly generated token in the form of a parameter to the HTTP request, and
   establish an interceptor on the server side to verify the token. If there is no token in the request or the token content is incorrect, it may
   be CSRF attack and reject the request.
3. The method of customizing attributes in HTTP headers and verifying
   them is also to use tokens and verify them. The difference from the previous method is that the tokens are not placed in the HTTP request in the
   form , but the It is placed in a custom attribute in the HTTP header. Through the XMLHttpRequest class, you can
   add the csrftoken HTTP header attribute to all requests of this type at one time, and put the token value into it. This solves the inconvenience of adding a token to the request in the previous method
   . At the same time, the address requested through this class will not be recorded in the browser's address bar, and there is no need to worry about the
   token being leaked to other websites through Referer.

6. Other defense methods

1. CSRF attacks are conditional. When a user accesses a malicious link, the authentication cookie is still valid. Therefore, when the user closes the page, it
   is particularly important to clear the authentication cookie in time for browsers that support TAB mode (opening a web page in a new tab).
2. Minimize or do not use the request() class variable as much as possible, and specify request.form() or request.querystring()
   as to prevent CSRF vulnerability attacks. This method can not completely defend against CSRF attacks, but increases to a certain extent. the difficulty
   of attacking.

SSRF

What is SSRF?

Server-side Request Forgery Attacks (Server-side Request Forgery)
Many web applications provide the function of obtaining data from other servers.
Using the URL specified by the user, the web application can fetch the image. Download files, read file content, etc.
This feature, if used maliciously, can exploit the flawed web application as a proxy to attack remote and local servers. This form of attack is called a Server-side Request Forgery attack.
- In general, SSRF attacks target internal systems that cannot be accessed from the external network. (Precisely because it is initiated by the server, it can request to the internal system connected to it and isolated from the external network).
Most of the reasons for the formation of SSRF are that the server provides the function of obtaining data from other server applications and does not filter and restrict the target address.
For example, batch get the text content of web pages from the specified URL, load the pictures of the specified address, download and so on.
Attackers can use ssrf to achieve five main types of attacks:
1. Port scanning can be performed locally on the external network and the internal network where the server is located to obtain banner information of some services.
2. Attack applications running on the intranet or local (such as overflow).
3. Fingerprint identification of intranet web applications by accessing default files.
4. Attacking web applications on the internal and external networks, mainly attacks that can be achieved by using get parameters (such as struts?, SQli, etc.).
5. Use the file protocol to read local files, etc.

SSRF Defense

1. It is easier to filter the returned information and verify the remote server's response to the request. If the web application is to fetch a certain type of file. Then verify whether the returned information meets the standard before displaying the returned result to the user. Unify the error information to prevent users from judging the port status of the remote server based on the error information.
2. Restrict the requested port to the port commonly used by http, for example, 80, 443, 8080.8090.
3. Blacklist intranet ip. Avoid applications being used to obtain intranet data and attack the intranet.
4. Disable unnecessary protocols. Only http and https requests are allowed. Can prevent problems like file:///.gopher://, ftp://, etc. cause.
5. Unify error messages
6. Set URL whitelist

Ultraviolet Vulnerability

What is an overreach vulnerability?

Unauthorized vulnerabilities are further divided into horizontal unauthorized access and vertical unauthorized access. In simple terms, it is the permission of ordinary users to operate, which can be changed into administrator permission through the vulnerability, or the permission to operate other people's accounts, also called unauthorized vulnerability. Normally, if you access some operations of the administrator, you need to have security verification, and unauthorized access will lead to bypass verification, you can access some sensitive information of the administrator, and some operations of the administrator will lead to the leakage of confidential data. A vertical override vulnerability can use a low-privileged account to perform operations on a high-privileged account, such as the ability to operate an administrator's account function, while a horizontal override vulnerability can be used to operate between account permissions at the same level, and to access some account sensitive information , for example, you can modify the information of any account, including viewing the member's mobile phone number, name, recharge records, order cancellation records, withdrawal records, betting records, etc., and it can also cause the use of horizontal overrides to perform functions of other users, such as deleting the bank. card, modify mobile phone number, secret answer and so on.

Horizontal override:
The algorithm does not verify the validity of the user identity of the user who sends the HTTP request, and also controls the authority of the request.
Vertical override:

1. First use bp to obtain the request information of the admin super administrator user to add a user
2. After obtaining the login information of ordinary customer service users
3. The operation of adding users can also be performed using the cookie discovery of ordinary users (there is an unauthorized vulnerability)

How to prevent unauthorized loopholes?

Perform security verification on the page with permission verification, and verify the parameters, ID, account password obtained from the front end of the website APP, and return it also
requires verification. For functions such as modification and addition, the current authority is judged, the user is verified, and the seesion is used to verify the security of
the user. The operation authority of the user, get and post data are only allowed to enter the specified information, and the data package cannot be modified.
Whether the request is the identity of the current user, you can strengthen the verification.

File Upload

What is file upload?

To allow users to upload files to the website is like opening another door to malicious users of the crisis server. Even so, in today's
modern Internet web applications, it is a common requirement as it helps improve business efficiency. The enterprise support portal allows users to
efficiently share files with employees across the enterprise. Allows users to upload pictures, videos, avatars and many other types of files. The more functions are provided to users
, the greater the risk and opportunity for web applications to be attacked. The possibility that such functions will be exploited by malicious users to gain access to a specific website
or compromise the server is very high. There is nothing wrong with uploading files, the problem and vulnerability lies in how the server handles the
uploaded files.
The general situations are:

• 1. Upload the file WEB script language, the WEB container of the server interprets and executes the script uploaded by the user, resulting in code execution;
• 2. Upload the file FLASH policy file crossdomain, xml to control the behavior of Flash in this domain;
• 3. The uploaded file is a virus' Trojan horse file, which is used by attackers to trick users or administrators into downloading and executing;
• 4. If the uploaded file is a phishing image or contains the original image, some browsers will execute it as a script to implement phishing or fraud;

The premise of file upload
1, the website upload function can be used normally
2, the file type is allowed to upload
3, the upload path can be determined
4, the file can be accessed, can be executed or included
linux file permissions
r=4
w=2
x=1

How to protect against file upload vulnerabilities?

According to the characteristics of the file upload vulnerability and the three conditions that must be met, we can block any one of the conditions to achieve the purpose of organizing file upload attacks:
1. The most effective way is to directly set the file upload directory to be non-executable. For Linux , revoke the permission of its directory; in fact, many uploading applications of large websites will be placed on independent storage for processing as static files, one is to facilitate the use of cache to accelerate and reduce energy consumption, and the other is to eliminate the possibility of script execution;
2. File Type checking: Whitelisting is strongly recommended, combined with MIME Type, suffix checking and other methods (that is, only allowed file types are allowed to be uploaded); in addition, for image processing, the compression function or resize function can be used to process images while destroying the contents contained in them. HTML code;
3. Use random numbers to rewrite the file name and file path, so that users cannot easily access the files uploaded by themselves;
4. Set the domain name of the file server separately;

file contains

What is file inclusion?

File inclusion means that program code does not have strict control over the handling of included files.
As a result, users can construct parameters including remote code to execute on the server, obtain website configuration or sensitive files, and then obtain server permissions, resulting in a series of malignant consequences such as malicious deletion of the website and tampering of user and transaction data.
It mainly includes two forms of local file inclusion and remote file inclusion.
Since developers write source code, it is open to insert reusable code into a single file, and include them in special function code files when needed, and then The code in the include file is interpreted and executed.
Since there is no filtering for the function entry contained in the file in the code, the client can submit a malicious construct statement, which is then interpreted and executed by the server.
In the file inclusion attack, there may be file inclusion operation functions such as inlcudeO in the source code of the WEB server, and the file path can be constructed and submitted through the client, which is the main reason for the success of the vulnerability attack.

How to fix file inclusion vulnerability?

1. PHP configure php.ini to turn off the remote file inclusion function (allow.urljnclude = Off)
2. Strictly check whether the variable has been initialized.
3. It is recommended to assume that all input is suspicious, and try to submit file addresses that may contain possible file addresses for all input , including the server's local files and remote files, are strictly checked, and directory jump characters such as .../ are not allowed in the parameters.
4. Strictly check whether the parameters in the functions included in the include files are controllable from the outside world.
5. Don't just verify and filter the data on the client side. The key filtering steps are performed on the server side.
6. Test all known threats before releasing the application
7. Set up file whitelist