In <Be alert for Third Party Content attacks> The article analyzes the problem based on the web program vulnerability idea. However, many programs or websites have not realized that this vulnerability is a program vulnerability, therefore, once Third Party Content is controlled by attackers, many users may be directly controlled. Therefore, we only have to consider how to protect ourselves.
First, let's take a look at the Third Party Content attack process.
[Vister] IE/FF /...
| ①
V
[Www.a.com] <script src = http://www. B .com/80vul.js> </script> <-X-[hacker]
| ②
V
[Www. B .com] 80vul. js <-- ③ -- [hacker]
Generally, an attacker fails to attack site A directly, but instead attacks the server on Site B [3rd-party content]:
1. For the server, the Third Party Content should be minimized to enhance the security of the server.
2. For [vister], we only have some hands and feet in the ① process. We can first determine whether the website you visit uses Third Party Content and intercept it if it is used.
The following describes the implementation ideas of 2. The common ideas are as follows:
1. Use the man-in-the-middle method to crawl all URLs and determine whether Third Party Content has been intercepted. In this way, it is convenient to write a proxy and set the browser to use this proxy to access the Internet.
2. it is implemented by developing browser plug-ins. For example, the noscript plug-in of firefox is used to prevent execution of all js files. However, this method is more violent and may affect the functionality. the following introduces a firefox plug-in to prevent such attacks:
RequestPolicy: http://www.requestpolicy.com/
A Firefox extension that gives you control over cross-site requests.
The main purpose of this plug-in developer is to prevent attacks such as CSRF Clickjacking. If you are familiar with CSRF attacks, you may see that, the CSRF process is the same for [vister] and Third Party Content attacks. The CSRF attack process is as follows:
[Vister] IE/FF /...
| ①
V
[Www.a.com] </script> <-- [hacker]
| ②
V
[Www. B .com] 80vul. php <-- X -- [hacker]
The difference is that the attacker controls [www.a.com], while the attacker controls [www. B .com] In the Third Party Content attack, but it is exactly the same for ①. therefore, we can use RequestPolicy to effectively prevent Third Party Content attacks.
Is to demonstrate how to prevent dz events: