DeLiberation Logo
    ARRAY Development

appSQA™ Source Code Audit
Service Specification

  1. Purpose
    2.
  2. General Description
    3.
  3. General Technical Description
  4. General Security Environment
  5. Phase I - Code Security Inspection
    1. Primary Criteria
      2.
      1. Applications and programming language
        2.
      2. Number of lines of code
        3.
      3. General QA programming considerations
        4.
      4. Function testing
        5.
    2. Secondary Criteria
      1. CGI functionality
        2.
      2. Corporate security policy
        3.
      3. System/program calls
        4.
      4. User input
        5.
      5. "Exec" tags
        6.
      6. Embedded tags
        7.
      7. Hidden input fields
        8.
    3. Programming Language-specific Inspection Criteria
      4.
      1. Perl
        2.
      2. C/C++
  6. Phase II - Program Security Testing
    7.
    1. Primary Criteria
      2.
      1. Operating System
        2.
      2. Fault tolerance
        3.
      3. Programming Language
        4.
    2. Secondary Criteria
      3.
      1. File protections
        2.
      2. File storage locations
        3.
      3. Data forwarding
        4.
      4. CGI execution
        5.
      5. CGI crashing
        6.
      6. CGI code access
        7.
      7. CGI write permissions
        8.
  7. appSQA™ Exclusions
    8.
    1. Functionality
      2.
    2. Environment
      3.
    3. Performance
      4.
    4. Stressed Conditions
      5.
    5. Presentation
      6.
    6. Installation
      7.
[Top]
 
  1. Purpose

    2. This document is the Service Specification of appSQA™ for DeLiberation™ Extranet Release 2.0.

    [Top]

  2. General Description

    3. appSQA™ Source Code Audit is a service to test and inspect software developed by third parties for security and QA flaws. The process takes into account the client's application design spec and the known security risks of the operating system. There are two phases of testing:
    • Phase I - Code Security Inspection - a formal code review and white box testing
    • Phase II - Program Security Testing - black box testing

    [Top]
     
  3. General Technical Specification

    4. The appSQA™ specs should adhere to the DeLiberation™ Extranet Release 2.0 General Technical Specification (refer to: http://www.arraydev.com/commerce/delibadmin/delib2). In case of disagreement, the module's spec takes precedence over the General Spec.

    [Top]
     
  4. General Security Environment

    5. Before implementing appSQA, it is essential that the following security concerns are addressed.

    1. Check if the site is going to be adequately defended against potential breaks.

    2. Enquire as to whether the site will be periodically audited by an independent security audit service to reveal shortcomings in the service.

    3. Ensure that the personnel creating web applications (both in-house and third party) are trustworthy and knowledgeble, and hence won't jeopardize security when running the application, either by neglect or by design (i.e, that software includes independent checks and balances to identify internal staff members who would implement unauthorized code changes, time bombs or malicious attacks from within).


    [Top]

  5. Phase I - Code Security Inspection

    6.  
    1. Primary Criteria

      2.  
      1. Applications and programming language

        2. The applications for testing will most likely be CGI or ASP scripts.  They may also take the form of an Internet-delivered executable program such as a ActiveX or Java applet, or a browser plugin. There will need to be some testing for any malicious code which may employ helper programs to access sensitive data from a user's hard disk and deliver them to the program's author.

        Interpreted languages (e.g. Perl, VBScript, JavaScript) are generally easier to test and debug since they can easily be broken into segments and run separately to determine the cause/effect of operating them.  Furthermore, some scripting languages include safety features that can be invoked to determine the suitability of the code.

        Compiled code is usually much more difficult to assess and test, especially if modularity is not one of the design features of the application.

        For a review of network protection measures to safeguard against poorly written or malicious Java applets and applications, see:         http://www.networkcomputing.com/904/904ws2.html.
         
      2. Number of lines of code

        3. To ensure that the original developers did a proper job with their software, sample code (at least 300 lines) will need to be provided before evaluating whether the code is "testable".
         
      3. General QA programming considerations

        4. Does the client have a good technical spec to test against?  If the code is badly written, it will die or provide numerous opportunities to break into it.  This is dependent on the above choices and the development culture.

      4. Function testing
        System level functions should be highly encapsulated (and tested) at any system level. Operations should go through these functions, and not access the system directly.

       
    2. Secondary Criteria


      1. CGI functionality
        Does the CGI meet application requirements? If not, has a change in implementation affected the way it works to the extent that it is changing data that should not be changed?


      2. Corporate security policy
        Does the CGI conform to the client's security policy? If not, why not? Where it does not conform, is that a 'real' security risk, or just a breach of corporate rules?


      3. System/program calls
        Minimize the number of system and external program calls within the CGI.


      4. User input
        Ensure that user input is not passed on to system calls or external programs by the CGI. Ensure that user input does not directly effect anything at the system level.


      5. "Exec" tags
        Check "exec" tags for "server-side includes" statements.


      6. Embedded tags
        If a CGI redisplays user input, check for embedded server side "include" tags if the web server allows them (specifically, the "exec" tag).


      7. Hidden input fields
        Ensure hidden input fields are not being used to pass off critical data


    3. Programming Language-specific Inspection Criteria
        4.  
      1. Perl
        1. Use taint checking (perl -T)
        2. In addition, execute perl with -w or 'use strict' mode to ensure that variable scope does not conflict.
         
      2. C/C++ (and other compiled languages)
        1. Check that any character buffers cannot overflow... (may crash the program and give a hacker access to the system).


    [Top]

  6. Phase II - Program Security Testing


    1. Primary Criteria

      1. Operating System

        2. Because each OS has its own peculiarities, the effort involved is contingent on the OS and its "current" failings. Windows NT-based code, for example, will be examined from the perspective of security risks typical for this OS. In addition, any new security patches available for the OS will be applied where necessary. Patches can be found at a number of websites listed at:         http://www.csci.ca/links.htm#patches.

      2. Fault tolerance
        This process involves testing the program under stressed environmental conditions such as low memory, low number of file handles, or low to zero available disk space to determine if a fault results in a security vulnerability or breach.

      3. Programming Language
        Each testing tool should usually be implemented as language-specific.

    2. Secondary Criteria

      1. File protections
        Can users write to code files?


      2. File storage locations
        Is the CGI directory under the umbrella of the web site? If so, it is at risk.


      3. Data forwarding
        Can users insert data into the mechanism which passes it on to the CGI? If so, it is at risk.


      4. CGI execution
        Is the CGI execute code extracted from 'passed in' information? If so, it is at risk)


      5. CGI crashing
        Will the CGI crash if given erroneous data? If so, it is at risk. What happens when it crashes?


      6. CGI code access
        Ensure that CGI's are not directly readable via web.


      7. CGI write permissions
        Ensure that Write permissions are turned off on all CGIs.

    [Top]

  7. appSQA™ Exclusions


    8. The section outlines the testing criteria that will NOT be part of the appSQA™ process.

    1. Functionality

      2. Except as it relates to the announced security features, no special code inspection will be performed to verify that the product operates "as advertised" or that it functions correctly.

    2. Environment

      3. No network or hardware testing will take place. The server/site, therefore, should be audited prior to a code audit to ensure security of the environment. There will be no testing of whether the application operates with different platforms, applications or browsers.

    3. Performance

      4. No testing will be done to ensure that the transition and response times fall within specified limits.

    4. Stressed Conditions

      5. No testing will be done to ensure that the program responds with appropriate messages and actions under low resource conditions. There might, however, be a code audit to reveal if stressed environmental conditions (such as low memory, low number of file handles, or low to zero available disk space) affects security features.

    5. Presentation

      6. appSQA™ service will not check whether the application displays correctly or that it contains any flaws or inconsistencies in artwork, animation, sounds or spelling.

    6. Installation

      7. appSQA™ service will only verify that the installation code does not pose a security problem. It will not test whether the installation works properly.

[Top]

Please contact us using email (preferred), fax or by phone, to:
array (at) ARRAYdev.com
Phone: (613)733-0399
Fax: (613)248-4819

[Home]