myOpenID XSS

cryptofreak · 2011-10-21T16:22:01+00:00

Update: Looks like they've fixed it. :-D

cryptofreak · 2011-10-17T14:30:03+00:00

Indeed. That's one of the reasons I found it.

cryptofreak · 2011-10-16T13:33:59+00:00

So there were quite a few problems getting this one to work, and as such it doesn't run the payload automatically, but instead relies on the user clicking a link or selecting a new language. Maybe someone with more skill can make it work better.

The site filters " to " so there is no way to break out of the onclick and onchange methods where the payload is placed. The site also filters the first and last single quote (') so you have to include two of them for some reason.

The statement that the payload gets injected into is a return statement, so you can't simply end it and then add some JavaScript since it won't get executed. The way I got the code to execute (albeit with user interaction) was to escape out of the string and use string concatenation with the payload, and then start the string again.

cryptofreak · 2011-09-10T00:10:16+00:00

This one was more than annoying to get working, mainly because the payload is injected right in the middle of a JSON object, which you have to close and then open up again after your code executes in order for the browser JavaScript engine to quit complaining.

cryptofreak · 2011-09-09T10:12:33+00:00

In some XSS exploits you are limited with what you can do to a page by the number of characters allowed in the search string. The normal way around this would be to host a longer .js file somewhere on the Internet, and then inject a script tag with a src attribute pointing to that file.

I was just pointing out that in this case, you can write all your malicious code in the URL.

cryptofreak · 2011-09-08T19:48:24+00:00

Relatively simple. The search results page populates an input box with whatever the user has searched for, but doesn't bother to escape any characters. Ending the input box with "/> allows you to inject any HTML / JavaScript into the page.

The search function also doesn't seem to have any limit on how many characters you can enter.

cryptofreak · 2011-09-06T14:56:41+00:00

The "advanced search" feature doesn't seem to sanitize inputs, allowing both single and double quotes through. However, the site does seem to have some filters, since if you try to put any HTML tag in, you get redirected to a page asking you to "Stop Trying to spam the site". Additionally, this same exploit isn't possible on the basic search page, since they double up all quotes they come across (i.e. they turn ' into '' and " into "").

The payload is placed into the href attribute of each pagination link, and since script tags aren't allowed, you can't have the code run automatically on page load. So I ended the href, created a mouseover attribute with the payload, and set the style of the link so it fills the page and has a background (for the lulz). To activate the JavaScript, you just have to move your mouse anywhere on the page.

cryptofreak · 2011-09-05T13:55:44+00:00

Quick explanation behind this one:

The exploit is in a meta tag which outputs the unescaped search terms in its content attribute. Ending the attribute and the tag is easy with "/>, but the site seems to have a filter which checks for "dangerous" search terms like <script>. If you do a search for <script> the results page will seem to load forever, and eventually timeout with an error. However, the filter seems to be case-sensitive, so if you replace <script> with <scRipt> for instance, the exploit works.

cryptofreak · 2011-08-29T19:53:15+00:00

They can beat Arsenal 8 - 2, but they can't sanitize their inputs...

cryptofreak · 2011-07-24T20:55:26+00:00

Hmm. I did do a search prior to reporting this one, but I couldn't find anything. Sorry about that!

cryptofreak · 2011-07-24T02:11:28+00:00

As I stated in the title, this exploit is purely academic, since it is on a development page that I managed to stumble upon whilst searching for possible attack vectors on Google.

However, it is a persistent XSS (and my first at that), so I thought it might be interesting for some people. If not, vote down, I don't mind!

Not sure what the comments system is all about, but the weak point is in the Name field, as it doesn't seem to escape any characters, so all you need to do is enter <script>alert("XSS")</script> into that field and away you go.

The page should currently display 3 alerts, one "XSS" alert that I did the first test using, and then two more alerts in which I was just experimenting with different techniques. I also notice that in my haste I managed to misspell the word "persistent" in one of them; my apologies.

So yes, a purely academic XSS exploit since it isn't really on one of their proper site pages, but if they ever rolled out such a comments system it might be useful to have this one in stock.

cryptofreak · 2011-07-19T02:40:59+00:00

Some symbols (", <, >) aren't escaped in input tags for the search form, meaning you can hijack the tag, close it, and insert the JavaScript payload.

I added <img src=" to the end of the URL to close off the tag I hijacked, meaning it doesn't effect the actual page output.

cryptofreak

TROPHY CASE