PHP Security - Session Hijacking

Session Hijacking

The most common attack method against sessions is session hijacking. It is a general term for all the means an attacker can use to gain access to other people's sessions. The first step in all these methods is to obtain a legitimate session ID to pretend to be a legitimate user, so it is very important to ensure that the session ID is not leaked. The knowledge about session exposure and pinning in the previous sections can help you ensure that the session identifier is known only to the server and legitimate users.

The principle of defense in depth (see Chapter 1) can be applied to sessions. When the session identifier is unfortunately known to an attacker, some inconspicuous security measures will also provide some protection. As a developer concerned with security, your goal should be to make the aforementioned disguise process more sophisticated. Remember that no matter how small the obstacle is, your application will provide protection.

The key to making the disguise process more complex is to strengthen verification. The session ID is the primary method of authentication, but you can supplement it with other data. All the data you can use is the data in each HTTP request:

 GET / HTTP/1.1
  Host: example.org
  User-Agent: Firefox/1.0
  Accept: text/html, image/png, image/jpeg,
image/gif, */*
  Cookie: PHPSESSID=1234

You should be aware of request consistency and consider inconsistent behavior to be suspicious. For example, although the User-Agent (the type of browser that issued this request) header is optional, the browser that issues the header usually does not change its value. If you have a user with a session ID of 1234 who has been using Mozilla after logging in The Firfox browser suddenly switched to IE, which is more suspicious. For example, you can mitigate the risk by requiring a password at this time. At the same time, in the event of a false alarm, this will have less impact on legitimate users. You can use the following code to detect User-Agent consistency:

I have observed that in some versions of IE browsers, the Accept header information issued when a user normally accesses a web page and refreshes a web page is different, so the Accept header cannot be used to determine consistency.

It is indeed effective to ensure that the User-Agent header information is consistent, but if the session identifier is passed through a cookie (the recommended method), it stands to reason that if the attacker can obtain the session identifier, he can also obtain other HTTP headers. Since cookie exposure is related to browser vulnerabilities or cross-site scripting vulnerabilities, the victim needs to visit the attacker's website and expose all header information. All the attacker has to do is reconstruct the header to prevent any consistency check of the header information.

A better approach is to pass a tag in the URL, which can be thought of as a second (albeit weaker) form of validation. Using this method requires some programming work, and there is no corresponding function in PHP. For example, assuming the token is stored in $token, you need to include it in all internal links in your app:

  
 
  Click Here

To make it easier to manage this delivery process, you might put the entire request string in a variable. You can append this variable to all links so that even if you don't use this technique initially, you can still easily make changes to your code later.

The tag needs to contain unpredictable content, even if the attacker knows all the HTTP headers sent by the victim's browser. One way is to generate a random string as a token:

When you use a random string (such as SHIFLETT), it is unrealistic to predict it. At this time, capturing the tag will be more convenient than predicting the tag. By passing the tag in the URL and passing the session ID in the cookie, the attack needs to capture them both at the same time. This is unless the attacker can view the raw information of all HTTP requests sent by the victim to your application, because in this case everything is exposed. This attack is very difficult to implement (and therefore rare), and preventing it requires the use of SSL.

  有专家警告不要依赖于检查User-Agent的一致性。这是因为服务器群集中的HTTP代理服务器会对User-Agent进行编辑，而本群集中的多个代理服务器在编辑该值时可能会不一致。

  如果你不希望依赖于检查User-Agent的一致性。你可以生成一个随机的标记：

  这一方法的安全性虽然是弱一些，但它更可靠。上面的两个方法都对防止会话劫持提供了强有力的手段。你需要做的是在安全性和可靠性之间作出平衡。

以上就是PHP安全-会话劫持的内容，更多相关内容请关注PHP中文网（m.sbmmt.com）！