0

I've been learning about XSS recently, and then I was trying to come up with ways to bypass anti-XSS filters in browsers. I though, "Maybe if you used a link shortener that virtualized your site!", similar to how a proxy site virtualizes pages, or W3Schools' Try It Editor (except it doesn't show code). The concept is that a link shortener would use a suspicious link and render the page into a virtualizer.

For example, Bob finds an XSS vulnerability in a site and shorten it into a shortened link; any shortened link less suspicious than https://vulnerable.com/<scRIPt>alert("XSSed!");</scriPT>. Bob would use the virtualizing URL shortener and put the above URL as the link and it would be virtualized into an <iframe> or something and not warn the user of malicious code and then send it to someone, who would then click on it.

Would this work to bypass XSS filters? Does a site like this already exist?

  • How would a link shortener solve that? Could you be a little more specific on the approach you're suggesting? – Arminius Apr 27 '17 at 22:58
  • There, I edited it. – anonymous Apr 27 '17 at 23:08
0

Ordinary URL shorterners are commonly used to hide the payload and make links look less suspisious. However, they do not help against the browsers XSS filters, since what an ordinary URL shorterner does is simply issuing a redirect.

You suggest an approach to bulding an URL shorterner that does bypass the browsers XSS filters using what you call virtualization instead of redirects.

The way to do this virtualization would be using an iframe. The only problem is that the browsers XSS filter will (probably) be protecting the iframe in the same way that it is protecting you when you enter a URL in the URL bar. So you don't win anything.

And using an iframe is the only way I can think of doing "virtualization" without running into the SOP. So I don't think this is a viable concept.

-1

First the https://vulnerable.com/<scRIPt>alert("XSSed!");</scriPT> is not dangerous for you, since you are asking(asking doesn't mean parse and run it locally) about a resource/path (here is <scRIPt>alert("XSSed!");</scriPT>).

In fact this is XSSing the server by the client. And I really think we have a such an evil server which really runs the requested path as script locally(in server). Unless a student does it for research and learning stuff(yes let's assume requested path as a script and run it locally, looks very awesome).

Sometimes the virtualizer you mentioned will make it dangerous for you, considering there is a html page which has a script and parse the URL path and place the value inside some div, for example as following:
The path(URI) looks like following

http(s)://noob_made.awesome/user={name_of_the_user}

And now the script part inside the page

function a_student_did_this(){//on body load maybe!
 var user_name=...;//grab the user from url param user
 document.write('Hello '+user_name);//why?
 return true;//indeed
}

And now if you assume calling the page as following

http(s)://noob_made.awesome/user=<scRIPt>alert("XSSed!");</scriPT>

your browser(not tested) MIGHT assume the user as script and really run it, so dangerous.

First, never go that way really when you think it's possible to get XSSed, specially when it's not secure (HTTP). But indeed either HTTPS and HTTP will work the same for you in virtualize you mentioned.

Second, even if there is no any way in the world and you tired of reasearching for an alternative, so at least fix it and do it in a way to make it not XSSable, for example as following

function a_jounior_student_did_this(){//but still in worst way
 var user_name=...;//grab the user from url param user
 user_name=encode_the_string(username);//encode it first
 user_name='<!CDATA['+user_name+']]>';//not it's not parsable
 document.write('Hello '+user_name);//could be safer now
 return true;//hmm
}

As following code now act just like CDATA(*non-*character data), and browser(if the same student didn't code the browser too) supposed to just get the data inside the CDATA in plain string.


Your questions:, indeed the virtualizing sites you mentioned are that smart which they won't ever run a script themselves(they act more like a proxy for you.), Logically scripts supposed to be run by the target node
But I've seen services(it's IE emulator I think if you have search) which take the page you specified, take a picture of its render and response an image to you. but of course you cannot get any information about if it's good or bad with a rendered image
Even if the services run the script, it's almost impossible to do a serious explicite damage to the target client. But you should blame yourself if the script redirect you to download something, and worse you get and run it, or a page ask you to pay some bill(for good reason?).
The W3school you mentioned almost doesn't do anything especially for you, instead make the coding easier for you, same thing with jsfiddle, etc.
Also there is no any direct relation between link shortener and XSS. Again as you finally need to load and invoke the scripts in target client.
A link shortener just keeps the associated link with something, and for any invocation for given shorted link, user gets redirected.

Fact 0: if a page or a server is XSSable, so it's your(programmer) fault. Just take some more time for studying and do the job right. just like old school SQL-injection(which is still living in some sites!), its brother XSS could be maintained too.

Fact 1: You obviously CAN prevent XSS attack in your server if you do it right. Since it's almost possible for client too(javascript), but as I mentioned, again XSS in client won't take explicit dangerous problems unless user act really bad.

  • I'm the person who's trying to make the attack, not the one who's trying to stop it. I'm writing a script that sends XSS payloads in a virtualized zone so that the reflected XSS can still work. Sort of a proof-of-concept idea. – anonymous Apr 28 '17 at 1:02
  • As mentioned dear, that might not work since the running the script over the proxy-like never get run as they will never have a clue to run any script at all. Unless there is a bug just like SQL-injection so you could do the XSS. Again, even if you could do it, you probably won't do anything special(dangerous) – user7859067 Apr 28 '17 at 2:08
  • Your first two paragraphs sounds wrong to me. I think OP is talking about reflected XSS. Why are you talking about the server running the script? Nobody is suggesting the server should do that. A lot of the rest of your answers sounds like it doesnt really address the question. Perhaps you should try to focus it a bit more? – Anders Apr 28 '17 at 8:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.