Is XSS in canonical link possible?
During regular pentesting of my site I discovered that I can close double quotes in a canonical link tag and enter an onerror attribute with a simple javascript alert(1).
It is visible in source code but javascript did not execute.
I also tried with onload event but same result.
Is there a way an attacker can use different payload to execute javascript ?
penetration-test xss
asked yesterday
user101user101
1685
New contributor
user101 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
During regular pentesting of my site I discovered that I can close double quotes in a canonical link tag and enter an onerror attribute with a simple javascript alert(1).
It is visible in source code but javascript did not execute.
I also tried with onload event but same result.
Is there a way an attacker can use different payload to execute javascript ?
penetration-test xss
asked yesterday
user101user101
1685
New contributor
user101 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
4
How about a>?
– Bergi
yesterday
@Bergi: Could you be more specific ?
– user101
22 hours ago
1
You say that"is not properly escaped in the link tag attribute. Does it also accept>or<without transforming it to an entity reference?
– Bergi
21 hours ago
@Bergi: No it does not. They are filtered out.
– user101
19 hours ago
add a comment |
During regular pentesting of my site I discovered that I can close double quotes in a canonical link tag and enter an onerror attribute with a simple javascript alert(1).
It is visible in source code but javascript did not execute.
I also tried with onload event but same result.
Is there a way an attacker can use different payload to execute javascript ?
penetration-test xss
asked yesterday
user101user101
1685
New contributor
user101 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
During regular pentesting of my site I discovered that I can close double quotes in a canonical link tag and enter an onerror attribute with a simple javascript alert(1).
It is visible in source code but javascript did not execute.
I also tried with onload event but same result.
Is there a way an attacker can use different payload to execute javascript ?
penetration-test xss
penetration-test xss
asked yesterday
user101user101
1685
New contributor
user101 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
user101user101
1685
New contributor
user101 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited yesterday
user101
asked yesterday
user101user101
1685
New contributor
user101 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
user101user101
1685
asked yesterday
user101user101
1685
1685
New contributor
user101 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
user101 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
user101 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
4
How about a>?
– Bergi
yesterday
@Bergi: Could you be more specific ?
– user101
22 hours ago
1
You say that"is not properly escaped in the link tag attribute. Does it also accept>or<without transforming it to an entity reference?
– Bergi
21 hours ago
@Bergi: No it does not. They are filtered out.
– user101
19 hours ago
add a comment |
4
How about a>?
– Bergi
yesterday
@Bergi: Could you be more specific ?
– user101
22 hours ago
1
You say that"is not properly escaped in the link tag attribute. Does it also accept>or<without transforming it to an entity reference?
– Bergi
21 hours ago
@Bergi: No it does not. They are filtered out.
– user101
19 hours ago
4
4
How about a
>?– Bergi
yesterday
How about a
>?– Bergi
yesterday
@Bergi: Could you be more specific ?
– user101
22 hours ago
@Bergi: Could you be more specific ?
– user101
22 hours ago
1
1
You say that
" is not properly escaped in the link tag attribute. Does it also accept > or < without transforming it to an entity reference?– Bergi
21 hours ago
You say that
" is not properly escaped in the link tag attribute. Does it also accept > or < without transforming it to an entity reference?– Bergi
21 hours ago
@Bergi: No it does not. They are filtered out.
– user101
19 hours ago
@Bergi: No it does not. They are filtered out.
– user101
19 hours ago
add a comment |
1 Answer
1
active
oldest
votes
You can use the same trick as can be used with hidden inputs:
<link rel="canonical" accesskey="X" onclick="alert(1)" />
On Linux, use ALT+SHIFT+X to trigger the payload. IMHO it's enough to report the issue and get it fixed, but it does require some unlikely user interaction.
Other than that, I see no way to exploit this in a modern browser without further code.
While the link tag supports the onload attribute, it only fires when something is successfully loaded, eg:
<link rel="stylesheet" href="http://localhost/test.css" onload="alert(1)">
If your injection were <link href="[user input]" rel="canonical">, then you could exploit it via http://somedomain/somecsssfile.css" rel="stylesheet" onload="alert(1).
The WHATWG spec defines that the first attribute must be used, so it is unlikely that any browser would use the second, so this will not work for your case.
I tried all other event attributes, and none trigger on a normal page load.
This blog post states that this would be exploitable under IE7 and IE8 by injecting a style attribute which then uses an expression to execute JavaScript.
If there is additional JavaScript code that insecurely processes elements, this might also become exploitable (see here for an interesting example).
answered yesterday
timtim
24.2k668102
Thanks ! You saved my day. For Windows ALT + X works too. This could be chained with clickjacking (if present in website) to execute Javascript.
– user101
yesterday
How to fix the issue then?
– Nigel Fds
yesterday
1
@NigelFds: By filtering out characters like ", < and >.
– user101
22 hours ago
1
@NigelFds Most - but not all - of the time, you'd want to HTML-encode relevant characters (', ", <, >) when echoing user input. As this is in a URL context, you could also URL-encode the data (see OWASP which also has a good overview of XSS prevention in other contexts, and when encoding of ', ", <, > is not enough).
– tim
20 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
user101 is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f205975%2fis-xss-in-canonical-link-possible%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can use the same trick as can be used with hidden inputs:
<link rel="canonical" accesskey="X" onclick="alert(1)" />
On Linux, use ALT+SHIFT+X to trigger the payload. IMHO it's enough to report the issue and get it fixed, but it does require some unlikely user interaction.
Other than that, I see no way to exploit this in a modern browser without further code.
While the link tag supports the onload attribute, it only fires when something is successfully loaded, eg:
<link rel="stylesheet" href="http://localhost/test.css" onload="alert(1)">
If your injection were <link href="[user input]" rel="canonical">, then you could exploit it via http://somedomain/somecsssfile.css" rel="stylesheet" onload="alert(1).
The WHATWG spec defines that the first attribute must be used, so it is unlikely that any browser would use the second, so this will not work for your case.
I tried all other event attributes, and none trigger on a normal page load.
This blog post states that this would be exploitable under IE7 and IE8 by injecting a style attribute which then uses an expression to execute JavaScript.
If there is additional JavaScript code that insecurely processes elements, this might also become exploitable (see here for an interesting example).
answered yesterday
timtim
24.2k668102
Thanks ! You saved my day. For Windows ALT + X works too. This could be chained with clickjacking (if present in website) to execute Javascript.
– user101
yesterday
How to fix the issue then?
– Nigel Fds
yesterday
1
@NigelFds: By filtering out characters like ", < and >.
– user101
22 hours ago
1
@NigelFds Most - but not all - of the time, you'd want to HTML-encode relevant characters (', ", <, >) when echoing user input. As this is in a URL context, you could also URL-encode the data (see OWASP which also has a good overview of XSS prevention in other contexts, and when encoding of ', ", <, > is not enough).
– tim
20 hours ago
add a comment |
You can use the same trick as can be used with hidden inputs:
<link rel="canonical" accesskey="X" onclick="alert(1)" />
On Linux, use ALT+SHIFT+X to trigger the payload. IMHO it's enough to report the issue and get it fixed, but it does require some unlikely user interaction.
Other than that, I see no way to exploit this in a modern browser without further code.
While the link tag supports the onload attribute, it only fires when something is successfully loaded, eg:
<link rel="stylesheet" href="http://localhost/test.css" onload="alert(1)">
If your injection were <link href="[user input]" rel="canonical">, then you could exploit it via http://somedomain/somecsssfile.css" rel="stylesheet" onload="alert(1).
The WHATWG spec defines that the first attribute must be used, so it is unlikely that any browser would use the second, so this will not work for your case.
I tried all other event attributes, and none trigger on a normal page load.
This blog post states that this would be exploitable under IE7 and IE8 by injecting a style attribute which then uses an expression to execute JavaScript.
If there is additional JavaScript code that insecurely processes elements, this might also become exploitable (see here for an interesting example).
answered yesterday
timtim
24.2k668102
Thanks ! You saved my day. For Windows ALT + X works too. This could be chained with clickjacking (if present in website) to execute Javascript.
– user101
yesterday
How to fix the issue then?
– Nigel Fds
yesterday
1
@NigelFds: By filtering out characters like ", < and >.
– user101
22 hours ago
1
@NigelFds Most - but not all - of the time, you'd want to HTML-encode relevant characters (', ", <, >) when echoing user input. As this is in a URL context, you could also URL-encode the data (see OWASP which also has a good overview of XSS prevention in other contexts, and when encoding of ', ", <, > is not enough).
– tim
20 hours ago
add a comment |
You can use the same trick as can be used with hidden inputs:
<link rel="canonical" accesskey="X" onclick="alert(1)" />
On Linux, use ALT+SHIFT+X to trigger the payload. IMHO it's enough to report the issue and get it fixed, but it does require some unlikely user interaction.
Other than that, I see no way to exploit this in a modern browser without further code.
While the link tag supports the onload attribute, it only fires when something is successfully loaded, eg:
<link rel="stylesheet" href="http://localhost/test.css" onload="alert(1)">
If your injection were <link href="[user input]" rel="canonical">, then you could exploit it via http://somedomain/somecsssfile.css" rel="stylesheet" onload="alert(1).
The WHATWG spec defines that the first attribute must be used, so it is unlikely that any browser would use the second, so this will not work for your case.
I tried all other event attributes, and none trigger on a normal page load.
This blog post states that this would be exploitable under IE7 and IE8 by injecting a style attribute which then uses an expression to execute JavaScript.
If there is additional JavaScript code that insecurely processes elements, this might also become exploitable (see here for an interesting example).
answered yesterday
timtim
24.2k668102
You can use the same trick as can be used with hidden inputs:
<link rel="canonical" accesskey="X" onclick="alert(1)" />
On Linux, use ALT+SHIFT+X to trigger the payload. IMHO it's enough to report the issue and get it fixed, but it does require some unlikely user interaction.
Other than that, I see no way to exploit this in a modern browser without further code.
While the link tag supports the onload attribute, it only fires when something is successfully loaded, eg:
<link rel="stylesheet" href="http://localhost/test.css" onload="alert(1)">
If your injection were <link href="[user input]" rel="canonical">, then you could exploit it via http://somedomain/somecsssfile.css" rel="stylesheet" onload="alert(1).
The WHATWG spec defines that the first attribute must be used, so it is unlikely that any browser would use the second, so this will not work for your case.
I tried all other event attributes, and none trigger on a normal page load.
This blog post states that this would be exploitable under IE7 and IE8 by injecting a style attribute which then uses an expression to execute JavaScript.
If there is additional JavaScript code that insecurely processes elements, this might also become exploitable (see here for an interesting example).
answered yesterday
timtim
24.2k668102
edited yesterday
answered yesterday
timtim
24.2k668102
answered yesterday
timtim
24.2k668102
answered yesterday
timtim
24.2k668102
24.2k668102
Thanks ! You saved my day. For Windows ALT + X works too. This could be chained with clickjacking (if present in website) to execute Javascript.
– user101
yesterday
How to fix the issue then?
– Nigel Fds
yesterday
1
@NigelFds: By filtering out characters like ", < and >.
– user101
22 hours ago
1
@NigelFds Most - but not all - of the time, you'd want to HTML-encode relevant characters (', ", <, >) when echoing user input. As this is in a URL context, you could also URL-encode the data (see OWASP which also has a good overview of XSS prevention in other contexts, and when encoding of ', ", <, > is not enough).
– tim
20 hours ago
add a comment |
Thanks ! You saved my day. For Windows ALT + X works too. This could be chained with clickjacking (if present in website) to execute Javascript.
– user101
yesterday
How to fix the issue then?
– Nigel Fds
yesterday
1
@NigelFds: By filtering out characters like ", < and >.
– user101
22 hours ago
1
@NigelFds Most - but not all - of the time, you'd want to HTML-encode relevant characters (', ", <, >) when echoing user input. As this is in a URL context, you could also URL-encode the data (see OWASP which also has a good overview of XSS prevention in other contexts, and when encoding of ', ", <, > is not enough).
– tim
20 hours ago
Thanks ! You saved my day. For Windows ALT + X works too. This could be chained with clickjacking (if present in website) to execute Javascript.
– user101
yesterday
Thanks ! You saved my day. For Windows ALT + X works too. This could be chained with clickjacking (if present in website) to execute Javascript.
– user101
yesterday
How to fix the issue then?
– Nigel Fds
yesterday
How to fix the issue then?
– Nigel Fds
yesterday
1
1
@NigelFds: By filtering out characters like ", < and >.
– user101
22 hours ago
@NigelFds: By filtering out characters like ", < and >.
– user101
22 hours ago
1
1
@NigelFds Most - but not all - of the time, you'd want to HTML-encode relevant characters (', ", <, >) when echoing user input. As this is in a URL context, you could also URL-encode the data (see OWASP which also has a good overview of XSS prevention in other contexts, and when encoding of ', ", <, > is not enough).
– tim
20 hours ago
@NigelFds Most - but not all - of the time, you'd want to HTML-encode relevant characters (', ", <, >) when echoing user input. As this is in a URL context, you could also URL-encode the data (see OWASP which also has a good overview of XSS prevention in other contexts, and when encoding of ', ", <, > is not enough).
– tim
20 hours ago
add a comment |
user101 is a new contributor. Be nice, and check out our Code of Conduct.
user101 is a new contributor. Be nice, and check out our Code of Conduct.
user101 is a new contributor. Be nice, and check out our Code of Conduct.
user101 is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f205975%2fis-xss-in-canonical-link-possible%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
How about a
>?– Bergi
yesterday
@Bergi: Could you be more specific ?
– user101
22 hours ago
1
You say that
"is not properly escaped in the link tag attribute. Does it also accept>or<without transforming it to an entity reference?– Bergi
21 hours ago
@Bergi: No it does not. They are filtered out.
– user101
19 hours ago