Summary of PHP security issues

                                                                                                                                                                                                                                                                         

1-XSS

Cross-Site Scripting (cross-site scripting attack), referred to as XSS, is a code injection attack. Attackers inject malicious scripts into the target website so that they can run on the user's browser. Using these malicious scripts, attackers can obtain users' sensitive information such as cookies, SessionID, etc., thereby jeopardizing data security.

Source

• UGC information from users

• Links from third parties

• URL Parameters

• POST Parameters

• Referer (may be from an untrusted source)

• Cookie (may be injected from other subdomains)

Escape, filter, limit length

2-SQL injection

Through SQL statements, you can log in without an account and even tamper with the database.

Attack example

String sql = "select * from user_table where username=
' "+userName+" ' and password=' "+password+" '";

--当输入了上面的用户名和密码，上面的SQL语句变成：
SELECT * FROM user_table WHERE username=
'’or 1 = 1 -- and password='’

"""
--分析SQL语句：
--条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功；

--然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用，这样语句永远都--能正确执行，用户轻易骗过系统，获取合法身份。
--这还是比较温柔的，如果是执行
SELECT * FROM user_table WHERE
username='' ;DROP DATABASE (DB Name) --' and password=''
--其后果可想而知…

How to defend against SQL injection
1. Check variable data type and format
2. Filter special symbols
3. Bind variables and use precompilation statement

3-CSRF

CSRF generally refers to cross-site request forgery
The full name of the CSRF attack is cross-site request forgery (cross site request forgery), is a malicious use of a website

CSRF takes advantage of a trusted website by disguising requests from trusted users. The attacker steals your identity and sends it to a third party in your name. The website sends malicious requests. What CRSF can do includes using your identity to send emails, text messages, conduct transaction transfers, etc., and even steal your account.

For example:
As follows: Web A is a website with a CSRF vulnerability, Web B is a malicious website built by an attacker, and User C is a legitimate user of the Web A website

3-1 The principle and process of CSRF attack are as follows:

1. User C opens the browser, visits trusted website A, enters the user name and password to request to log in to 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 can send requests to website A normally;

3. Before the user exits website A, he opens a TAB page in the same browser to visit website B;

4. After receiving the user's request, website B returns some offensive code and issues a request to access website B. Third-party site A;

5. After receiving these offensive codes, the browser carries cookie information and sends a request to website A according to the request of website B 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 permissions based on user C's cookie information, causing the malicious code from website B to be executed.

3-2 Defense against CSRF attacks

There are currently three main strategies to defend against CSRF attacks: verify the HTTP Referer field; add token to the request address and verify; customize attributes in HTTP headers and verify.

1-Verify the HTTP Referer field

According to the HTTP protocol, there is a field called Referer in the HTTP header, which records the source address of the HTTP request. Under normal circumstances, the request to access a secure restricted page comes from the same website. For example, if you need to access http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory, the user must first log in to bank.example and then go through Click a button on the page to trigger the transfer event. At this time, the Referer value of the transfer request will be the URL of the page where the transfer button is located, usually an address starting with the bank.example domain name. If a hacker wants to implement a CSRF attack on a bank's website, he can only construct a request on his own website. When a user sends a request to the bank through the hacker's website, the Referer of the request points to the hacker's own 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.example, 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 by a hacker and the request will be rejected.

The obvious benefit of this method is that it is simple and easy to implement. Ordinary developers of the website do not need to worry about CSRF vulnerabilities. They only need to add an interceptor to all security-sensitive requests at the end to check the Referer value. can. Especially for the current existing system, there is no need to change any existing code and logic of the current system, there is no risk, and it is very convenient.

However, this method is not foolproof. The value of Referer is provided by the browser. Although the HTTP protocol has clear requirements, each browser may have different implementations of Referer, which does not guarantee that the browser itself has no security vulnerabilities. The method of verifying the Referer value relies on the third party (i.e. the browser) to ensure security. Theoretically, this is not safe. In fact, for some browsers, such as IE6 or FF2, there are already some methods to tamper with the Referer value. If the bank.example website supports the IE6 browser, a hacker can set the Referer value of the user's browser to an address starting with the bank.example domain name, so that it can pass the verification and conduct a CSRF attack.

Even if you use the latest browsers, hackers cannot tamper with the Referer value, and this method still has problems. Because the Referer value will record the user's access source, some users believe that this will infringe on their own privacy rights. In particular, some organizations are worried that the Referer value will leak certain information in the organization's intranet to the external network. Therefore, users themselves can set their browsers so that they no longer provide a Referer when sending requests. When they visit the bank website normally, the website will consider it a CSRF attack because the request does not have a Referer value, and deny access to legitimate users.

2-Add token in the request address and verify

The reason why the CSRF attack can be successful is because the hacker can completely forge the user's request, and all the User authentication information is stored in cookies, so hackers can directly use the user's own cookies to pass security verification without knowing the authentication information. The key to resisting CSRF is to put information in the request that hackers cannot forge, and that information does not exist in cookies. You can add a randomly generated token as a parameter to the HTTP request, and create 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 is considered that it may be a CSRF attack and the request will be rejected. .

This method is safer than checking the Referer. The token can be generated after the user logs in and placed in the session. Then the token can be taken out of the session at each request and matched with the token in the request. Compare, but the difficulty of this method is how to add the token to the request in the form of parameters. For GET requests, the token will be appended to the request address, so that the URL becomes http://url?csrftoken=tokenvalue. For POST requests, add at the end of the form, so that the token is added to the request as a parameter. However, in a website, there are many places where requests can be accepted. It is very troublesome to add a token to each request, and it is easy to miss. The commonly used method is to use javascript to traverse every time the page is loaded. For the entire dom tree, tokens are added after all a and form tags in the dom. This can solve most requests, but for html code that is dynamically generated after the page is loaded, this method has no effect and requires programmers to manually add tokens when coding.

Another disadvantage of this method is that it is difficult to ensure the security of the token itself. Especially in some forums and other websites that support users to publish their own content, hackers can publish the address of their own personal website. Since the system will also add a token after this address, hackers can get this token on their own website and launch a CSRF attack immediately. In order to avoid this, the system can add a judgment when adding the token. If the link is to the own website, add the token later. If it leads to the external network, it will not be added. However, even if the csrftoken is not attached to the request as a parameter, the hacker's website can still obtain the token value through the Referer to launch a CSRF attack. This is also the reason why some users like to manually turn off the browser Referer function.

3-Customize attributes in the HTTP header and verify

This method also uses tokens for verification. Different from the previous method, there is no Instead of putting the token as a parameter in the HTTP request, put it 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 once, and put the token value into it. This solves the inconvenience of adding token to the request in the previous method. At the same time, the address requested through XMLHttpRequest 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 the Referer.

However, this method has great limitations. The XMLHttpRequest request is usually used for partial asynchronous refresh of the page in the Ajax method. Not all requests are suitable to be initiated with this class, and the page obtained through this class request cannot be recorded by the browser, so that forward, backward, and refresh can be performed. , collection and other operations bring inconvenience to users. In addition, for legacy systems that do not have CSRF protection, if you want to use this method for protection, you must change all requests to XMLHttpRequest requests, which will almost rewrite the entire website. This cost is undoubtedly unacceptable

4-CC attack

4-1 Principle of CC attack:

The principle of CC attack is that the attacker controls some hosts to continuously send a large number of data packets to the other server, causing the server resources to be exhausted until it crashes. CC is mainly used to consume server resources. Everyone has this experience: when a large number of people visit a web page, it will be slow to open the web page. CC simulates multiple users (as many threads are as many users) without stopping. Accessing pages that require a large amount of data operations (that is, requiring a lot of CPU time) causes a waste of server resources. The CPU is at 100% for a long time, and there are always unfinished connections until the network is congested and normal access is suspended.

4-2 Types of CC attacks:

There are three types of CC attacks,

• Direct attack
• Proxy attack
• Botnet attack

Direct attacks are mainly targeted at WEB applications with important flaws. Generally speaking, they are only used when there are problems with the writing of the program. This situation occurs relatively rarely. Botnet attacks are somewhat similar to DDOS attacks. They cannot be defended from the WEB application level, so proxy attacks are CC attackers. Generally, attackers will operate a batch of proxy servers, such as 100 proxies, and then each proxy will issue 10 requests at the same time. , so that the WEB server receives 1,000 concurrent requests at the same time, and immediately disconnects from the proxy after sending the request, to prevent the data returned by the proxy from blocking its own bandwidth and unable to initiate another request. At this time, the WEB server will The processes that respond to these requests are queued, and the same is true for the database server. In this way, normal requests will be processed at the end, just like when you go to the canteen to eat, there are usually less than ten people in line. Today If a thousand people are inserted in front of you, then the chance that it will be your turn is very small. At this time, the page will open extremely slowly or a white screen will appear.

4-3 The difference between CC attacks and DDOS

DDoS is an attack on IP, while CC attacks server resources.

5-DOS attack

DOS: The Chinese name is denial of service. All attacks that can cause DOS behavior are called DOS attacks. The effect of this attack is to make the computer or network unable to provide normal services. Common DOS attacks include attacks on computer network bandwidth and connectivity. DOS is a stand-alone attack between stand-alone computers.

The principle of DOS attack: First, the attacker sends a large number of false IP requests to the attacked server. The attacked server returns confirmation information after receiving the request and waits for the attacker to confirm. (HTTP is required here. Basic knowledge of how the protocol works and TCP three-way handshake) This process requires TCP's three-way handshake. Since the request information sent by the attacker is false, the server cannot receive the returned confirmation information, and the server will be in a waiting state for a period of time. , but the resources allocated to this request have not been released. When the attacker waits for a certain period of time, the connection will be disconnected due to timeout. At this time, the attacker will send a new false information request again, so that eventually the server resources will be exhausted until it becomes paralyzed.

6-DDOS attack

DDoS attack is a distributed denial of service attack. DDoS attack method is based on traditional DoS attack A type of attack method produced. A single DoS attack is generally conducted in a one-to-one manner. With the development of computer and network technology, the difficulty of DoS attacks has increased. So the DDoS attack was born. Its principle is very simple: the processing power of computers and networks has increased by 10 times. Attacking with one attack machine no longer works. Then DDoS is launched by using more puppet machines. Attack, attack the victim on a larger scale than before. Commonly used DDoS software include: LOIC.
Add two points here: First, DDOS attacks can not only attack computers, but also routers, because routers are a special type of computer; second, network speed determines how good and fast the attack is. For example, if In an environment where your network speed is limited, their attack effect is not very obvious, but a fast network speed is more effective.

The above is the detailed content of Summary of PHP security issues. For more information, please follow other related articles on the PHP Chinese website!