With the advent of OS 3.0 being released imminently, I thought it’s time I highlighted a particular bugbear of mine on the iPhone - well not on the phone itself, but on websites designed for it.

As I spend a fair amount of personal time on the train, I spend it surfing the internet -often following useful links from this site, digg and slashdot.   However around once/twice a week I find that the link doesn’t take me to the linked article where I want to go - but to an iPhone specfic website “thats more optimised for a mobile handset”.

A lot of these sites don’t even have a mode to offer to “take me back to the regular browsing experience” - although some thankfully do.      Annoyingly those that do have the option don’t you generally to the original article - but it does at least present a way for the normal website to be viewed.

The only way around this appears to be to install an alternate browser sending another user-agent to the website in question - but should we really have to resort to the appstore to fix this?

So I am asking all website designers nicely.   Yes you can create an iphone version of the site…  but please don’t force it upon us…     Some of have iphones for the “real web experience” but on the move, not a “for handset” experience.

Please comment with your thoughts and a list of sites that appear to force this on you if you feel like naming/shaming these annoying sites…

My personal bugbear being a science fiction fan is scifi.com - which on my last visit forced a version of the site that you couldn’t get out of on the handset.

Looks like another PC magazine is potentially set to close doors to printed text and become online-only.

Background:

Part of my current role (in fact the main piece now) is Web Application Security Testing. Which means I get paid to hack around with corporate and non corporate web apps (ie, Apps we buy vs app’s we build).

Web application bugs although currently looked by some to not be serious are gathering in momentum and becoming more common - only recently a lot of websites were compromised by Chinese hackers using SQL injection. XSS in particular can also be used to great effect in just one example of many to send a session cookie off site to hacker base - and thus giving them access to the logged in users data.

Over the past year I’ve tested around 40 apps in total, some complex, some simple. Major security defects have been found in all apart from one application during this time.
The fact is, regardless of the language an Web application is written in, it typically is vulnerable to one of the below 3 in my findings.

• SQL Injection
• Cross Site Scripting (XSS)
• Privilege Escalation

The above is not a full list, but its the basics and believe it or not even in 2008 SQL Injection is still the most common flaw we find! For a better view of what you should be doing to stop this, OWASP is a good website to start with.

Of these bugs SQL Injection and Cross site scripting are usually the easier to spot, and also to get developers to fix - and it is surprisingly easy to fix these first two by not trusting user input, and filtering it before it hits database in case of SQL injection, or is formatted back to users ( in case of XSS both preferably). There are good tools to test both in a semi-automated way in the form of a firefox extension here - we use this in combination with commercial tools to test for this in combination with manual testing (for SQL injection typically) with database traces running. Manual testing is far easier if you can see the queries being executed on the database (though you can’t do this in a black-box test where you have no access to remote database obviously.).

Privilege escalation however can be more tricky to both test and find in my experience at least. Its almost always a manual test - as the commerical and free tools do not do as good as job at finding this as they do the XSS/SQL bugs. In my testing I have found that some developers however still seem to think that simply hiding menu’s from a lesser priviledged user is a way to secure their application (though thankfully this is a minority!)..

One application I tested recently did at least get this right, but used a very predictable bash64 encoding to hash message ID’s within the messaging in the app (where critical data was being passed over this) They wrongly assumed the algorithm they devised was strong enough to protect themselves….. as it didn’t look predictable to the developers (who had no experience of that kind of work). The problem was they had negected to do a check when the page was loaded as to whether user had rights to read that message. That simple fix was enough to secure the app…

Where I work at least, we finally are integrating Web security at project design and initial build stages - so finally security is being taken seriously at day one (This is reducing the critical bugs found at testing) - Is this happening elsewhere?

Overall though is it not time for Web developers to take security more seriously? My hit rate on serious defects is showing that in some cases its the last thing on their mind when developing - and those that do make a effort, they sometime miss the mark leading to a nasty bug.

For information, the tools I use daily are : IBM Appscan, Paros, BURP, XSS/SQL-Inject, althugh these are not the only ones - I have a list that fills my screen - of various proxy’s, header modifiers, request modifiers etc, encryption tools etc.