name: inverse layout: true class: taylor msoe --- class: center, middle .title[ # Developing Secure Software ] ??? * **P** speaker view * **C** clone slideshow * **?** help --- # Want to protect against * Confidential data exposure * Misuse of system resources * Disruption of useful machine operation * Assisting future attacks * etc... --- # Talk Overview ## Security Principles — Be Mindful ## Security Practices — Be Conscientious --- class: center, middle .title[ # Security Principles ] --- # Integrity * Only authorized users can manipulate data -- * All data manipulation via authorized methods/procedures -- > Encapsulation limits damage --- # Confidentiality * Unauthorized access to information is prevented -- > Leaking data is bad -- * Even if villain is unable to gain control of your software --- # Availability * Authorized users can access the system -- > May as well not exist * if cannot be accessed --- # Principle of Least Privilege * Grant minimal access rights to tools and data -- > Limit pain when things go bad --- # Economy of Mechanism * Systems should be designed to be as simple and small as possible -- > Simplicity reduces chance of future errors --- # Open Design * Security should not depend on the secrecy of its design or implementation -- > Security lost if secrets compromised --- # Psychological Acceptability * Software should be as easy to use/access as if the security mechanisms weren't present -- > Difficult security makes people look for alternatives --- # Fail Secure * Limit the amount of information exposed when failing -- > Be careful with error messages --- # Plan for Failure * Have a plan for securing systems and recovering from suspected/known security breaches -- > Swift response GOOD -- > Rushed response BAD --- # Weakest Link * A system is only as strong as its weakest link -- > Can't neglect any aspect --- # Summary of Security Principles * Integrity * Confidentiality * Availability * Least Privilege * Economy of Mechanism * Open Design * Psychological Acceptability * Fail Secure * Plan for Failure * Weakest Link --- class: center, middle .title[ # Security Practices ] --- # Security Practices * Be defensive -- + Implement as if you are under attack -- * Prefer having obviously no flaws rather than no obvious flaws -- + Clever logic can hide flaws -- * Avoid duplication -- + Maintaining duplicated code is tedious + Often doesn't happen -- * Establish trust boundaries -- + Sanitize and validate data when crossing boundaries -- * Encapsulate -- + Provide succinct interfaces + Make fields private + Avoid accessors + Coherent behaviors in interface/class/package/module --- # Security Practices cont... * Document security-related information -- + Required permissions + Security-related exceptions, preconditions, postconditions -- * Beware of activities that may use disproportionate resources -- + Requesting large image sizes for vector graphics + Integer overflows + Infinite loops -- * Release resources in all cases -- + Every `open` should have a `close` + Ensure output buffers are flushed + If the flush fails, throw an exception --- # Security Practices cont... * Purge sensitive information from exceptions -- + Exception objects may contain sensitive information + Useful when debugging + Risky in production + E.g., a `FileNotFoundException` may reveal location of a configuration file with sensitive information -- * Do not log highly sensitive information -- + E.g., Social Security numbers and passwords --- # Security Practices cont... * Consider overwriting highly sensitive data from memory after use -- + Reduces risk of sensitive data exposure from sniffing memory before garbage collector acts + Can be difficult - Cannot overwrite immutable fields - Libraries may make additional copies of data -- * Generate valid formatting -- + Guards against attacks exploiting special characters as inputs, incorrect escaping, etc... to cause incorrect formatting. + Use well-tested libraries for output — If they don't exist, create simple classes with the sole purpose of cleanly handling formatting (so they are easier to test). --- # Security Practices cont... * HTML/XML/SQL generation requires care -- + Sanitize untrusted data before including it in HTML, XML, or SQL. -- * Limit the extensibility of classes and methods -- + Design classes and methods for inheritance or declare them as final. + Left non-final, a class or method can be maliciously overridden by an attacker. -- * Validate inputs -- + Inputs from untrusted sources must be validate before use. -- * Prevent constructors from calling methods that can be overridden -- + Constructors that call overridable methods give attackers a reference to `this` before the object has been fully initialized. -- * Prefer immutability -- + Declaring things as final ensures that they can't be changed maliciously. --- # Security Practices cont... * Ensure public fields are `final` -- + Only immutable values should be stored in public fields to prevent malicious changes. -- * Ensure `public static final` field values are constants -- + `public static final` means that the field can't be changed + If a reference, then reference can't point to a different object + Still possible to interact with the reference + If reference points a mutable object, it can be used to change it value of the object -- * Create copies of mutable output values -- + Returning a reference to a field from an object gives the caller direct access to that internal field, even if it was declared private. Making a copy of the field and returning a reference to that copy is safer. --- # Security Practices cont... * Consider declaring class as `final` -- + A `final` class cannot be extended, e.g., `String` -- ``` Java public final class String implements Serializable, Comparable<String>, CharSequence { } ``` --- # Security Practices cont... * Consider declaring class/interface as `sealed` -- + New in Java 15 + Control what classes can extend the class / implement the interface -- ``` Java public abstract sealed class Shape permits Point, Circle, Rectangle { } ``` -- * Subclass must be declared as `final`, `sealed`, or `non-sealed` -- ``` Java public final class Point extends Shape { // ... public sealed class Circle extends Shape permits LabeledCircle { // ... public non-sealed class Rectangle extends Shape { // ... ```