(blue star) Overview

Most of the software security flaws were found at code level implementations due to insecure build package configuration. Software security flaws can be introduced by:

  • Not identifying security requirements up front

  • Introducing flaws during maintenance or updating

(blue star) Reviewing process with the checklists

The review process is simply cross-checking the implemented code with the checklist. The checklist were categorized per critical implementation checkpoints. Each of checkpoints were listed below:

Error Handling and Logging

  • All logging controls should be implemented on a trusted system. (e.g., The server)

  • Logging controls should support both success and failure of specified security events.

Data Protection

  • Disable client side caching on pages containing sensitive information. Cache-Control:no-store, may be used in conjunction with the HTTP header control "Pragma: no-cache", which is less effective, but is HTTP/1.0 backward compatible

  • Implement appropriate access controls for sensitive data stored on the server. This includes cached data, temporary files and data that should be accessible only by specific system users.

  • Use only encrypted volumes.

System Configuration

  • Ensure servers, frameworks and system components are running the latest approved version.

  • Ensure servers, frameworks and system components have all patches issued for the version in use.

  • Turn off directory listings.

  • Restrict the web server, process and service accounts to the least privileges possible.

  • When exceptions occur, fail securely.

  • Remove all unnecessary functionality and files.

  • Remove test code or any functionality not intended for production, prior to deployment.

  • Prevent disclosure of your directory structure in the robots.txt file by placing directories not intended for public indexing into an isolated parent directory. Then "Disallow" that entire parent directory in the robots.txt file rather than disallowing each individual directory.

  • Define which HTTP methods, Get or Post, the application will support and whether it will be handled differently in different pages in the application.

  • Disable unnecessary HTTP methods, such as WebDAV extensions. If an extended HTTP method that supports file handling is required, utilize a well-vetted authentication mechanism.

  • If the web server handles both HTTP 1.0 and 1.1, ensure that both are configured in a similar manor or insure that you understand any difference that may exist (e.g. handling of extended HTTP methods).

  • Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks.

  • The security configuration store for the application should be able to be output in human readable form to support auditing.

  • Implement an asset management system and register system components and software in it.

  • Isolate development environments from the production network and provide access only to authorized development and test groups. Development environments are often configured less securely than production environments and attackers may use this difference to discover shared weaknesses or as an avenue for exploitation.

  • Implement a software change control system to manage and record changes to the code both in development and production.

Database Security

  • Use strongly typed parameterized queries.

  • Utilize input validation and output encoding and be sure to address meta characters. If these fail, do

    not run the database command.

  • Ensure that variables are strongly typed.

  • The application should use the lowest possible level of privilege when accessing the database.

  • Use secure credentials for database access.

  • Connection strings should not be hard coded within the application. Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted.

  • Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database.

  • Close the connection as soon as possible.

  • Remove or change all default database administrative passwords. Utilize strong passwords/phrases or

    implement multi-factor authentication.

  • Turn off all unnecessary database functionality (e.g., unnecessary stored procedures or services, utility packages, install only the minimum set of features and options required [surface area reduction]).

  • Remove unnecessary default vendor content (e.g., sample schemas)

  • Disable any default accounts that are not required to support business requirements.

  • The application should connect to the database with different credentials for every trust distinction (e.g., user, read-only user, guest, administrators).

File Management

  • Do not pass user supplied data directly to any dynamic include function.

  • Require authentication before allowing a file to be uploaded.

  • Limit the type of files that can be uploaded to only those types that are needed for business purposes.

  • Validate uploaded files are the expected type by checking file headers. Checking for file type by extension alone is not sufficient.

  • Do not save files in the same web context as the application. Files should either go to the content server or in the database.

  • Prevent or restrict the uploading of any file that may be interpreted by the web server.

  • Turn off execution privileges on file upload directories.

  • Implement safe uploading in UNIX by mounting the targeted file directory as a logical drive using the associated path or the chrooted environment.

  • When referencing existing files, use awhite list of allowed file names and types. Validate the value of the parameter being passed and if it does not match one of the expected values, either reject it or use a hard coded default file value for the content instead.

  • Do not pass user supplied data into a dynamic redirect. If this must be allowed, then the redirect should accept only validated, relative path URLs.

  • Do not pass directory or file paths, use index values mapped to pre-defined list of paths.

  • Never send the absolute file path to the client.

  • Ensure application files and resources are read-only.

  • Scan user uploaded files for viruses and malware.

Docker Security