-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathRisk-of-trusting-subdomains.html
23 lines (23 loc) · 2.25 KB
/
Risk-of-trusting-subdomains.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="generator" content="pandoc">
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
<title></title>
<style type="text/css">code{white-space: pre;}</style>
<!--[if lt IE 9]>
<script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<link rel="stylesheet" href="./github-markdown.css">
</head>
<body>
<h2 id="risk-of-trusting-subdomains">Risk of trusting subdomains</h2>
<p><em>Note: This does not apply if you untick <code>Allow requests to the same domain</code> in <code>Preferences > Manage policies > Default Policy</code></em></p>
<ul>
<li>Subdomains are generally assumed to be owned by the same organization as the main domain. (eg. <code>images.example.com</code> is assumed to belong to the same organization as <code>www.example.com</code>). The general risk is that it is <em>possible</em> for a site to direct traffic for a subdomain of theirs to a different company's IP address. This situation appears to be fairly uncommon at the current time, but is a real threat to privacy and is currently in use on various popular sites. The owner of <code>example.com</code> could point <code>cdn.example.com</code> to a content distribution network used on <code>example.com</code>, but that is actually owned by an other company (content delivery netowrks, analytics and tracking services...), or to direct traffic for <code>ads.example.com</code> to an other company that serves ads.</li>
<li>If you host <code>personal.example.com</code> on your local network, an attacker who controls <code>another.example.com</code> will be able to bypass RequestPolicy's <em>default deny</em> policy for <code>personal.example.com</code>, as it does not apply to requests to the same domain.</li>
<li>An attacker that tricks you into visiting <code>www.evilsite.com</code> could point his subdomain <code>attack.evilsite.com</code> to the IP address of <code>your-bank.com</code>, thus the requests to the bank site will be allowed. However, your browser will not send cookies saved for <code>your-bank.com</code> to the attacker, as they do not have the same domain name. This makes the attack less useful in most situations.</li>
</ul>
</body>
</html>