I've been working with some client side flash developers recently and we came across an unusual error that was being thrown in a Flex application when we were sending a webservice request to a Coldfusion server.

The error was "Security error accessing URL". I thought I'd overcome this a long time ago by using the cross-domain.xml file to allow server access to services.

It appears that there is a security issue with Flash 9 that requires the following line to be added to the CrossDomain.xml file:

I'm guessing that it is enabling access for SOAP requests to any remote services on that server.

You could use a 404 ColdFusion template to handle missing templates, or the onmissingtemplate Application CFC function. Luckily I have a client with half a dozen sites all on the same server, with nothing else on it, so it makes more sense to do this in Internet Information Services.

404 templates are a handy way of masking any site errors or missing templates. Not only are they a cosmetic fix to nasty display errors but they can also seriously help your server security.

[More]

I'm based in the UK, and I use the Vodafone mobile provider. Recently they text everyone stating that they were switching to online billing, and that you wouldn't be receiving a monthly paper bill. I am fine with this, less paper in the postal system is a good thing. This Blog post is about how the online application they have built doesn't work.

If you go to http://online.vodafone.co.uk/ and try and login the SSL certificate is invalid. (Security error: (Error code: ssl_error_bad_cert_domain)).

There has been a lot of coverage in the press recently about how to check for valid SSL certificates, and what the padlock icon means, so it is a bit of a basic error to make. Customers are looking for reassurance when using online applications, and being shown error messages like the one in the screenshot above does not build confidence. The next issue that I faced was that the destination for my registration and logging in didn't actually work!

When you are actively promoting something, and in fact removing the other options (paper billing is cancelled by default) you must make sure that it WORKS. I can appreciate that sometimes you might get intermittant faults, but I got a text telling me to go check my bill three days ago, and it has not worked since.

Please fix it, otherwise I'm going back to killing trees.

A popular daytime television show in the UK has recently broadcast an article on Internet security and Internet dating. With Online Dating being an industry I worked in for a brief period this was quite relevant to me.

http://www.itv.com/lifestyle/thismorning/more/internetdatingdisasters/

The main aim of the Sally Cornock's site is to warn of 'love rats' and suspicious profiles online. It appears that she was stung by a serial dater online and has done something about it.

It highlights the dilemma of free to join, fixed cost membership sites quite well though. Most dating sites are free to join. They provide very little functionality, and no interaction at all with other members UNLESS you upgrade your account and pay a fee. When you understand this it makes policing this near on impossible.

Sally Cornock has raised the issue of potentially having a governing body to perform validation on members as they join, so that you know someone is who they say they are. This would discourage a massive percentage of the market, as signing up for free by providing only one or two fields of data is simple. But passing an online verification is an extra level of hassle to the "casual shopper", which most people are. When you look at the statistics only a tiny number of signups ever convert to full membership.

It nicely highlights some of the less technical aspects of web usage, click through below to read more:

http://www.crimestoppers-uk.org/crime-prevention/helping-prevent-crime/personal-safety/online-dating-safety

http://www.e-victims.org/

http://www.suzylamplugh.org/personal-safety/personal-safety-tips/safety-on-the-internet/

http://www.victimsupport.org.uk/help%20for%20victims/Get%20information%20victims/Information%20about%20specific%20crimes/Cyber%20crime

One of the more recent additions to my Coldfusion frameworks is masking the more ugly URL's using Isapi rewrite. In this article I'll be using Helicon's Isapi ReWrite, but Apache re write works in much the same way.

Usually in your Coldfusion frameworks, most other technologies as well, you are passing around a variable or two to control the page content, and more often than not it is in the url. It never looks particularly clean if your URL has a long name value query string behind it, like this:

Cosmetic reasons

So for two reasons URL rewriting seems like a good idea.

Firstly to mask those ugly URLS with a url rewriter. On a basic level this will re write specified request to the URL you tell it to, taking your ugly list of name value pairs and changing it into a user friend URL. If you are pitching this to a client this looks a lot more professional.

Security reasons

Secondly there is an added security benefit here. The URL gives a lot away about a website, like what the code base is, and is potentially a window on the internal workings of a website. Take a normal FuseBox application for example. The normal URL might be:

From here it is very easy to start messing around with the controller names, trying to dig out an 'admin' controller, or other common function controller. Similarly adding values to pages where it is obvious a Query has been fired is an easy way of testing of the developer is using 'cfQueryParam', with potentially disastrous results.

Along the same lines it is quite simple to inject form values into the URL (like this http://www.mccran.co.uk/index.cfm/2009/7/30/Cross-site-Script-hacking-using-the-GET-method). By masking the URL and the values you make it considerably more difficult to do this, after all if you can see or get to the URL, how can you fool around with it?

So far I am implementing a rewrite script that will rewrite URLs into friendly strings, here is a modified version of the .htaccess file I'm using.

This code starts off by turning the rewriteEngine on, then setting the rewriteBase, this is typically your webroot, or the root of the site the file is for. Then it rewrites any URL params to the URL string.

The main part of the code is where we set individual rewriteRule's for each URL. The first example (home) looks for any URL requests to the 'home' string, and re writes this to the URL in the regular expression (index.cfm?go=controller.home). Pretty straight forward really.

There is a lot more you can do with this, and hopefully I'll get to explore rewriting in more depth in the future.

I've dealt with Cross Site scripting (XSS) attacks before ( http://www.mccran.co.uk/index.cfm/2009/4/6/Cross-Site-scripting-hack-test-form), so I'm familiar with the principles involved. In this example there is a subtle difference.

In the example above the vulnerability was created by POSTING a text string through the form action. In this example we will examine a similar vulnerability using GET. IE we will simply pass the attacking string through the url of the form, setting the form field value in the traditional 'url?variable=N' way.

To demonstrate this create a simple form:

Call your form in a browser. Now append on the end of that url the text string below.

?attributes.formValue==>"><%2Ftitle><%2Fiframe><%2Fscript><%2Fform><%2Ftd><%2Ftr>
<%2FIfRamE>

Reading through the string you'll notice that it is an Iframe constructor that is calling a url, in this case www.Google.com.

As the url is setting the value of 'attributes.formValue' this will be inserted into the form on the submit action. We are not posting it, so it will not be picked up by any custom POST action code.

One interesting point to mention here is that testing this in IE 8, it will actually be blocked by default, as it has detected that scripts are running over different domains.

So if you are in the habit of writing POST detection scripts, make sure you handle any other submissions as well!

I am a big fan of fusebox, I like the way it handles inheritance, and I love the fact that it instinctively lends itself to a modular approach.

Part of the strength in using fusebox is in knowing exactly when each of the framework fuse actions run, and just what sort of functionality you can embed in them. In this case I'm using the "Pre fuse Action" to perform a basic security validation on any fuseactions in that circuit.

Above is a blank prefuseaction, insert any code you want to perform on any of the other fuseactions in that circuit here. Note that it runs before the circuit action.

A basic session validation script could be something like:

In the code above I am checking for a valid session variables, and if it is not there sets an error message and redirects to the homepage.

This is a pretty basic "catch all - are you logged in?" type query, but if you have an administration circuit then it provides good basic fuseaction protection. I've extended it out one step further by creating a cfc call to this code which just returns true/false. Something like this:

I am currently extending this further with more robust security, and user roles and groups.