Neat puzzle! Yes, that filter is exploitable.
No, your code is fine.
Cross Site Scripting requires
untrusted input to be
interpreted as code in the browser.
Your code is safe, because it does not reflect the untrusted input (myVar) back into the generated HTML.
To see XSS in action, just add <%=myVar %> at the end of your code snippet. There it is: Reflected XSS
From what I see, unless you've output that myVar to the page or its applied to any other page, I do not believe so. I'm not a java expert but please correct my understanding below:
If I understand correctly, you've simply taken the Request Parameter myVar and stored it in memory as myVar in your application. Using 2, if statements with boolean logic to ...
The frame is not being loaded from a remote source.
What you're adding to the page is something like this:
Generic answer since I'm not familiar with HubSpot in particular.
You can't, ever, use client-side script on the parent page to modify content in an iframe that is loaded from another domain (or that is sandboxed without the allow-same-origin sandbox exception). If you are able to access the contentDocument of an iframe, then it is a same-origin iframe. That'...
There are two possible cases I can see for this:
This is due to the browser URL-encoding the exploit strong, and the server isn't decoding it. That might be defeated in various ways (try other browsers, try submitting the navigation request via JS or via a hardcoded link rather than using the in-app button, try finding an exploit string that doesn't require ...
One method is to check if the server supports TRACE method. TRACE method is used for debugging mainly. The response contains the cookies even HttpOnly ones. Then with XSS vulnerability you make a payload with a XHR request with TRACE method and collect the response containing the cookies.
Another technique is a "cookie jar overflow". Chrome has ...
I see at least 3 possible bypasses:
The most obvious one, which should work based on your post, is by using double quotes instead of simple quotes:
The second one, which is rarely filtered in my experience, is ...
Use an HTML data-* attribute to store the object as JSON and later parse it with JS. This has several security and design advantages over injecting directly into an inline <script>.
Let's inject the JSON-serialized object into the data-obj attribute of a <div>:
<div id="appdata" data-obj="@Json.Encode(Model)"><...
If you trust the ...