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!