software.dev

If any DIGGers read this, the reason I linked to this blog is because as far as I can tell, I’m the only person to ever come across this; there isn’t any other site to link to.

DIGG this article

For ADD readers, you can try out the ‘new Gmail Plus service’ here: http://www.google.com/u/gplus. Article follows below:

Yesterday I mentioned that I had discovered an exploit in a little known service from a major web company. It turns out that that exploit is in a little known service called ‘Google Public Service Search’. This service is meant for universities or other non-profit organizations to add a ‘Google’ search to their website. It differs from the other free Google site search in that it allows you to customize the header and footer of the search results page. It’s interesting to note that the code for your header and footer is actually hosted by Google, on their server.

I actually found this site when asked to add a Google search to one of the pages at work. One problem that people had with the default behavior is that while you can customize the initial search box to your heart’s consent, the search box that appears on the results page is off-limits. This was a problem, because people had asked for the radio buttons say specific things, instead of the default ‘WWW’ and ’some other domain’. I pondered how I could get around this, just out of curiosity (though I suspect this would violate the ToS ) and tried a simple Javascript alert. Sure enough, when I ‘previewed’ the page, the script was executed. Interesting…

I began to use Javascript to modify the DOM, allowing me to change the search box on the results page. Then I had another idea… I knew that my header was rendered first, then Google’s results, then the footer. I decided to encapsulate the Google search results by placing them in a DIV tag, then closed the DIV tag in the bottom. Right after that, in the footer, I used the Javascript ‘document.getElementById(divID).innerHTML’ property, and essentially, hid all of Google’s search results. I realized that I had created a blank slate, hosted at a Google.com address.

Though this was certainly impressive to me, it would not get the attention of anyone. Most people I know, when I show them I can execute a Javascript alert say “So?”. I decided to up the ante a bit and create a new ‘Google service’, modelled heavily after Gmail, but offering new features. After the Javascript in the footer, I added all of the HTML I needed to render a completely new page, of my choosing. I chose to use a modified version of the Google homepage. For the login form, I directed the user’s input to my server, which simply alerts them that they have been ’scammed’, but reassures them that no information was stolen — I just echo the user’s username and password that they entered.

Similar ‘phishing’ sites could be set up at ANY URL. What makes this type of exploit so insidious is that most people would consider the URL to be safe: http://www.google.com/u/gplus. While Google has suffered from similar attacks in the past, most of them have had suspicious URLs, at least to the advanced user. Using the exploit in this service, a malicious attacker could launch phishing sites that even advanced users could fall for.

Just as a sidenote, the URL of this service always has the form: http://www.google.com/u/something. ‘/something’ can really be anything you want (alphanumeric only, I believe).

The day after I found the exploit, I emailed security@google.com and got a response saying they would follow up with me later. They immediately took down the login page for the service as you can see here: https://services.google.com/publicservice/login. The site has been down since then.

My initial idea was that Google could simply remove script from the headers and footers; however, as my coworker pointed out, you could achieve a similar effect using the CSS ‘hidden’ (I think?) property on the DIV, and not use Javascript at all. It should be interesting to see how Google fixes this issue.

Yesterday I talked a little bit about SOME of the stuff I do at Mediaworks; I’d like to continue that with some of the things that I’ve learned there.

One thing that I have becoming increasingly aware of is security in websites (or lack thereof). It’s kind of funny — whenever I visit a new website, one of my first thoughts is how I could break it, how I could ‘hijack’ the page. One might think that these are malicious things, used to hurt users of the site, but on the contrary, understanding exploits is key to protecting your own applications against outside attacks.

What actually sparked my interest in the security of websites was a nice Wikipedia article on XSS attacks. I had, of course, heard of XSS attacks before, but I didn’t really know what they were until I read the article. Immediately after reading Wikipedia, I did a little more research and found out a little bit about how such attacks are performed, and what can be accomplished. I took some of the ideas and techniques I read about, and applied them to the site I was currently working on at work. Sure enough, I was able to inject Javascript that was executed when the page was viewed. As a general rule, if, at any point on your site, a user could cause an alert box to appear through Javascript, your webpage is probably at risk.

One of the most common problems I’ve seen is with search fields. Enter a search of random characters, and see what happens. All too often, a website will say something like “Search query ‘fkljsdhkfj’ cannot be found”. My first thought when I see that is “Alright, let’s see what happens if I enter Javascript in that search field.” Surprisingly often, the Javascript will execute. Why is this a problem? Let’s say I send someone a link to the site (possibly a trusted site like eBay or Amazon), directly to the search query I specify (e.g., http://www.example.com?search=eviljavascript). The Javascript can execute, and do all kinds of things (taking cookie authentication information for instance, or my personal favorite, ‘hijacking the DOM’).

The attack described above is a pretty tame one. The user still has to click a URL to have the source execute. More malicious attacks enter script into a field that is saved to a database and displayed to other users at another time. In this fashion, potentially thousands of users can have the attackers script executed on their machines. A general example of this would be some sort of XSS vulnerability in a popular bulletin board program. If you were able to inject javascript into a popular post, hundreds or thousands of users that view the post would be effected.

The bottom line is that you have to assume the user is an attacker, and plan accordingly. All data should be sanitized. Nothing should ever be displayed to the user, even if only the user who entered it will see it, without being protected. Use functions to strip HTML or at the very least, Javascript from user input. Validate all user input — if you expect a 10 digit number, verify that that’s what you got. Do not rely on ’security’ like setting a max-size on form text fields. These sorts of protections are enforced client side, and can be removed.
Learning how would-be attackers think, and what they actually do, is one way to protect against these types of attacks. In a few days, I’ll talk a little bit about how I discovered a clever exploit in a service provided by a major web company.