Secured Coding

Duration

3 days

Overview

This course introduces the principles of secure programming. It begins by discussing the philosophy and principles of secure programming, and then presenting robust programming and the relationship between it and secure programming. We will go through a detailed example of writing robust code and we will see many common programming problems and show their connection to writing robust, secure programs in general. We will examine eight design principles that govern secure coding and how to apply them to your own work. We will discuss how poor design choices drive implementation in coding. We will differentiate between informal, formal, and ad hoc coding methods. Throughout, methods for improving the security and robustness of your programs will be emphasized and you will have an opportunity to practice these concepts through various lab activities.

Objective

• Upon completion of this course, students will be able to:
• Understand the basics of secure programming.
• Understand the most frequent programming errors leading to software vulnerabilities.
• Identify and analyse security problems in software
• Understand and protect against security threats and software vulnerabilities
• Effectively apply their knowledge to the construction of secure software systems

Day 1

• Declarations and Initialization
• Prevent class initialization cycles
• Do not reuse public identifiers
• Do not modify the collection's elements during an enhanced for statement
• Numeric Types and Operations
• Detect or prevent integer overflow
• Do not perform bitwise and arithmetic operations on the same data
• Ensure that division and remainder operations do not result in divide-by-zero errors
• Use integer types that can fully represent the possible range of unsigned data
• Do not use floating-point numbers if precise computation is required
• Do not attempt comparisons with NaN
• Check floating-point inputs for exceptional values
• Do not use floating-point variables as loop counters
• Do not construct Big Decimal objects from floating-point literals
• Do not compare or inspect the string representation of floating-point values
• Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data
• Avoid loss of precision when converting primitive integers to floating-point
• Use shift operators correctly
• Characters and Strings
• Do not form strings containing partial characters from variable-width encodings
• Do not assume that a Java char fully represents a Unicode code point
• Specify an appropriate locale when comparing locale-dependent data
• Do not encode noncharacter data as a string
• Use compatible character encodings when communicating string data between JVMs
• Input Validation and Data Sanitization
• Prevent SQL injection
• Normalize strings before validating them
• Canonicalize path names before validating them
• Do not log unsanitized user input
• Safely extract files from ZipInputStream
• Use a safe subset of ASCII for file and path names
• Exclude unsanitized user input from format strings
• Sanitize untrusted data passed to the Runtime.exec() method
• Sanitize untrusted data included in a regular expression
• Specify an appropriate locale when comparing locale-dependent data
• Don't form strings containing partial characters
• Perform any string modifications before validation
• Use compatible character encodings on both sides of file or network IO
• Do not trust the contents of hidden form fields
• Do not allow sensitive information to leak outside a trust boundary
• Prevent XML Injection
• Prevent XML External Entity Attacks

Day 2

• Expressions
• Do not ignore values returned by methods
• Do not use a null in a case where an object is required
• Do not use the Object.equals() method to compare two arrays
• Do not use the equality operators when comparing values of boxed primitives
• Do not pass arguments to certain Java Collections Framework methods that are a different type than the collection parameter type
• Do not follow a write by a subsequent write or read of the same object within an expression
• Expressions used in assertions must not produce side effects
• Prevent loss of useful data due to weak references
• Object Orientation
• Limit accessibility of fields
• Preserve dependencies in subclasses when changing super classes
• Prevent heap pollution
• Provide mutable classes with copy functionality to safely allow passing instances to untrusted code
• Do not return references to private mutable class members
• Defensively copy mutable inputs and mutable internal components
• Sensitive classes must not let themselves be copied
• Do not expose private members of an outer class from within a nested class
• Compare classes and not class names
• Do not use public static nonfinal fields
• Be wary of letting constructors throw exceptions
• Respect object-based annotations
• Ensure that references to mutable objects are not exposed
• Do not use an object that has been freed.
• Methods
• Validate method arguments
• Never use assertions to validate method arguments
• Do not use deprecated or obsolete classes or methods
• Methods that perform a security check must be declared private or final
• Do not increase the accessibility of overridden or hidden methods
• Ensure that constructors do not call overridable methods
• Do not invoke overridable methods in clone()
• Never declare a class method that hides a method declared in a superclass or super interface
• Preserve the equality contract when overriding the equals() method
• Classes that define an equals() method must also define a hashCode() method
• Follow the general contract when implementing the compareTo() method
• Ensure that keys used in comparison operations are immutable
• Do not use finalizers
• Do not assume that reassigning method arguments modifies the calling environment

Day 3

• Exceptional Behaviour
• Do not suppress or ignore checked exceptions
• Do not allow exceptions to expose sensitive information
• Prevent exceptions while logging data
• Restore prior object state on method failure
• Do not complete abruptly from a finally block
• Do not let checked exceptions escape from a finally block
• Do not throw undeclared checked exceptions
• Do not throw Runtime Exception, Exception, or Throwable
• Do not catch NullPointerException or any of its ancestors
• Do not allow untrusted code to terminate the JVM
• Input Output
• Do not operate on files in shared directories
• Create files with appropriate access permissions
• Detect and handle file-related errors
• Remove temporary files before termination
• Release resources when they are no longer needed
• Do not expose buffers or their backing arrays methods to untrusted code
• Do not create multiple buffered wrappers on a single byte or character stream
• Do not let external processes block on IO buffers
• Distinguish between characters or bytes read from a stream and -1
• Do not rely on the write() method to output integers outside the range 0 to 255
• Ensure the array is filled when using read() to fill an array
• Do not convert between strings and bytes without specifying a valid character encoding
• Provide methods to read and write little-endian data
• Do not log sensitive information outside a trust boundary
• Perform proper clean-up at program termination
• Do not reset a servlet's output stream after committing it
• Canonicalize path names before validating them
• Miscellaneous
• Use SSLSocket rather than Socket for secure data exchange
• Do not use an empty infinite loop
• Generate strong random numbers
• Never hard code sensitive information
• Do not leak memory
• Do not exhaust heap space
• Do not modify the underlying collection when an iteration is in progress
• Prevent multiple instantiations of singleton objects
• Do not store nonserializable objects as attributes in an HTTP session
• For OAuth, ensure (a) [relying party receiving user's ID in last step] is same as (b) [relying party the access token was granted to].
• Do not use OAuth 2.0 implicit grant (unmodified) for authentication
• Do not let session information leak within a servlet

Programme scope, delivery arrangements and suitability are confirmed during enquiry.