Security Testing | Security 4 No0bs - Requirements: The Gathering

Performing a Security analysis for requirements in a story  Web Application Security Testing (pt.2)

Hey all,

In my previous post - Getting started using a WBS - I posted a draft of a WBS that is usable for the project you are assigned to, from a testing perspective. It is by no means a finished product and can be customized as needed. Below I'm going to discuss performing a security analysis for requirements in a story.

1.0 - Requirements Best Practices

Source: http://agilemodeling.com/essays/agileRequirementsBestPractices.htm

• Stakeholders actively participate
• Adopt inclusive models
• Take breadth-first approach
• Model storm details just in time (JIT)
• Treat requirements like a prioritized stack
• Prefer executable requirements over static documentation
• Implement requirements
• Create platform-agnostic requirements
• Create smaller, digestible requirements
• Question traceability
• Explain requirements gathering techniques
• Adopt stakeholder terminology (speak 1 language)
• Keep it fun
• Get Management support
• Turn stakeholders into developers

2.0 - Use Case (sample)

The context for this feature is login functionality for an e-commerce website, where visitors (new Customers) can opt to create accounts so as to facilitate order tracking, adding items to a wishlist, or simply expediting the checkout process. Visitors can register at any time simply navigating the the registration form from the link in the navigation header, or during checkout after adding items to their cart.

ID	ELEMENT	DESCRIPTION	PRIOR RESEARCH
1	User logs in	Registered members of the site can access their profile, dashboard, etc.	Single-sign on necessary for returning customers
Goal	Customers will freely interact with E-Comm agents	Customer Account Management	Client Services Analysis, 2016
Actors	E-Comm Reps, Registered Users	Agents can resolve customer issues; Customers can track their orders	Client Services Analysis, 2016
Pre-Condition	Customer record in DB	User is to have successfully registered in the system	CMS Integration
Post-condition	Profile page; login credentials	Successful subscription will create a profile with USN and avatar	CMS Integration
Trigger	Link in header / cart page	Guest users can opt to register from nav header or during checkout	N/A
Exceptions	Form validation rules	Required field and standard validation rules enforced	CMS Integration

3.0 - Security Analysis

Now that we've identified a feature in test, let's consider the security implications
source: OWASP TOP 10 for 2013

TEST CASE	ELEMENT	DESCRIPTION	SECURITY ANALYSIS
Login authentication	User logs in	Registered members of the site can access their profile, dashboard, etc.	Single sign-on necessary for returning customers; authentication protocols are enforced
Required Fields	Validation rules	Error messages shown on-submit	Messages should not convey the nature of what is wrong, or hint at what should be expected
Boundary Test	Max field lengths	Correspond to data structure in the DB	Should only allow for what is expected in the DB, no more
Character Test	Alpha-numeric data types	Text input validation for expected entry (ex: phone number = numeric keypad)	Non-numeric (ASCII) characters are to be inadmissible on-submit of form
SQL Injection	Commands in text fields	Error handling for script calls	SQL or any other such query language is to be inadmissible on-submit of form
Broken Authentication	Testing password, keys, session tokens, etc	Login authentication is to be handled securely by the server	Verify login authentication can't be compromised; session can't be hijacked; cookies can't be manipulated, and so on
Cross-site scripting	Authentication: session hijacking by way of XSS script	Data transmitted is validated or escaped	Test that XSS is not possible; data is transmitted properly
Insecure Direct Object Reference	Test for Exposure to a file, directory or key	Authentication is valid	User should not see references to file, directory, or the like exposed in the url post-authentication
Sensitive Data Exposure	Testing for exposure to sensitive data post-authentication	Authentication is secured	Sensitive data is adequately protected (stored, encrypted)
Cross-site Request Forgery	Login Redirect	On-submit, user is redirected to the expected destination	CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application.
Unvalidated Redirects	Login Redirect	System redirect for authenticated user operates as expected	Web applications frequently redirect and forward users to other pages and websites. This should not be the case at log in

4.0 - Requirements

Having scoped the feature, and mapped out some security scenarios, we've fleshed out some potential requirements:

• Login form fields are required
• Login form allows for only alpha-numeric data; where expected special characters are permitted
• Login username is to allow a finite number of text (or check for e-mail input)
• Login password field allows a finite number of characters, of a particular format
• Login form field password text field is to be masked
• Login error messages must be in the right font-style and color
• Login error messages must not communicate what the expected input should be
• Login authentication must redirect user the proper destination - cannot be hijacked
• Login session is managed server-side
• Login url must not past authentication parameters
• Login authentication cannot be manipulated in any way, giving non-auth'd users admin privileges

As you can see, the list can get pretty lengthy. And this is just the beginning!

Security Testing | Security 4 No0bs - Getting started by using a WBS

Applying Project Management fundamentals to Quality Assurance, as it relates to  Web Application Security Testing (pt.1)

Hey all,

This year, my focus is to ramp up my Info Sec. / Web App Security learning and stumbled upon this gem from last year. Figured I could re-purpose it for Security Testing. The scope of this "part 1" is to take the approach of someone assigned to a project and applying old-school practices to get started.

Some of this may work, some of it may not. But the foundation is laid out and it goes something like this:
 

1.0 - Objective

   1.1 - Define testing agenda and purpose of document as it relates to Security
           1.1.1 - Get Project Summary
           1.1.2 - Get S.O.W

2.0 - Testing Scope

   2.1 - Establish what is to be tested
          2.1.1 - Get Testing Requirements from PO / Project Lead / Devs
          2.1.2 - Get Testing Bounds (what won't be tested / out of scope)

   2.2 - Determine level of effort for test tasks
           2.2.1 - Test Types and Duration
           2.2.2 - Test Task Dependencies & Schedule (when to start a new cycle)

3.0 - Personnel

   3.1 - Who are the Client and Stakeholders involved
           3.1.1 - Get names from PO / Project Lead / Devs

   3.2 - Who are the other members on the team (PO / Devs / BA / QA / etc.)
           3.2.1 - Have Kick-off Meeting
           3.2.2 - Get Names, Roles & Responsibilities

4.0 - Security Software & Test Strategy

    4.1 - What Software will be used
            4.1 - Meet w. PM / Devs / QA
            4.2- Discuss best applications / programs to use
            4.3- Discuss testing strategy (best approach) as it relates to OWASP Top-10

5.0 - Risk

    5.1 - Establish risk matrix from features-in-test
            5.1.1 - Meet with PM / BA / Devs
            5.1.2 - Get Risk Analysis from BRD

6.0 - Entrance / Exit Criteria

     6.1 - Determine when testing is to begin
            6.1.1 - Meet with PM / Devs / QA Team
            6.1.2 - Get Release schedules / Test Cycle schedules

7.0 - Completion Criteria

     7.1 - Determine when testing is complete
            7.1.1 - Establish sweep-completion ETA

8.0 - Glossary

      8.1 - Write up all terms, acronyms, and defined language in use
             8.1.1 - Draft list of terms and definitions (including CTAs, navigation end-points)

9.0 - Approval

      9.1 - Sign-off by all parties involved

01.01.2017 Growth! and the changes I want

Act of contrition, take 1

forgive me blogger for I have sinned. It has been too long since my last post. Here's what went down:

2016 can best be described "episodic" - since it started bad, ended great, and marked along they way by lessons learned and awakenings.

Q1 - Winter of discontent

Let me start of by saying that vanity got the better of me in 2016. I let myself get caught up in the fight to make things happen and get sh@#$% done; enamored with the need to feel validated by having a title proper pay. I took a job that gave me just that, proper title and decent pay with the opportunity to make things happen and grow a team with the knowledge and skills I had acquired so far. A win, right!

No. Not even in the slightest.

You see, I took a job that had the promise of everything I was looking for. However, this became a "be careful what you wish for" moment. In my vanity - loving the title of "Manager" - I failed to read the fine print. I failed to see the bigger picture. I failed to do the very job I was hired to do. How, you ask?

Well, the environment I worked in was quaint. The people I worked with were friendly albeit somewhat distant. But the product I worked on bored me. Testing the same thing over and over became routine and monotonous. I fell out of love with this thing I was supposed to be responsible for. I stopped caring about the very thing QA Managers are supposed to care about. (Confession: I was a bad tester, not bad at testing, but unmotivated to be better)

I embraced the quality thereof, but I wasn't sold on its appeal. Worse, I didn't care anymore. As time went on, I began to feel more isolated and alone. I was frustrated and lonely, and craved change. I wanted camaraderie but found none. I wanted to learn new things, but was getting tasked with menial assignments. And this eventually reared its ugly head in my work performance, which greatly suffered. The consequence: termination. The feeling: elation!

Q2 - The turn-around

January and February of 2016 and I found myself unemployed, but somehow relieved. The weight of a burdensome job was lifted. Luckily I saved just enough to cover several months of expenses, with my unemployment pittance covering the rest. Dear reader, being without work feels great at the beginning - the honeymoon - but over time, the reality sinks in, the bills pile up, and desperation sets in. It can be a total mind-f**k if you let it.

Being without work can also be a great time for soul-searching and opportunity. I took the approach of using the time to learn new skills and gain new experiences. I practiced some much needed automation programming, I networked at meet-ups, and I kept an upbeat attitude. I used this time to make things happen and get sh**t done, per my new year's resolution mantra. And that I did.

As it would happen, March was a total bust. In my vigor to make things happen, I came down with a slight case of pneumonia which side-lined me for the entire month. No going out, no computer work, no blogging (sorry!), and no working out. It was a 30-day moratorium on life. Then along came April (the month, not a girl!)

Q3 - The re-awakening

Easter comes in at the end of March, and usually symbolizes rebirth and renewal. By April, this was my rebirth. I came out of my malady with a renewed confidence and strength. I resumed my daily activities of working out, job hunting, soul-searching, and getting back on track. Should have blogged, but got caught up with other things of more importance(again, sorry!).

April began with a tremendous job opportunity (current place of employment). Where I'm currently at is a start-up, like all my other places of employment, and presented itself as a small company with a project for a prestigious client. To say I was blessed to be hired and tasked with this project is an understatement. I work for an awesome boss, surrounded by amazing people, and work on a project I absolutely own. I'm at a place that really cares for your overall personal and professional growth. They invest time and energy into making sure you 'bloom where you are planted'. Do I need a title? Nah! Is the pay adequate? Better than adequate, as I'm making more than at my former employment, with much much better perks.

Fun fact: I had interviewed at the parent company some years back and turned it down for economic reasons (the position was contract). How fortunes have changed in my favor.

Q4 - Spiritual rebirth, renewed vigor

So here I am, dear reader, having a tremendous career rebirth. Some time ago I considered quitting QA Testing altogether and was contemplating web design. But I am at a job I truly embrace. I enjoy going to work. I welcome the opportunities it presents. And I have something to look forward to now in 2017, for you see, I am now part of a committee that is exploring ways to incorporate WEB APPLICATION SECURITY TESTING into its core competencies (shivers with excitement!)

A year ago, I was on the outs. 365 days and some odd hours later, I have optimism like never before. And its only the beginning - day 1.

2017 - GROWTH! and the changes I want

2017 is looking to be a promising year. I endeavor to keep them coming. For you see, the mantra for this year is growth. Spiritual, Financial, Physical, and Professional. In the months to come, I plan to build on my skills and level-up. That means hitting the Security track hard (not just talking the talk, but finally taking action).

2017 -- GROWTH!!!

Top 10 signs of a Bad Tester

If any of sounds like you, please take corrective action ... now!

Dear Readers,

Some time ago, I came across this top-10 list of what makes a bad tester. I'm sure we could all add to this list, so I invite you to do so. As I transition to a role in management, I've studied some of the points and will be adding my opinion in ("blue").

The list was subjective, based on the author's own perspective of what made a bad tester, and proper credit is given (paying this forward).

Enjoy! Top Ten Bad signs ( Augusto E.,  Principal Agile Test Engineer at Paddy Power PLC): 

Tester spends long hours sitting at his desk testing with the headphones on 

• This can be taken in a couple of ways. If a tester is spending long hours at their desk because they're in the midst of a full regression (manual or automation), test plan / test case write-up, or closing tickets, then its not the worst thing. But if this is a pattern of behavior akin to dissociating from one's environment, team, or workplace then it could be taken as bad.

He doesn't talk to Developers

• A big mistake if you are in the planning or testing phase of a project. A developer will be your ally when it comes to deducing bugs and putting forth a quality product. Failing to do this, dear tester, is a failure to do your job properly. No one is an island!

Developer don't talk to him

• See my previous comment. If you have not allied yourself with a developer, you are in a sense alienating yourself from the team. Your value will be diminished by this. Please stop doing this and get to know your developers ... a.s.a.p!

He doesn't talk to Product owners

• A tester who has not talked to a project manager, business analyst, or other such product owner is essentially lost at sea, in a raft, without a paddle, food, or water when it comes to testing effort. Failing to talk to a product owner is failing to acquire the necessary information to do the job (at all phases). If this is you ... stop doing this or find another job.

Product owners don't talk to him

• IF you find this to be true, dear tester, make some effort to correct this. Information is your weapon in the effort to deliver a solid testing platform. If you don't have the tools you need you won't succeed.

He doesn't talk to the customers

• This is subjective. If your job is in the Customer Service / Client Relations field, you will need their feedback to help in the quality effort. Otherwise, conversations with customers are best left to those in those roles.

Customers don't talk to him

• See my previous comment. The author of this list makes the point of the a tester being alienated.

Nobody looks for him for questions

• This is a problem if you are not perceived as valued member of the team. I can't stress it enough how bad this is, dear tester. If nothing else, you are the advocate of Quality. You need to know as much as a producer, work with a developer, and think like the end-user. You wear many hats and have tremendous value to the team. Your voice needs to be the most heard.

Nobody looks for him for opinions

•  Again, yours is the voice of Quality. You need to be heard above all others. If you have been successful in your job, you can provide insight into what makes a quality product. There is no place in QA for church mice. 

Communicates only through mail and bug reports

• Unless you have a sore throat, or some other ailment that keeps you from being able to physically speak, you would be wise to leave the desk and liase with your fellow team members. And I'm not including a sprint meeting, or stand-up. I'm talking about being able to sit with a developer or producer and get it done.

Missing defects, especially critical ones

• Where do I begin with this one. I can't stress it enough how BAD this is for you, dear tester. Its easy to miss a bug if the feature was not scoped properly, or if time was limited. But if you have had enough time, been given proper information / documentation to get the job done yet you still missed an obvious critical bug? 
• A bug that was missed because it was tester error illustrates an egregious problem with person assigned to the project, especially if they are not motivated to succeed. A good manager will be attuned to this and take the necessary action to prevent a repeat occurrence. If however, there is no change then decisions need to be made. 

No accountability / trace-ability

• I'm a huge proponent of trace-ability. When test plans and test cases are written, they provide tangible proof that you, dear tester, know the project you have been assigned to and have the testing tools necessary to get the job done. IF a bug is missed, one can look back and see where the problem occurred.
  
  I had a situation where a serious bug was missed (reported by the Client). The issue was escalated and an all-hands meeting was conducted. It turned out the issue was environmental, stemming from a particular race condition when connectivity to the network was lost (and the device went to sleep mode).
  
  The point: while it was easy to blame QA, our response was positive and constructive. We had accounted for all possible scenarios and had documentation (approved and signed off) to provide insight into the testing effort taken. We took accountability without playing the blame game. The bug was something attributed to a 3rd-Party API and the issue was immediately resolved. All was made right again.
  
  Accountability and trace-ability are HUGE in our line of work. Failing to take accountability for failure is less a flaw in testing, and more of a flaw in the person. 

Mind what you have learned, dear tester, serve you it will (yoda voice). 

This list was not meant to call you out (if this applies) but rather to point out the "bugs" in who you are as a member of the team. Take strides to improve who are and what you mean to the team and the company. 

QA Tool: Android Support (Platform Versions)

Dear Readers,
For those of you who specialize in developing, testing, or otherwise using Android handsets and / or tablets, pay close attention to the information listed below.

Below is a screenshot from the android developer portal, and shows a very useful breakdown of the more popular android versions to use.

Keep in mind, this is all pre-6.0 (aka "Marshmallow").

For more insight, click this link - Android Dashboard.

QA Tool: Using Using QuickTime to capture videos‏

Dear Readers,
Passing this useful tidbit of information along. Enjoy!

Using Using QuickTime to capture videos‏ 

1. Open QuickTime Player
2. Go to File > New Movie Recording
3. Assuming quicktime doesn't crash, it will: 
• Mirror the device on screen. 
• If it uses the camera on the computer you can change the video source by clicking the down caret next to the record button.
4. Proceed with recording the video, be mindful of video time (duration). 
• Some bug trackers have a file constraint of x-MB and you won't be able to upload your video

Blind Squirrel Approach: What do you do when requirements are sparse

"Because even a blind squirrel finds a nut once in a while ..."

You may be familiar with this saying, or you may not have ever heard of it before. The message is simple: given the likelihood of failure, success can happen, even in the slightest of ways. How does this apply to QA you ask?

New to the project

You, intrepid QA / Software Engineer in Test, have been assigned a new project, or are filling for someone. If the Test Plan is adequate, you should have all the information you need to successfully complete your task. But what if you don't? Do you panic?

• Solution-1: If a fellow teammate has handed off the project to you, they should already on-board you to the project and provide as much background, context, and other details of relevance. If this wasn't the case, the next-most person in the list is your team lead or manager. The team leads should have some substantial information and are usually the best "go-to" people on the team.
  
• Solution-2: I've always felt the need to read through as much as I can and get a Producer / Project Manager to sit with me and get a proper on-boarding (if the QA Lead / QA Manager hasn't already done so).

Sparse Requirements

So you are now on the project and have been somewhat on-boarded to the project, but the details are still fuzzy. What do you do?

• Solution-1: If you're like me, you investigate. You talk to the people assigned to this project and you get the details you need. I usually start with the developers, before I go to the producer. This is frowned upon, but who better to get the explicit information than from the people who need these details to complete the project. If a developer can successfully code against requirements, you can test against it. Developers will also provide additional insight you may need to consider in testing.
  
  Once the test cases are written (or updated), show this to the Producer for final approval. All will be right in the world.

Lack of Information

You've asked your team lead and there was a lack of clarity (tsk tsk). You asked the Developer for some insight and got none. Now you reach your wit's end and go to the Project Manager. They hand you documents that are sparse of details and have gaps in requirements. What's a good tester to do?

• Solution-1: This may not be a totally true scenario, but let's suspend belief for one second and entertain the likelihood that information is sparse. In the absence of information, a good tester has to take matters into his / her hands and ask for an S.O.W (scope of work), Requirements Document, or something in writing that outlines the expectations of the project.
  
  I've had this happen to a slight degree. The takeaway was that a huge amount of time was wasted doing some unnecessary investigative work to get the information I needed and successfully do my job.

Conclusion

For any QA Tester or Software Engineer in Test (SEIT), information is the key to success. The more we have, the better off we'll be. In my past history and all the way up to now, "I DON'T KNOW" has never been an acceptable answer. If you don't know, its because you didn't MAKE the time to know. If you didn't ask the right questions or do your due diligence, then its on you, dear tester.

If you asked the right questions but got the wrong information then the source of the information is suspect. All the more reason to keep asking questions.

Its our job to understand what it is that we are doing and why. I always ask, "why am I doing this?" not because of some defiant need to assert my position, but more because I want to understand the business logic. Also, I want to understand the scope of what I'm doing and to whom I'm doing it for. All these questions help me be a better tester, not just a cog in the machine.

This may or may not have helped you .. but if I can, let me offer one piece of advice:

ALWAYS BE ASKING?