Chapter 2

SOFTWARE SECURITY
PRACTICES

1
 INTRODUCTION
• It is less expensive to build secure software than to correct security issues after the
application has been completed
• The costs associated with a security breach is also very expensive
• Software development projects should also incorporate[include] a security
development lifecycle

2
 RECOMMENDED SOFTWARE
SECURITY PRACTICES
• Clearly define roles and responsibilities
• Provide development teams with adequate software security training
• Implement a secure software development lifecycle
• Establish secure coding standards
• Build a reusable object library
• Verify the effectiveness of security controls
• Establish secure outsourced 外包 development practices

3
 GOAL OF SOFTWARE SECURITY
• To maintain the confidentiality, integrity and availability of information resources
in order to enable successful business operations
• This goal is accomplished through the implementation of security controls

4
 SOFTWARE SECURITY FLAWS
• May be introduced at any stage of the software development lifecycle, including
❑ Not identifying security requirements up front 预先提出安全要求
❑ Creating conceptual 概念设计 designs that have logic errors
• Microsoft Bob.pptx
❑ Using poor coding practices that introduce technical vulnerabilities
❑ Deploying the software improperly
❑ Introducing flaws during maintenance or updating

5
 SAFETY & SECURITY IN
SCRIPTING
• Safety vs Security?

-safety
– system operate without harm of the people. (environment, property ）
- prevent data loss – ensure data integrity

- security
- protection of the system from unauthorized access
- prevent unauthorized access, malware, encryption of the data.

6
 SECURITY ISSUES

• Access to sensitive data

• Modification of data
• Denial of service
• Malicious code injection (XSS, SQL injection)

7
ACCESS TO SENSITIVE DATA

• Principle of least privileges 最小特权

– Authentication & authorization
– Limit the methods by which information can be accessed
– Limit the people who can access it
– Limit the time that people have access to it

8
9
 MODIFICATION OF DATA

• Server-side validation
• Whitelists vs blacklists
• Whitelisting (what they can do) is the practice of adding emails, IP addresses, and
apps to a list of entities that are safe to receive messages and attachments form or use.
• For example, cannot get email from email server, only can receive the email from the
specific email domain server.
• Blacklisting (what they cannot do) is the practice of compiling a list of entities that are
unsafe or unwanted to prevent them from reaching your computer or email.
• For example, Tarumt website block the user to access pornography website.

10
11
 DENIAL OF SERVICE

• Time interval between unsuccessful login attempts

• Wrong password, let user 5 minit later enter password.
• Limit number of login attempts

12
MALICIOUS CODE INJECTION

• Filter all user input at server-side as well

• Sanitization (remove) of user input
• Escaping output 转义输出
• For eg, try to change ‘>’,’<‘ to html input
• Use prepared statements/parameter binding in SQL statements

13
 NON-REPUDIATION

• Authentication
• Logging

14
IMPORTANT CONSIDERATIONS

• Code organization
• Error messages
• Storing and securing passwords

15
Secure Coding Practices

16
 INPUT VALIDATION (1)
• Conduct all data validation on a trusted system
• Identify all data sources and classify them into trusted and untrusted. Validate all
data from untrusted sources (e.g. databases, file streams, etc)
• There should be a centralized input validation for the application
• Specify proper character sets (e.g. UTF-8) for all sources of input
• Encode data to a common set before validating (canonicalize) 规范化

17
 INPUT VALIDATION (2)
• All validation failures should result in input rejection
• Validate all client-provided data before processing, including all parameters, URLs
and HTTP header content (e.g. cookie names and values).
• Verify that header values in both requests and responses contain only ASCII
characters

18
 INPUT VALIDATION (3)
• Validate data from redirects
• Validate for expected data types
• Validate data range
• Validate data length
• Validate all input against a white list of allowed characters, whenever possible

19
 OUTPUT ENCODING 编码
• Conduct all encoding on a trusted system
• Use a standard, tested routine for each type outbound encoding
• Contextually output encode all data returned to the client that originated outside the
application’s trust boundary
• Contextually sanitize all output of untrusted data to queries for SQL and XML
• Sanitize all output of untrusted data to OS commands

20
 AUTHENTICATION (1)
• Require authentication for all pages and resources, except those intended to be
public
• All authentication controls must be enforced on a trusted system
• Establish and utilize standard, tested, authentication services
• Use a centralized implementation for all authentication controls

21
 AUTHENTICATION (2)
• Segregate 分 离 authentication logic from the resource being requested and use
redirection to and from the centralized authentication control
• All authentication controls should fail securely
• Ensure that only cryptographically strong one-way salted hashes of passwords are
stored and that the table/file that stores the passwords and keys is writeable only by
the application (Do not use the MD5 algorithm if it can be avoided)

22
 AUTHENTICATION (3)
• Password hashing must be implemented on a trusted system
• Validate the authentication data only on completion of all data input
• Authentication failure responses should not indicate which part of the
authentication data was incorrect
• Utilize authentication for connections to external systems that involve sensitive
information or functions

23
 AUTHENTICATION (4)
• Authentication credentials for accessing services external to the application should
be encrypted and stored in a protected location on a trusted system. The source
code is NOT a secure location
• Use only HTTP POST requests to transmit authentication credentials
• Only send non-temporary passwords over an encrypted connection or as encrypted
data (e.g. an encrypted email)

24
 PASSWORD MANAGEMENT (1)
• Enforce password complexity requirements established by policy or regulation
• Enforce password length requirements established by policy or regulation
• Password entry should be obscured on the user’s screen 在用户屏幕上被遮挡
• Enforce account disabling after an established number of invalid login attempts
(normally 5)
• Usable Security

25
 PASSWORD MANAGEMENT (2)
• Password reset and changing operations require the same level of controls as
account creation and authentication
• Password reset questions should support sufficiently random answers
• If using email-based resets, only send email to a pre-registered address with a
temporary link/password

26
 PASSWORD MANAGEMENT (3)
• Temporary passwords and links should have a short expiration time
• Enforce the changing of temporary passwords on the next use
• Notify users when a password reset occurs
• Prevent password re-use
• Passwords should be at least 1 day old before they can be changed

27
 PASSWORD MANAGEMENT (4)
• Enforce password changes based on requirements established in policy or
regulation
• Disable “remember me” functionality for password fields
• The last use (successful or unsuccessful) or a user account should be reported to the
user at their next successful login

28
 PASSWORD MANAGEMENT (5)
• Change all vendor-supplied default passwords and user IDs or disable the
associated accounts
• Re-authenticate users prior to performing critical operations
• Use multi-factor authentication for highly sensitive or high value transactional
accounts
• If using 3rd party code for authentication, inspect the code carefully to ensure it is
not affected by any malicious code

29
 SESSION MANAGEMENT (1)
• Use the server or framework’s session management controls. The application
should only recognize these session identifiers (IDs) as valid
• Session ID creation must always be done on a trusted system
• Session management controls should use well-vetted algorithms that ensure
sufficiently random session IDs

30
 SESSION MANAGEMENT (2)
• Logout functionality should fully terminate the associated session or connection
• Logout functionality should be available from all pages protected by authorization
• Establish a session inactivity timeout that is as short as possible, based on
balancing risk and business functional requirements. In most cases it should be no
more than several hours

31
 SESSION MANAGEMENT (3)
• Disallow persistent logins and enforce periodic session terminations, even when the
session is active
• If a session was established before login, close the session and establish a new session
after a successful login
• Generate a new session ID on any re-authentication
• Do not allow concurrent logins with the same user ID

32
 SESSION MANAGEMENT (4)
• Do not expose session IDs in URLs, error messages or logs. Session IDs should
only be located in the HTTP cookie header
• Protect server-side session data from unauthorized access, by other users of the
server, by implementing appropriate access controls on the server
• Generate a new session ID and deactivate the old one periodically

33
 SESSION MANAGEMENT (5)
• Generate a new session ID if the connection security changes from HTTP to
HTTPS, as can occur during authentication
• Supplement standard session management for sensitive server-side operations, like
account management, by utilizing per-session strong random tokens or parameters

34
 ACCESS CONTROL (1)
• Use only trusted system objects for making access authorization decisions
• Use a single site-wide component to check access authorization
• Access controls should fail securely
• Deny all access if the application cannot access its security configuration
information

35
 ACCESS CONTROL (2)
• Enforce authorization controls on every request, including those made by server-
side scripts, “includes” and requests from rich client-side technologies like AJAX
• Segregate privileged logic from other application code
• Restrict access to files or other resources, including those outside the application’s
direct control to only authorized users

36
 ACCESS CONTROL (3)
• Restrict access to protected URLs to only authorized users
• Restrict access to protected functions to only authorized users
• Restrict direct object references to only authorized users
• Restrict access to services to only authorized users
• Restrict access to application data to only authorized users

37
 ACCESS CONTROL (4)
• Restrict access to user and data attributes and policy information used by access
controls
• Restrict access to security-relevant configuration to only authorized users
• Server-side implementation and presentation layer representations of access control
rules must match
• If state data must be stored on the client, use encryption and integrity checking on
the server side to catch state tampering

38
 ACCESS CONTROL (5)
• Enforce application logic flows to comply with business rules
• Limit the number of transactions a single user or device can perform in a given
period of time. The transactions/time should be above the actual business
requirement, but low enough to deter automated attacks

39
 ACCESS CONTROL (6)
• If long authenticated sessions are allowed, periodically re-validated a user’s
authorization to ensure that their privileges have not changed and if they have, log
the user out and force them to re-authenticate
• Implement account auditing and enforce the disabling of unused accounts

40
 ACCESS CONTROL (7)
• The application must support disabling of accounts and terminating sessions when
authorization ceases (e.g. changes to role, employment status, business process,
etc.)
• Create an Access Control Policy to document an application’s business rules, data
types and access authorization criteria and/or processes so that the access can be
properly provisioned and controlled. This includes identifying access requirements
for the data and system resources

41
 CRYPTOGRAPHIC PRACTICES
• All cryptographic functions used to protect secrets from the application user must
be implemented on a trusted system
• Cryptographic modules must fail securely
• All random numbers, strings, file names, etc. should be generated using the
cryptographic module’s approved random number generator
• Establish and utilize a policy and process for how cryptographic keys will be
managed

42
 ERROR HANDLING (1)
• Do not disclose sensitive information in error responses (e.g. system details, session
IDs or account information)
• Use error handlers that do not display debugging or stack trace information
• Implement generic error messages and use custom error pages

43
 ERROR HANDLING (2)
• The application should handle application errors and not rely on the server
configuration
• Properly free allocated memory when error conditions occur
• Error handling logic associated with security controls should deny access by default

44
 LOGGING (1)
• All logging controls should be implemented on a trusted system
• Logging controls should support both success and failure of specified security
events
• Ensure logs contain important log event data
• Ensure log entries that include untrusted data will not execute as code in the
intended log viewing interface or software

45
 LOGGING (2)
• Restrict access to logs to only authorized individuals
• Utilize a master routine for all logging operations
• Do not store sensitive information in logs (e.g. unnecessary system details, session
IDs, passwords)
• Ensure that a mechanism exist to conduct log analysis

46
 LOGGING (3)
• Log all input validation failures
• Log all authentication attempts, especially failures
• Log all access control failures
• Log all apparent tampering events, including unexpected changes to state data
• Log attempts to connect with invalid or expired session tokens

47
 LOGGING (4)
• Log all system exceptions
• Log all administrative functions, including changes to the security configuration
settings
• Log all backend connection failures
• Log cryptographic module failures
• Use a cryptographic hash function to validate log entry integrity

48
 DATA PROTECTION (1)
• Implement least privilege, restrict users to only the functionality, data and system
information that is required to perform their tasks
• Protect all cached or temporary copies of sensitive data stored on the server from
unauthorized access and purge those temporary working files as soon as they are
not longer required

49
 DATA PROTECTION (2)
• Encrypt highly sensitive stored information, like authentication verification data,
even on the server side. Always use well-vetted algorithms
• Protect server-side source code from being downloaded by a user
• Do not store passwords, connection strings or other sensitive information in clear
text or in any non-cryptographically secure manner on the client side

50
 DATA PROTECTION (3)
• Remove comments in user-accessible production code that may reveal backend
system or other sensitive information
• Remove unnecessary application and system documentation as this can reveal
useful information to attackers
• Do not include sensitive information in HTTP GET request parameters
• Disable auto complete features on forms expected to contain sensitive information

51
 DATA PROTECTION (4)
• The application should support the removal of sensitive data when the data is no
longer required (e.g. personal information or certain financial information)
• 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

52
 DATABASE SECURITY (1)
• Use strongly typed parameterized queries
• Utilize input validation and output encoding and be sure to address metacharacters.
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

53
 DATABASE SECURITY (2)
• 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
54
 DATABASE SECURITY (3)
• 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))

55
 DATABASE SECURITY (4)
• 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)

56
 FILE MANAGEMENT (1)
• Do not pass user supplied data directly to any
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
57
 FILE MANAGEMENT (2)
• 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
• Scan user uploaded files for viruses and
malware
58
 FILE MANAGEMENT (3)
• When referencing existing files, use a whitelist
of allowed file names and types
• 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

59
 TRADE-OFFS?
• Performance vs Security
• Efficiency vs Security
• Usability vs Security

60
EXTRA KNOWLEDGE
From this point onwards

61
MEMORY MANAGEMENT (1)
• Utilize input and output control for un-trusted
data
• Double check that the buffer is as large as
specified
• When using functions that accept a number of
bytes to copy, e.g. strncpy(), be aware that if
the destination buffer size is equal to the
source buffer size, it may not NULL-terminate
the string
62
MEMORY MANAGEMENT (2)
• Check buffer boundaries if calling the function
in a loop and make sure there is no danger of
writing past the allocated space
• Truncate all input strings to a reasonable
length before passing them to the copy and
concatenation functions
• Specifically close resources, don’t rely on
garbage collection (e.g. connection objects,
file handles, etc)
63
MEMORY MANAGEMENT (3)
• Use non-executable stacks when available
• Avoid the use of known vulnerable functions
(e.g. printf, strcat, strcpy, etc)
• Properly free allocated memory upon the
completion of functions and at all exit points

64
GENERAL CODING PRACTICES (1)

• Use tested and approved managed code rather

than creating new unmanaged code for
common tasks
• Utilize task specific built-in APIs to conduct
OS tasks. Do not allow the application to issue
commands directly to the OS, especially
through the use of application initiated
command shells

65
GENERAL CODING PRACTICES (2)

• Utilize locking to prevent multiple

simultaneous requests or use a synchronization
mechanism to prevent race conditions
• Protect shared variables and resources from
inappropriate concurrent access
• Explicitly initialize all your variables and other
data stores, either during declaration or just
before the first usage

66
GENERAL CODING PRACTICES (3)

• In cases where the application must run with

elevated privileges, raise privileges as late as
possible, and drop them as soon as possible
• Restrict users from generating new code or
altering existing code
• Review all secondary applications, 3 rd party
code and libraries to determine business
necessity and validate safe functionality

67
GENERAL CODING PRACTICES (4)

• Avoid calculation errors by understanding your

programming language’s underlying
representation and how it interacts with numeric
calculation. Pay close attention to byte size
discrepancies, precision, signed/unsigned
distinctions, truncation, conversion and casting
between types, NaN calculations, and how your
language handles numbers that are too large or
too small for its underlying representation

68
GENERAL CODING PRACTICES (5)

• Implement safe updating. If the application

will utilize automatic updates, then use
cryptographic signatures for your code and
ensure your download clients verify those
signatures. Use encrypted channels to transfer
the code from the host server

69