Hard at work on my first Flash game

October 10th, 2006

A few days ago on Digg, I saw another Flash game that inspired me to try one myself.  It wasn’t super impressive, yet it had a certain fun quality that attracted me to it.  I’m talking about the ‘Gladiator’ Flash game that you can try here:

 http://www.gamefudge.com/Swords-and-Sandals

I decided I was going to make a similar game, though I’m more of a fan of ‘magical’ games, so I opted to have dueling wizards as the central theme of my game.  The game ‘flow’ in my game (if it goes as planned) will be very similar.  Basically, you’ll fight a series of battles, winning gold and experience if you win, that will give you access to new weapons, armor, spells, etc…  I’m a sucker for games with items and power-ups.

The kicker is that you will cast spells using a ‘Lost Magic’ interface; that is, while you’re running around with the WASD keys trying to blast the other wizard, you can hit Shift  to bring up a ‘casting rune’ where you trace out the shape of the spell you want to cast.  If you’re successful, the spell is ‘activated’ and clicking the mouse button will fire the spell.  Currently, I have about 20-30 spells planned, spread out across six schools of magic: fire, arcane, temporal (space/time related), disruption (kind of a twist; spells that burn mana, reflect spells, etc… ), light, and shadow.  The magic is laid out in a ‘tech-tree’ of sorts, so some spells have prerequisites.  It should be pretty cool once it’s done (assuming I finish :) )

I’ll post some pictures soon because right now, it’s pretty hard to describe the gestures used for the spells in the game so far (there are 3).  You can see what it looks like currently, at any time, at http://www.ericfarraro.com/flash.  It’s a WIP, obviously.  WASD is movement, and you can see the ‘casting rune’ by hitting Shift.

Check back soon for screenshots and more instructions!

Decided to write another game

October 4th, 2006

Now the fun part — deciding what type of game to make :)   I’ve been doing some thinking about what kinds of games I’d like to see [more of] and here’s what I came up with:

- RPG styled like Megaman: Battle Network.  I didn’t really like the feel of MM:BN, but I think it has a lot of potential.  It takes a little more twitch skill than, say, an FF style RPG.  I also absolutely love the idea of ‘cards’.  I never played any TCG seriously because they’re too expensive, but I like the idea of customizing a ‘deck’ and drawing abilities from that deck in battle.  There was a pretty cool Gamecube game like this.

- ‘Reactive RPG’, ala Mario RPG.  Again for similar reasons as above.  I like the idea of using a little twitch skill every now and then to increase / avoid damage.

- I recently played a cool little Flash game called ‘Nevermore’, which apparently, is like Hapland (I didn’t really think so, but they both have cool art styles).  In any case, Nevermore is basically a ‘puzzle platformer’.  It has a kind of mysterious, surreal feel to it that I kind of like, almost like Myst.  I’d like to see a game like Nevermore, but longer, and with more point and click interactions instead of straight platform jumping.

- A turn-based strategy game where, when units meet, they are controlled in a real-time battle.  You probably notice a trend here.  There was a game like this on PS called ‘Unholy Wars’; it was a turn-base strategy game with a really simple resource model, and maybe… 8-10 different units with different abilities.  You could attack adjacent units, entering a battlefield where each player controlled their unit, and had four different abilities to attack with.  This was presented in a third person view.

- Stylus (mouse drawing) game.  The Wii and NDS have really got me thinking about ‘drawing’ games.  It’s certainly not as fun to draw with a mouse, but I think there is a lot of untapped potential here.  More on this later.

- Puzzle platformer, centered on a mage-like character.  Possible ‘color’ theme, or more specifically, ‘ elemental’ magic.  Maybe you could pick the type of mage you wanted, or would have to use several types of mages to solve puzzles… not sure yet.

- Generic Flash ’survival’ game.  I like the idea of a mage character here as well… learn spells, get gold, buy defenses, keep playing until dead.  I’d like to see a game like this with a bit more strategic depth than is normally themed… more options.

- Fantasy-themed Worms game… specifically with base-building.  One of my favorite ‘house-rules’ ways to play Worms was to set the amount of girders allowed to infinite, with which my friend and I would build huge fortresses and put our Worms inside before we started the match.  We also built ’sky bases’ (girders in the air in the shape of say, an airship) and boats (girders in the water); the other person had to siege the base.  I think a game that actually included a mode like this would be a ton of fun to play.

- Some other union of genres that doesn’t really fit.  I played a side-scrolling RTS awhile back (I forget the name, but it was kind of Steam-punkish).

I’ll continue this later, but I think I have an idea I might go with… currently thinking of a ‘Gladiator’ type game where you control a mage from a top-down view to blast opponents with magic.  Specifically, drawing runes on the screen ala Lost Magic, but hopefully implemented better.  Several schools of magic should make it interesting.  We’ll see!

Some simple XSS Attacks by Example

September 20th, 2006

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 :)

Working on another article about XSS attacks

September 20th, 2006

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.

After the ‘Google Search’ exploit

September 17th, 2006

I was actually pretty surprised how fast the news propagated through the internet. After posting the details of the exploit on Digg at about 8pm tonight, it drifted off into obscurity. The following morning however, apparently a bunch of people some how found the article, because it was already on the frontpage with 300 Diggs. Several hours later, the details were ALL over — Slashdot, Newsforge, Digg — all the big sites had discussions about the exploit. In some cases, people were confused and I did my best to link back to the article so people knew what was going on.

It wasn’t clear to everyone from my previous article, but Google knew of the exploit several weeks ago and they immediately shutdown the login page for the service. While existing pages were left up, they did the right thing immediately after I reported to them the details of the bug by making sure no one could actually exploit it.

While I believe I took appropriate action by first disclosing the exploit to Google and waiting until the service was closed for several weeks, there were a few people concerned with the disclosure. It is in my opinion that leaving the exploit quiet is a far worse scenario — while I don’t know of any other sites like this in existence, I think a headline of this nature is FAR preferable to a headline that says ‘Thousands give credit card numbers in Google Phising exploit’. Thousands of people were able to learn about what the whole ‘http://www.google.com/u/’ style URL meant, and will not fall for this exploit if it exists in the wild somewhere.

As best I can tell, I served about 245,000 requests and served 20 GB of pictures.  I’m happy to say that my host, Dreamhost, prevented the site from going down during the Digg/Slashdot/etc… rush!

Thanks to everyone who helped spread the word and left comments. Keep and eye on this site as well — I definitely love looking for these kinds of things :)

You can read the official report by Google here:

http://googlewebmastercentral.blogspot.com/2006/09/for-those-wondering-about-public.html

Phising Exploit Discovered in ‘Google Public Search Service’

September 14th, 2006

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.

Security in Websites

September 13th, 2006

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.

First Post

September 12th, 2006

I figured that to break in the new site (I hate the word blog), I should include a little bit about myself and what I do. Note: This site is not a site about what I ate this morning, or recounting every detail of my life. This site will focus specifically on software / web-development type stuff, and the issues surrounding it.
For starters, I work at a place on campus at UC Davis called Mediaworks. Mediaworks ( http://mediaworks.ucdavis.edu) does a variety of things — not just programming — for organizations on campus. Some of the services Mediaworks provides are custom animation / graphics, photography, consulting services, and programming, among other things. Of course, as Computer Science Engineering Science, I am part of the Programming Group.

Recently there’s been a big push to make sure all of the IET (the organization of which Mediaworks is one department) websites are HTML / 508 Compliant. Testing said websites and fixing the ones that are not compliant is not the most exciting thing, but it actually turned out to be extremely educational. If you’re like me and first learned HTML back in the Geocities / Angelfire days, chances are you’re in for a rude awakening. A lot of the stuff you used to do — using underline tags, using center tags, using tables for layout — are all either considered bad practices or are deprecated. For instance, I was pretty confused when the w3c validator was complaining about my &ltu&gt tags. Isn’t that the tag for underline? Sure it works, but the tag has been deprecated. Instead, you’re supposed to use the &ltins&gt tag, which, apparently, stands for ‘insert’ (as in, you inserted text; there is a related ‘del’ tag for strikethrough). In any case, there are a lot of little nuances like this that you never really learn until you have to build a site that requires compliance.

508 Compliance is another beast altogether, and has to do with making your site available to the masses, specifically disabled persons. I don’t know a whole lot about the details, but apparently sites that get government money are supposed to make sure that their sites are ‘508 Compliant’ which means that they meet certain requirements set by the ADA. There are things in 508 such as using ‘alt’ tags for images, not using blinking text / marquees (LOL, 1990) , etc… A lot of web developers don’t pay attention to such things, but it can become a pretty big deal.

I have lots of other stuff to talk about, in terms of what I do at Mediaworks but I’ll save that for tomorrow.