Increasingly security testing of web applications are left to the end-user to discover. The web is generally seen as an imperfect thing, so it is not surprising that most users do not expect a website that works well 100%. What I have seen on the best Agile and Lean projects, is this is omitted to much further down the cycle, if at all – but why? Yes, they are skilled testing areas (and hence higher cost to secure fully skilled resource), but there is a lot that can be done, with the right tools and approach. Continue reading
I have had a few years of frustration at self-proclaimed “web saviours” amounting to little more than scattergun ddos attacks, ftp and database compromises. All, I should say, as easy to protect yourself against. For a start don’t use ftp! Switch that service off, and use ssh or a secure ftp protocol to deal with file management. I have had a few more experiences this year dealing with fallout from hacker attacks, along with some communication to some groups and individuals.
I have been a little hard on youth, as it is easy to lose focus by getting caught up in a moment. Sometimes I believe hackers confuse the web itself with their targets. Attacking random websites, just because you found back-door access into server or database, seems a little churlish and not in the least bit revolutionary. “Highlighting security flaws” is a pretty weak motivation, as who does it really benefit. The hoster? They nail that particular hole shut and go about their business. Meanwhile the hosters’ customers are the ones who sustain the actual damage.
One of the more publicly known of the more focused hackers is the “The Jester” – he calls himself a (US) Patriot hacker. Maybe not best of starts, but his targets are deliberate – mainly Islamist extremist websites, but occasionally sidesteps onto other projects such as the turgid Westoboro Baptist Church and the tasteless twitter trolling site that appeared quickly in the wake of the Newtown school shootings.
There is an arrogance in the hacker world – as with anything with tech, you get the stars and a million imitation drones. It is easy enough to create a presence on the web and declare yourself and Anonymous hacker. Take credit for other attacks, blame embarrassing boo-boos on other. There is a childish level of “blame culture”, but now the “stars” are easier to spot as they carry an agenda is that understandable and to varying degree, morally sound.
What currently interests me how few seem to challenge hackers online. For all the umprompted outpourings of opinions, no-one seems to challenge something so prevalent and so potentially damaging for individuals. Are you sure you don’t have an opinion? Usually with a little digging you can find responsible party for a website attack. Though there are truly anonymous hackers out there, most will publicise their action in some way. Even if it is just boasting in a readme file! My point is if you don’t voice up when you think something is wrong, how will they ever know. “Script kiddies” are getting to be a bit of a curse, rather than any help.
One of the values of automated testing is being able to run a set of tests as part of a suite or load. However, if you have sensibly built in some good protection using MVC anti-forgery or SAML tokens, then there is strong possibility tests can fail due to security functionality disallowing tests run too rapidly. Continue reading
The first lesson I had with Behaviour Driven Development (BDD), is that Kanban is ideal project management match. And particularly suitable for re-factoring projects, though prepare yourselves for more admin and management.
The remit was to implement a clearly defined set of new features, into an unknown arena. No developer likes picking up code in such advanced state as there are many possibilities as to what can go wrong. There were no registered open bugs of any note, as but development progressed, issues regularly surfaced at integration point. Here we hit what we realised was accidental Kanban. Because of the unpredictability of re-factoring projects, the development timeline became more fluid and subject to change. Although not generally done as default, I created new feature files in the Specflow BDD tool to cover the bugfix or where possible added or edited a scenario to an existing feature file (a feature file comprises of a user story and one or many scenarios). This meant that the developer fixing the bug could still follow the BDD process.
Exploratory Testing (ET) is much used (and abused) term, but is very valid description of testing done outside of BDD boundaries. However there is no reason that you can’t still keep to the feature file process when devising ET scope. No application is perfect, so the record of no outstanding issues looked likely to be a simple project closure exercise. So I used the ramp of issues closed near project end date as start point and sure enough, found many existing issues. Due to resources these issues were reviewed with harsh eye, only prioritising ones that could not be postponed. For example, one of the first issues found was that weekly newsletter emails were not being sent out, and had accumulated on mailbox server.
Security testing was not considered in the original project work, but with any website I believe is performing standard checks for security to highlight the more common XSS-scripting and SQL Injection vulnerabilities. It is surprisingly how many developers leave basic holes such a password field autocomplete set active. Security testing can go to real depths, but you can catch most hackers out with basic tests using specific lightweight tools. Remember, most hackers are amateurs.
Kanban provided a dynamic way to manage Work in Progress, which is at Kanban core. The idea is the keep your Kanban board well weighted, with work spread out to resources evenly and identifying the cross-functional elements of the team. Due to my overall experience I was able to offer consultancy on improvements from Kanban perspective. Scrum is iterative in approach, but Kanban is Iterative AND Incremental – managing the parts and the whole. More challenging from management perspective, but extremely effective at gelling a team.
BDD – Behaviour Driven Development is a set of practices which help software development teams to have conversations about the behaviour of their system and how it delivers value to the project stakeholders. BDD has changed from its early roots as a replacement to TDD and now works as a mini-methodology across the whole software lifecycle. Over the last few years the adoption of BDD has grown globally, with dozens of tools created, used by hundreds of projects around the world. In this talk we look at the original reasons behind the creation of BDD, bringing the focus away from the tools and back to its purpose and the philosophies which support it, including Real Options, Deliberate Discovery and Feature Injection.
Another great security tool from the Open Web Application Security Project. Asides from worrying spelling in a lot of these open source projects (“Responce”??), there is little gem to identify hidden pages/directories and directories with a web application, which highlights possible security holes (an emailer script in unused page for example). This can be used safely as the tool will not exploit anything it finds, just to find other possible attack vectors that are not immediately obvious.