security (25)

OWASP Dependency-Check Plugin on Jenkins CI

The OWASP Dependency-Check Plugin will locate npm, maven, php, jar packages and analysze them for known security vulnerabilities (full support list is on the website). To use, you need to create a build step on the app build job you have, after all dependencies installed, then publish the report in a post-build step.

End-users as security testers

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.


I would caution anyone, and everyone, to not judge anybody by information that isn’t complete, over the Internet especially, and when all the facts aren’t known.
Anonymous justice is no justice


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.

Fast forward with a pencil >>

I remember developing a really fast technique for advancing/reversing audio cassette tapes using hexagonal shaped pencil and a lot of technique.  Part of it was the pointless childish challenge, but also down to the brutality of my stereo player at the time. Fast forwarding from beginning to end of a C90 tape could take less than  a minute, climaxing in an almighty clunk as the stereo took a few seconds to register the tape could be moved no further.  I repaired the occasional broken tape using tiny pieces of sellotape – again, a  childish challenge.  For a child, adversity can take many forms, and as a child (occasional tantrums aside), we are persitent in our goal of navigating round obstacles put in our path – be they parental rules, or dodgy stereos.  Our dogmatic belief is there is always a way round a problem.

An application presents a tester with a systematic set of challenges to overcome.  We know there will be bugs somewhere, we know improvements can always be made, and we know there will be vulnerabilities.  But unlike a child, we have to follow a more logical structure rather than the unstructured systematic approach of a small child. However, we can have both … end users can be viewed as childlike beings, and there is no reason you cannot add some method to the erratic methods of children to reach a goal.

I am well aware of my own behaviour when surfing.  I turn into a cantankerous, impatient user who will leave your unusable site, just to spite you.  Yes, I can be that petty.  As a tester, I try to carry that with me.  When users encounter a problem they may just give up, or they may just hammer away trying to get something to work.  They may be bothered to write you an irritated email, but lets face it – how many of us can be bothered with that.  I do it – but only as opportunity to introduce myself and testing services 😉

So we need to account for two broad user groups – those that give up at drop of a hat, and those that will persist doggedly to get round a problem.  Both a major traits of a small child that are carried through to adulthood, and surface in differing situations.  None more so than the web, which is most likely to bring out the sulky child in us all.  This is possibly why I have always had positive experience using school leavers/undergraduates as testers, as they still have significant amounts of that childlike energy. You need to channel of course, as random chaotic testing can end up providing little value.

There are advantages to both, and testers need to play both roles, depending on the type of testing you are trying to perform. Doing a usability check definitely warrants the former group, as by far a major cause of people dropping off sites is Usability. If you are doing a security test, then an approach that covers multiple courses of action will highlight potential unexpected behaviour or security issues. You must have noticed, if you have ever been in a User Acceptance Test session with project stakeholders, there is also one person who will ask the awkward questions, and will deviate from path of instruction. They are the most useful person in the room, even if it may be painful to hear what they have to say sometimes!