Wednesday, June 16, 2010

STeP-IN Theme Conference - Application Security Testing

Recently STep-IN forum (http://www.stepinforum.org/) hosted a theme conference on 'Application Security Testing'. Given my newly developed interest in this topic, I attended this conference along with two colleagues. It was my first STeP-IN conference and also first visit to Bangalore. I enjoyed both parts of it :)

Conferences agenda was of two days, first day being about tutorials and second day conference.

Day 1, Tutorial 1: First tutorial was from McAfee. QA lead and managers talked about typical steps involved in hacking a website, breaking network security and common exploiting ideas for an application. They started with Linux command 'whoami' to know more about a website and that how can someone try to exploit unguarded ports on a server. We then moved to structuring security testing which majorly revolved around network security but those who work on desktop product could very well relate to it and that steps are more or less. The best part was discussion of common security vulnerabilities. They had a test website (shopping portal) on their laptop and demoed XSS and SQL Injection on that website. That was an insight for a person like me who knew about it but never saw it in action.

Day 1, Tutorial 2:
Second tutorial was about finding security flaws using static code analysis. Presenters had code snippets of C and Java and asked participants to find security flaws in that code. In some cases, participants were able to find more flaws than expected by presenter. Good ones :) As far as static code analysis (commonly known as code review) is concerned, I'm a big fan of it. My personal take is that finding security flaw is just a subset and we should be able to achieve more much out of it. Ranging from identifying memory leaks to performance bottlenecks, removal of redundant code to increase code coverage.

Day 2, Conference: It started with keynotes from Sr. VP and MD India of McAfee. Very enlightening. I was amazed to see data shared by him in terms of new threats and malware reported on daily basis. He also talked about various step that McAfee is taking for putting more focus on security around the globe. Few more presentations were done by delegates from different companies which revolved around need of security testing, how to incorporate it in software development life cycle and that individual Dev, QE and Product Manager needs to understand the importance of security and not just focus on feature development. Later, Mr Anthony Lim (IBM) stole the show with his presentation skills while talking about security threats in cloud computing.

Day 2, Open House: With four panelists from the industry, agenda was to discuss 'Testing Challenges in Cloud based Security'. Cloud computing being the new trend with lots of clouds around it, there were few interesting questions like 'Who is responsible if there is a security breach on the cloud?'. I think there are legal aspects attached to it but from tester's point of view there are challenges involved in it. Being on cloud, your app is always exposed to bad guys. First you secure your standalone application and then move to simulated cloud environment for security testing.

There was active participation from IBM (also sponsor of this conference) and McAfee. Delegates from other well known companies (Intel, Dell, Adobe, Mindtree etc) were also there. one thing which I found common while taking to other participants was that Application Security Testing, in majority of cases, is a QE initiated task and it is hard to convince management to fund time and resource for it. It is fairly important that you take your developer along, make him aware of importance of security and then get it rolling into your product.

I will conclude that it was a learning experience for me to attend this conference and exposure to industry's focus on security testing was definitely encouraging for budding security testers.

Tuesday, June 8, 2010

Introduction to Application Security

I'm in the field of Software Testing for few years, involved in manual & automated testing, black box to API testing but didn't get a chance to work on Application Security Testing. I thought of exploring this area and at the same time, start this blog to share my learning and learn from your experience.

Security leak means that an unauthorized user is able to access to your system or information. Let's go through and try to understand some of the common security problems, which you should evaluate for your product. Later, we will discuss each one of these in detail.

On web applications, this can happen through techniques like XSS (Cross site scripting) where third party code is embedded on a website which can then capture your credentials or CSRF (Cross site request forgery) where a hacker can gain control over your workflow.

On desktop product side, there are techniques like Command injections (you might have seen articles or videos on youtube where security researchers demo this by automatically launching Calculator when a faulty file is opened in the application. It means that there is security vulnerability in application's file handling logic which allows hacker to execute commands while opening faulty files. Another common technique is file format fuzzing which makes application to crash while handling faulty files and possibly giving control to hacker over system's memory.

Apart from these, if your application handles sensitive information such as PII (Personally Identifiable Information) and Credit Card information then you need to extra careful in handling these. For handling credit card information, there are industry standards (PCI DSS - Payment Card Industry Data Security Standard) which you should follow.

Testing application for security vulnerabilities is not limited to web applications. Contrary to my earlier belief that security testing is primarily for web applications, I'm now fairly convinced that it is equally important for desktop applications as well. Rather, cost of fixing an issue for desktop product would be more than pushing an update for web application.