Check out my latest dev project

Soldato
Joined
12 Jan 2004
Posts
6,824
Location
Londinium
http://www.fsa.gov.uk/pages/Doing/Regulated/Fees/calculator/index.shtml

Click on one of the two links at the bottom of the page to go to the app.

It has just gone live today and thats unbelievable considering I was handed a ****-poor func spec at the beginning of october. I was the sole dev on the project and was working with a project manager, tester and a business team member.

The project was basically to make FSA fees more transparent by providing an online calculator for financial firms to calculate their past and future fees, and understand how they are calculated.

The app uses asp and vbscript, (lots of) javascript with Ajax style server requests and xml for data (no database).

The project was a nightmare as no business analysis had been started by october and it was a public commitment to deliver it by the 1st Feb. I had to do all of the analysis and write a new func spec, as well as the app spec.

It was crazy, but I cant believe we met the deadline! The FSA is currently outsourcing most of its project (it is plnning to outsource the entire dev team in the next few months) so we got to stick it to them by delivering a project on time and at a fraction of the cost!

Now if you excuse me, I think I am going to hurl....
 
I've done some checking and I cant see how you can inject any malicious code into the app?

Are you willing to go into more details or were you just trolling?
 
dont be so naive (nero) give him a chance to respond.

i am not so competent tried going over your source code but obv didnt look at right places :p.

although injection exploit usually refers to something someone can do with a form and in your case i can only see one form Search form... that i take it gets the results from a database? (i may be wrong, probably am... :o)
 
Freak_boy said:
dont be so naive (nero) give him a chance to respond.
He is, that's why he asked for more info :p

Looks like a neat app there nero120 :)

I have a rule: Never do any work for public bodies and expect even the remotest amount of organisation :(
 
roboffer said:
Cant say Im overly impressed, but it is a fee calculator! :D

Nice clean use of Ajax in a way that actually improves the usability of the site, that's the important bit.

I didn't test, but does it degrade gracefully?
 
Thanks guys! Sorry for being direct but to say that there is a massive security hole in the app and not give any details I thought was pretty cruel!

Ive checked it again but cannot see how you could inject any code into the app as both querystring and form variables are filtered for tag and code characters. We also have a company called pentest penetration test all the apps we produced and they found no exploits, so if there is one they owe us a refund! Although maybe you were pulling my leg? ;)

Since the app relies heavily on javascript, I had to put in a lot of checks to make sure the app is only displayed if javascript is enabled, all the objects are supported and the attached js file gets downloaded. Thats the area I was most worried about because of the short testing time, I bet there are a few cases that slip through the net.

It should degrade quite nicely on other browsers, but due to the timescales, there might have been a few more obscure browsers that don't degrade well. Not bad for a rush job though I think! ;)
 
Moredhel said:
Requires javascript and is therefore useless, either write a non javascript alternative or don't bother at all.
Oh come off it - so many webapps use JS these days. I haven't examined in detail but it looks like the kind of setup where some client-side processing is necessary.
 
Moredhel said:
Requires javascript and is therefore useless, either write a non javascript alternative or don't bother at all.

That's hilarious! QUICK! Someone phone google and tell them their web apps are useless cos they require javascript! Crap. I wish you'd have enlightened me before we started this project!
 
Nothing I've used of Google's requires javascript. Even google maps and gmail have non javascript alternatives.

People were just starting to get the idea of usable failover and accessibility into their heads, when suddenly google used XMLHttpRequest() effectively, despite it being around for years, suddenly it was given all kinds of buzz words (Ajax etc) and made trendy. Now everyone thinks they can throw the lessons of accessibility out the window again, of course that's not to say you must hold development back, by all means use the latest and greatest shiny technology. But consider the options for people who don't have access to that same technology. Nothing REQUIRES client side proccessing, admittedly it's a lot easier to code doing it that way, which is why people are using it more and more often, but ease for the programmer is no excuse for a lack of accessible options, such new technologies should be used on top of existing methodologies, not instead of them.

Not to mention this site in particular is a govornment site, I'd hate to think aobut the DDA implications of it only working for javascript enabled browsers, and it's lack of even tenuous compliancy to any accessibility standards. I've worked on govornment sites myself (Albeit in education, where we had to take into account the Special Education Needs and Dissabilities Act as well as the Dissabilities Discrimination Act), and know that the laws and regulations in that regard are quite stringent and a bit of a minefield.
 
Last edited:
Moredhel said:
Nothing I've used of Google's requires javascript. Even google maps and gmail have non javascript alternatives.

People were just starting to get the idea of usable failover and accessibility into their heads, when suddenly google used XMLHttpRequest() effectively, despite it being around for years, suddenly it was given all kinds of buzz words (Ajax etc) and made trendy. Now everyone thinks they can throw the lessons of accessibility out the window again, of course that's not to say you must hold development back, by all means use the latest and greatest shiny technology. But consider the options for people who don't have access to that same technology. Nothing REQUIRES client side proccessing, admittedly it's a lot easier to code doing it that way, which is why people are using it more and more often, but ease for the programmer is no excuse for a lack of accessible options, such new technologies should be used on top of existing methodologies, not instead of them.

Not to mention this site in particular is a govornment site, I'd hate to think aobut the DDA implications of it only working for javascript enabled browsers, and it's lack of even tenuous compliancy to any accessibility standards. I've worked on govornment sites myself (Albeit in education, where we had to take into account the Special Education Needs and Dissabilities Act as well as the Dissabilities Discrimination Act), and know that the laws and regulations in that regard are quite stringent and a bit of a minefield.

I see your point but this site is a service for financial firms, if their browser can't handle it or they are blind, deaf, dumb, etc they can always ring the fsa and get them to send them a printout of their fee calculation (which wasnt available before this site went live). Compromises were made and some may not be able to see the site. JavaScript was used to actually make it much simpler (and even possible) for the firms to calculate their fees correctly. The XML HTTP object is not required, if the client browser does not support it then it simply uses standard HTML form submits.

But I disagree with you about how javascript makes it easier for the coder, it actually makes it more difficult. The use javascript allowed the page to dynamically update to the users inputs. During our app pilot with a number of firms, many of them cited this as one of the best features. No need to keep going to seperate pages and going back and forth to change options - do it all on one page, and it works pretty elegantly considering the amount of content on there.

I dont think there was a right or wrong approach to do this. Yes, I could have gone the fully accessible route but given the timescales, budget, non-critical nature and user base, this approach seemed the right one. Once we receive a fair amount of feedback we will know whether we took the right approach or not. I dont see the point in spending loads of time and money making a site accessible to everyone with every browser and every disability when the likelyhood of them ever going there is slim to none.
 
Back
Top Bottom