Sunday, 2 March 2014

Software Security - At every stage of SDLC.

Is software security of any relevance to the role that I play as a programmer, a product owner, a  business developer, a user and a tester?

In the past month, a retail firm failing to fix the reported bugs concerning security led to several user's credentials landing in and now removed).

This article is an attempt to identify every role in SDLC with that of a responsible securitista.
  • Why security needs to be considered as a functional feature?
  • Why should software security be identified as an integral part of SDLC?
  • Why is there a need to build a security team?
  • Why having a mind-set and skills required for security, a boon to any organization?
In addition, it is necessary to get consumers to understand that the Application/Website built is robust and secure. And have this message conveyed with the security features that your application provides the users with. The image below is one such attempt by Amazon.

Image courtesy: Amazon

Adding security features, is making an effort to not lure the customers to a pitfall but remembering to model the requirements by combining the functional features of any application with security features(which are also essential for effective functioning of any application, irrespective of it being consumer facing or not).

The requirements that are received may sometimes be too specific and are in terms of achieving what the epic/user story demands in an agile team.

To illustrate this: Consider the design of a login page.
Deriving the requirement from a user story: As a user, I would like to login to the specified application successfully with the credentials(authorized mostly) provided.
To this description of the requirement, irrespective of the role played by you, consider adding the below requirements:
  • security
  • user accessibility
  • user experience
  • metadata information in the login page
  • contact us info
  • elements of SEO
  • copyright information
  • plug-in installation instruction
  • privacy notice
  • conditions of use.
Is this approach to requirement collection, programming, testing taught/followed/received in your organization?

Consider that an application is being built to deliver all testing related Heuristics information on a web page.
On typing 'I SLICED UP FUN'(a heuristic developed by Jonathan Kohl) in the text field and upon submitting this request to the server, the server fetches:
  • information about the author, 
  • explanation of the heuristic, 
  • it's usage, 
  • comments, 
  • user reviews, 
  • related searches and 
  • other heuristics by the same author.
Stop not at this point, build the requirements and test the aforementioned features and the below by installing add-ons for respective browser.
  • check the  title of the document
  • favorite icon
  • SEO(using seoquake)
  • mobile and desktop versions of the application
  • test on different versions of supported browsers for RWD(using window resizer)
  • localization and server information(using flagfox)
  • help and about the application
  • error messages, sending crash reports and learn more(an essential feature to learn more about the error)
  • performance on different browsers: by clearing cache, flushing DNS and tests related to cookies(using
  • install add-ons on supported browsers and collect data related to performance testing(using Yslow), load testing (using IMacros),brute force and dictionary attack(using IMacros)
  • display and accessibility (using the Wave toolbar, firebug to inspect and investigate) and everything that the home page is required to display and function well for all the intended users.
  • font check(using FOUNT) and color check(using colorzilla)
During functional testing phase stick not with testing/checking against specific requirements instead build a robust system which goes way beyond the requirements sheet. 
Build a security and privacy conscious team to build the requirements right from the login page to the delivery page for any application(web,standalone,online,offline).

It would help to secure the system if the collective intention of the team is beyond getting the consumers to click on DOWNLOAD/ORDER button. Pep up the security system of your app for every new feature added.

Question the motive, objective, requirements, the business and the product owner and learn regularly  to keep the requirements and test ideas updated.

What would you like to provide your consumers with?
If the answer is a fully functioning robust system, then set your objective to match this answer.

Designing the objective
What must the objective be? 
  • Lure consumers with extra bucks/promo code to get them to just Sign Up by providing the email address only - This design is an example of a minimalistic approach/vision.
  • Easy sign in: with an option to Sign In from an existing account which could raise the risk of an attack in case of an existing/known vulnerability. Accounts/Credentials reuse can be susceptible to security threats, in this case - This design is to increase the customer base easily/faster.
  • Providing users with a thorough researched registration page having validation checks for every field and maintain consistency across devices/browsers/platforms - This design is an example of the futuristic approach/vision.
Let us not assume that having robustness built into the system will secure the website from all types of hacks. But, yes we can add layers of security to make the application a little less prone to security threats.

-By identifying the vulnerabilities and building counter attack measures for the known vulnerabilities.

There are 1000(the current number may/maynot differ) password related vulnerabilities known and these issues can be found at http:/
NVD - National Vulnerability Database
If victimized, then as mentioned in an article here:
It is okay to panic, even hackers get hacked. It can be a learning experience.
Let panic not supersede the next step of action when compromised.
Being victimized can help the victim to:
  • Figure the type of hack.
  • Learn vulnerabilities which the app is prone to.
  • Trace back sometimes to the hacker.
  • Help add additional layers of security.

Security bug

The below hack is shared post the fix.
Shopclues(a retail website) had exposed sensitive information that which could be edited prior to posting the request to the server before proceeding to complete the transaction.
The values in the address bar could be edited and posted to the server using the POST method.
The same link could be used on another device(as is) to complete the transaction by altering the sensitive information.
The application did though secure the next layer by failing such transactions.

Note: The customer was not notified about the failed transaction.
But the altered and posted amount is deducted on continuing to complete the transaction by providing the bank account details:
Case 1: With Internet banking as the mode of payment.
Case 2: Test to check how the transaction is completed, if any other mode of payment is chosen other than net banking.

A mindset which is required to understand, know and learn about software security is amiss in certain regions and organizations at many work levels(an unexplained bias from what I see).

What Next? 

A need to take security seriously sincerely.

 Image courtesy: 
From the book 'Hacking for Dummies'

What We Can Do?
  1. We certainly can start now and develop a mind set for software security as a feature required to ensure QUALITY.
  2. Introduce security at all levels of Software Development Life Cycle.
  3. Educate our teams and ourselves with privacy and security concepts. 
  4. Questioning if all the fields marked as mandatory are really required when registering to not collect airplane tickets but to shop for flowers. I do not yet know why DOB has to be provided to shop for flowers or if a user is logging in to read an article in a public forum. Unless a database of all user's DOB is maintained and is used. 
  5. If/When encountered with such observations, then do file this bug under 'data theft' category if some website/web form is asking you to fill information which is certainly not in their scope of use/knowing.
  6. If required upfront ask for and collect the DOB's of all nationalities and maintain it in a national database of DOB's. Like the national database of Dog and Cat DNA's in the United Kingdom to help trace criminals(in a crime scene involving cats and dogs).

Summing it up
Bugs are not in the product. Bugs are about the relationship between the product and the people who desire something from it - via Testing Trapeze (

Hence the question to be asked and answered is: Do WE desire security as a feature in the applications that we provide and use?

No comments: