Building Secure Web Apps

Building Secure Web Apps

1. Requirements

   • Abuse Cases
     • Tells us what the system should not do
   • Security Requirements
     • are in addition to functional requirements
     • Center around CIA
       • Confidentiality (Includes Anonymity and Privacy)
         • Sensitive Data should be kept private to the parties applicable to the data
       • Integrity
         • Data should not be damaged by unauthorized parties
       • Availability
         • system should be responsive enough to service requests
         • Denial of service attacks deny such availability
     • Supporting Security Requirements
       • AAA supports standard security requirements by controlling who accesses which services and tracking these accesses
         • Authentication
           • Notion of identity, also called a principal (can be people or systems)
           • can be achieved by some data that is private to the principal
             • What only the principal knows e.g. a password
             • What the principal is e.g. biometric information such as fingerprint
             • What the principal has e.g. a USB dongle
           • can have multi-factor authentication - adds an extra layer of protection
         • Authorization
           • associates principals and actions and defines if a principal has a right to perform the action
           • Access control policies govern authorization
             • Access lists grant or deny principals access
             • can be based on users or group of users e.g. an admin can be assigned to multiple roles
             • can also be based on origin e.g. any user from a UoA IP address can access all the UoA library material
         • Accounting
           • Keep enough information so that security breaches can be investigated

2. Design

   • Threat Models
     • Network User
       • at the network edge
       • examines the contents what she receives
       • can submit input that is not legit
       • Possible attacks: XSS, CSRF, SQL Injection. Can also do denial of service attack
       • Must be on the same network as you so they can monitor the session and the traffic
     • Snooping User
       • has access to the network
       • can not only monitor what she sends and receives but also what others send and receive
       • may be able to modify, drop or duplicate contents that others send
       • Possible attacks: Denial of service, replay and session hijacking
       • requires physical access to the wired network
       • Encrypt all communication
         • TLS at the application layer
         • IPSec at the network layer
     • Co-located User
       • someone with access to the user's machine or server
       • most dangerous type of threat
       • has the ability to measure or interfere with IO e.g. key strokes, displays, drivers
       • read or modify the file system and/or memory
       • level of intrusion depends on access level
       • Possible attacks: trojan horses, key loggers and data theft
   • Basic Principles of Secure Design
     • Favor Simplicity
       • keeping things simple aims to prevent flaws
       • using fail-safe defaults should be secure choices
         • no default password and require user to pick one
         • choose whitelists rather than blacklists
       • Simplify UI
         • attempt not to offer security choices - pick a strong one internally and stick to it
         • don't ask the user to make too many security decisions - could result in the user picking a wrong choice
         • allow users to see the consequences of their security choices
     • Trust with Reluctance
     • Defend in Depth
       • Provide a line of defence
       • If one line of defence is broken, then there is a different one that needs to be tackled

3. Implementation

4. Testing