software.dev

Digg this article

I thought that today I’d write a bit about how XSS attacks can be performed by setting up a sample site where users could try some of the exploits discussed, to better learn how to protect their own sites. I am by no means an expert, but it seems that the vast majority of web developers are painly unaware of XSS exploits to any degree, leaving many sites vulnerable.

The page I’ve set up is actually based off of another Google service. This one is free for everyone (not just public institutions) but only allows you to add an image at the top. I probed this site for vulnerabilities but am happy to say that it appears to be solid.

For this ‘lesson’ of sorts, you’ll need to use the Firefox ‘Web Developer’ Add-on. Click here to download this add-on from https://addons.mozilla.org/firefox/60/. This add-on adds a small bar to the top of your Firefox browser that will allow you to manipulate webpages that you are currently viewing in real-time. You can edit the CSS and watch what happens, highlight different elements on the page, and tons more. What we’re interested in is manipulating form fields.

One approach developers might use to protect their site from XSS attacks is by using ‘client-side’ protections. I didn’t actually know this until recently, but many limitations you put on forms can actually be removed by the user.

Take a look at the fake service I’ve added. (You’ll probably want to open it up in another browser window or tab so that you can follow along.) Basically, the service will allow you to “customize” a page hosted on my server (I don’t actually host any customizations, in this case), much like Google’s other search service. The form will allow you to specify an image, its orientation, and its width. We’ll look at how vulnerable this application is, and what we can do to fix it.

First, look at the ‘Image’ text field. Your first thought when seeing a text field like this is first of all, if the results that you type in the field will be displayed back to you at some point and secondly, if HTML characters (particularly > and <) are properly escaped. In this case, you will note that the text you enter for ‘Image’ is directly added to to the <img> tag on the preview page, and that the > and < characters are not properly escaped. Cut and paste the following into the ‘Image’ field and click Submit.

See how it works? We provide the image that is expected, end the <img> tag ourself, and then add our script. The developer, trusting of the users, assume that only valid images will be used. Woops.

Ignore any ‘width’ or other text you see on the screen. What’s important is that you should see a Javascript alert box (assuming you have Javascript enabled). Many people who aren’t familiar with XSS attacks might be thinking “so what?”. If you can cause an alert box to appear, you can pretty much do what you want. Steal user cookies, modify the DOM, launch phishing attacks, it’s all fair game.

Next we’ll use the Firefox Web-Developer Add-on to attack the Select box on the page. Select boxes give a false sense of security — it makes it seem like the user can only be pick from certain ’safe’ options. Not true! The web-developer add-on allows you to turn any select element on the page into a text box. Interesting huh? Convert the <select> box to a text field, then copy and paste the following code in the orientation field:

Well, look at that. We thought we were limiting a users choices, but they can still enter whatever they want. The moral of this story, as said before, is you must validate EVERYTHING including things that are supposed to be trusted. In this case, one possible way to protect this orientation field would to have a few lines of code to make sure that the orientation is in a list that you predetermine (e.g., left and center). If the value of the field in the POST is not one of the values you specified as valid, omit it completely.

Finally, we’ll look at how you can similarly ignore maximum length constraints on text fields in order to exploit them more easily. The Web Developer add-on will help us here again. Click the ‘Forms’ label, then go down to ‘Remove Maximum Lengths’. This probably isn’t particularly common, but if a naive web developer thought that by limiting a field size, they did not leave enough space for you to launch any sort of attack, they made a big mistake as you can see! With the maximum limit removed, enter the following into the width field:

In summary, we saw the following vulnerabilities:

• Image field: No real protection at all; developer assumes user will input a valid image name. Could be fixed by some how checking that the image actually resolves to be an image. Another possibility would be to use a regular expression technique to make sure the path to the image makes sense. No matter the solution, using a function to properly escape HTML characters is a must. In PHP, you can use the function ‘htmlentities. (PHP.net). There are also many good PHP frameworks to help you ‘Sanitize’ your data — I like CakePHP. (cakephp.org)
• The Orientation field: A select box makes it seem like we have nothing to worry about. The user can only choose from specific options. As we saw, you have to assume anything can come out of that box. A good solution would be to predefine a small number of options, and check to make sure that what you receive from the POST matches one of your predefined variables exactly. No other checking or sanitation should be required.
• The Width field: Similar to the <select> box; you can’t rely on client side protections such as maximum field lengths to protect the integrity of your data. The value of ‘width’ should be checked server side — first, it should be 4 characters or less, and should be numeric. If anything else is received from POST, it should be discarded.

As you can see from the above examples, there are many ways in which a site can be vulnerable to XSS attacks. Looking for vulnerabilities is certainly not hard; it simply requires a certain mindset. You should constantly be thinking about how you can ‘break’ a website, force it into an unspecified state, etc… If you do find something big, make sure to report it responsibly to the owners of the site before doing anything crazy

The article I’m working on now is meant to inform other web designers about some of the things that I’ve learned about XSS attacks, and protecting your site against them — by example. I’ve put together a small, sample site where you can ‘practice’ XSS attacks, and learn about how to identify and fix XSS exploits. Look for it in a day or two.

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.