Skip to content

Instantly share code, notes, and snippets.

Last active Apr 7, 2021
What would you like to do?
Reading notes from "Software and Systems Security for CompTIA CySA+" on Pluralsight

Software and Systems Security for CompTIA CySA+

Examining the Software Development Lifecycle (SDLC)

  • ignored instructor's advice to set up penetration testing VMs



  • the most important phase
  • done by the most senior team members, with input from customers


  • software, hardware, external sources
  • where is the data being stored?
  • how is the traffic transmitted?
  • how is access granted?
  • who's given admin rights?


Risk Analysis
  • threats and vulnerabilities which may arise from interaction with other systems
  • external/legacy code -- any vulnerabilities?
  • high-risk privacy projects could require legal review
Functional Specifications
  • description of interface requirements (input types/validation)
  • time zones, dates in the past allowed?
  • workflow
  • audit trail for every update on the database


  • boxes, diagrams
  • "known resource environment"
  • connections


  • test the boxes from "Implementation" from an "unknown resource environment"
    • aka "hacker view"
  • make a testing plan
    • unit tests
    • system/end-to-end tests


  • how is it being secured?
  • what is the security mechanism in the CI/CD system, and the server(s)
  • if it's deployed via portable hardware, what happens if it's lost?
  • package installer - does it install what you think it does?


  • ongoing security monitoring
  • emergency response procedures
  • updates that could affect the application
    • OS, backend, third-party

End of Life

  • steps to remove software
  • effects on other back end resources
  • make sure you disable service accounts
  • thorough documentation will power thorough decomissioning

Software Development Models

Code and Fix

  • no plan
  • fix problems as they occur, or until the project is finished
  • if the architecture is wrong, big rewrites may be required
  • may never get released


  • one task after the next, predefined
  • when to use?
    • requirements are well-documented
    • technology is understood, not dynamic
    • ample resources, including expertise
  • it's a bit rigid, can't really pivot
    • better for simple projects
  • security-wise, it allows for security checks at every stage


  • satisfy the customer through early and continuous deployment
    • check security at each deployment
    • progress is visible
  • welcome changing requirements
  • business + devs working together
  • sustainable development, consistent pace
  • self-organizing teams
  • iterative improvement of team effectiveness
  • each iteration goes through each of the five phases (above)
  • disadvantages
    • not great for complex dependencies
    • depends on customers
    • not great for documentation (?)


  • no full specification of requirements
  • starts by specifying only a part of it, then another part on completion
  • when to use?
    • when requirements are clear, but may evolve
    • time to market constraint
    • using new tech, learning on the fly
    • resources for later phases aren't available yet
  • bugs and security flaws can be caught in each iteration
  • disadvantages
    • more resources may be required, like consultants etc.
    • not for small projects
    • not suitable for changing features


  • Waterfall "control" aspects + Iterative
  • revisits four phases multiple times
    • each iteration is a "spiral"
  • when to use
    • budget constrained, but risk evaluation is important
    • medium/high-risk
    • long-term commitment
    • unsure of requirements
  • disadvantages
    • management is more complex
    • don't know when it'll be done
    • process is complex

(Security) Code Reviews

  • why?
    • detect vulnerabilities early on


  • define the scope of the code review
    • budget constraints
    • types of code review
    • categorize vulnerabilities

Common Sense Tips

  • talk with the team
  • have enough time
  • limit to 400 lines, 60 minutes
  • verify the fixes took


  • static (without execution)
  • dynamic (monitor system memory, response behaviors, performance while running)
  • peer review
  • UAT (user acceptance testing)
  • fuzzy testing
    • application UI fuzzers
      • import/export functions, input fields
    • protocol fuzzers
      • transmit manipulated packets into the application using unexpected values in header/payload
    • file format fuzzers
      • open files whose format has been manipulated
    • dumb fuzzers generate random inputs
    • other fuzzers test known vulnerabilities
  • fault injection
    • compile time -- introduce fault by modifying source code
    • protocol software -- send unexpected/noncompliant data
    • runtime -- inserting into memory or injecting faults to cause the application to fall down
  • mutation testing
    • small modifications to the program itself
  • stress/load testing
  • security regression
  • formal method
    • capture every possible path, find corner cases
    • requires the system spec to be stated formally

Intercept Proxies

  • get between the client and server
    • manipulate data
    • affect timing


  • he's running the OWASP BWA (bad web app), intercepting it using a BurpSuite proxy
  • devtools-like
  • allows submission of forms


  • included in Kali Linux
  • similar to BurpSuite, it intercepts
  • crawls the page, raises alerts
  • sql injection example

Reverse Engineering

  • extracting code from a binary
    • how?
      • decomposing
        • disassembler -- machine code from memory -> text string
        • decompiler -- deconstruct high-level code
        • debugger
      • obfuscating code
        • ? isn't this a way to protect against reverse engineering??
      • reverse engineering labs
        • put buggy code/malware in a sandbox for analysis
        • important to keep it away from the hypervisor and network
        • WANNACRY was defeated this way
          • it had a kill switch, which reached out to a nonexistent URL
          • researcher registered that domain/URL, which prevented the drive from being encrypted

Applying Best Practices of Secure Coding

  • goals
    • confidentiality
    • integrity
    • availability
  • attacker's goals
    • what the application can be made to do
  • client side UI offers no protection, because you can build your own requests
  • Java and Flash applets can be decompiled

Input Validation

  • identify all data sources
    • trusted/untrusted
    • validate all data from untrusted sources
    • centralized input validation routine
    • use proper character sets e.g. UTF-8 for all input sources
      • encode data using character set before validating
      • determine if the systems support UTF-8
    • all failures should result in input rejection
    • e.g. headers, urls, cookie name/values
    • include automated postbacks from JS, Flash, other embedded stuff (?)
    • headers must include only ASCII chars
  • validate data from redirects
    • an attacker to submit malicious content directly to the target, which could get around the application logic
  • validate expected data types, ranges, lengths
  • validate input against an approved list of allowed chars, if possible
  • implement additional controls, if you're going to need to allow special chars
    • secure task-specific APIs
    • output encoding
      • use a trusted system (your server)
      • standard tested routine for each type of outbound encoding
      • contextually output encoding
        • e.g. HTML entity encoding
      • encode all chars, unless we know they're safe for the intended interprter
      • contextually sanitize output, like XML, SQL, LDAP
      • sanitize all output of untrusted data to the operating system commands
    • account for utilization of that data throughout the application

Authentication and Password Management

  • authentication on all pages and resources, except public pages
  • auth should be forced on a trusted system
  • use standard, tested auth services
  • use a centralized authentication implementation
  • segregate auth logic from the resource being requested
    • use redirection from and to centralized auth
  • auth should fail securely
  • admin and account management should be at least as secure as the user auth
  • only store cryptographically strong, one-way, salted hashes of the passwords
    • ensure the table/file is writable only by the application
  • password hashing must be done on a trusted system (server)
  • validate auth data only on completion of all data's input
  • don't show which part of auth failed
  • error responses should be identical in both display and source code
  • use auth for connections to external systems, especially if there's sensitive info being transmitted
    • auth credentials should be encrypted and stored in a protected location on the trusted system
  • only use HTTP POST
  • send non-temporary passwords via encrypted connection
  • enforce password complexity and length requirements (more than 15 chars)
  • obscured passwords in input
  • enforce account disabling after ~5 attempts
    • interval of disablement, balance it between it becoming a DDoS for your site and allowing brute force
  • reset questions -- don't do pre-programmed ones or Googlable info
  • only send password reset to known emails
  • put a short expiration time on password resets
  • notify the use when a password reset occurs
  • force change of temporary password
  • stop password recycling
  • password must be at least one day old before resetting
  • enforce password refreshes
  • disable "remember me?"
  • report the last use of the account to the user at their next login
  • monitor to identify attacks against mupltiple accounts, like using the same password
  • change vendor-supplied password/user IDs, or disable those accounts
  • use multi-factor auth for high-value accounts
  • re-authenticate for critical operations
  • inspect third-party code carefully

Session Management

  • use the server/framework's management controls
  • session ID should be created on trusted system
  • session algos should be well-vetted
  • set domain/path for cookies containing the session identifiers to a restricted value for the site
  • logout should fully terminate associated session and its connection, as well as access to protected pages
  • make session as short as possible
  • don't allow persistent logins, enforce periodic session terminations, especialy sensitive info-containing apps
  • if session is established before login, close it and establish a new one after login
  • if there's re-auth, create a new session identifier
  • if there's a user ID currently logged in, don't allow concurrent logins
  • hide session identifiers in URL
    • should only be located in HTTP cookie header
  • protect server side session data
    • by ipmlementing appropriate access controls on the server
  • create new session ID if HTTP->HTTPS switch or vice versa
    • better to only use HTTPS
  • use strong random per-session tokens/params
    • OR per-request strong random tokens/params
  • set the "secure" attribute on cookies
  • set cookies with HttpOnly attribute

Access Control

  • use only trusted system objects, e.g. a server-side session object, for auth
  • use a single site-wide component to check access authorization
  • access control should fail securely
  • deny all access if the application can't access its security configuration
  • enforce auth controls on every request, including server-side scripts OR requsets from client-side things like AJAX
  • isolate privileged logic from other application code
  • restrict access to authorized users
    • files or other resources,
    • protected URLs
    • protected functions
    • direct object references
    • services
    • application data
    • configuration information esp. security-related, including those outside the application's control
    • policy information used by access controls
  • if there's state data on the client side, use encryption and integrity checks on the server side to catch state changes
  • enforce application logic flows to comply with business rules
  • limit the number of transactions a user/device can perform within a specific time period
    • balance between preventing automated attacks and useability
  • maybe use a "referrer" header as a supplemental check, not by itself -- can be spoofed
  • if you allow long auth sessions, re-validate periodically to make sure thier privileges haven't changed
    • if they have, log them out
  • implement account auditing, disable unused/retired accounts
  • use the least privilege theory when possible for eaccessing third party systems (?)
  • create an access control policy

Cryptographic Practices

  • all cryptographic functions to protect secrets must be used on trusted systems
  • protect master secrets from unauthorized access
  • crypto modules should fail securely
  • make sure random numbers are generated using a vetted/approved library
    • should be compliant to FIPS 140-2
  • establish policy for managing crypto keys

Error Handling and Logging

  • don't disclose sensitive info in error responses
    • e.g. debugging, stack trace
    • use generic errors
  • the app should handle application errors, don't rely on server configuration
  • free allocated memory when an error occurs
  • deny access by default when there's an error
  • logging controls should be on trusted system
  • log should contain success and failure
  • log important event data
  • restrict log access
  • use a master routine for all logging operations
  • don't store sensitive info in the logs
  • ensure there's a mechanism to go through and look at the logs
  • validate log entry's integrity using a hash function
  • log
    • input validation failures
    • auth failures
    • tampering events, including unexpected changes to state
    • attempts to connect with invalid/expired tokens
    • log system exceptions
    • changes to admin settings, especially security-related
    • TLS connection failures
    • cryptographic module failures

Data Protection

  • least privilege -- restrict users only to the functionality they need to do their jobs
  • protect cached/temporary copies of sensitive data from unauthorized access
    • purge them when no longer required
  • encrypt sensitive data, including on the server
  • prevent source code download
  • don't store passwords non-securely
  • remove comments from production code that might reveal sensitive info
  • remove unnecessary applications/system docs (?)
  • don't include sensitive info if you use HTTP GET
  • disable autocomplete on forms
  • disable client-side caching
  • support removal of sensitive data in app
  • access controls for data stored on the server
    • cached data, temp files, data that should be accessible only by specific system users

Communication Security

  • use TLS for sensitive info, including connections to external systems
  • TLS certs should not be expired, and have the correct domain
  • no TLS fallback, just fail
  • DevSecOps
    • apply principle of least privilege
    • use threat modeling and other techniques at the start of the project and throughout the lifecycle
  • use a single TLS implementation
    • stipulate character encoding
  • filter sensitive info in parameters from the HTTP referrer

System Configuration

  • use the latest versions of server, frameworks
    • patched
  • disable directory listings
  • restrict web server, process, and service accounts (least privileged)
  • when an excepotion occurs, make sure it fails securely
  • remove all unnecessary functions and files
  • remove test code
  • robots.txt
    • prevent disclosure of your directory structure
      • place directories in disallowed parent dir, then disallow the parent dir in robots.txt instead of one at a time
  • define which HTTP methods the application supports
    • and whether it'll be handled differently on different pages
  • make sure multiple HTTP versions are handled in a similar manner (?) e.g. 1.0, 1.1
  • remove unnecessary info from the responder header related to the OS, server version, application framework
    • you can use software to spoof other things
  • security configuration store needs to be human-readable
  • implement asset management system and register system components and software in that system
    • that way you can know about any changes that take place, and whether you allowed it
  • isolate dev and prod environments, use virtualization
    • allow access only to authorized groups
      • sometimes dev environments are less secure
  • implement a software control system

Database Security

  • strong, typed parametrized queries
    • keep query and data separate using placeholders -- use prepared statements
  • input validation (as before), output encoding
    • don't run db commanbd if they fail
  • least privilege for db access
  • secured credentials for db access
  • connection strings shouldn't be hardcoded, but stored in a separate file on trusted system, and encrypted
  • use stored procedures to abstract data access
  • allow removal of permissions to tables
  • unused connections should be removed asap
  • change default db credentials
  • use multi-factor auth for admin db access
  • disable unnecessary functions
  • don't install all DB features
  • remove sample vendor content
  • review accounts on DB, disable defaults
  • application should connect to the DB with different credentials for every "trust distinction"

File Management

  • don't pass user-supplied data to any dynamic "include" function
  • require auth before allowing file upload
  • limit file types for upload
  • validate uploaded files by checking the file headers
  • don't save the files in the same context -> database or file content server
  • limit files that could be interpreted automatically by the server
  • turn off execution privileges on files uploaded to a dir
  • implement safe uploading on Unix by mounting a target file dir as a launchable drive using the associated path/chrooted environment
  • use a white list of file types
  • don't pass user-supplied data into a dynamic redirect
    • if you have to, the redirect should only accept validated relative path URLs
  • don't pass directory/file paths; use index values mapped to a predefined list of paths
  • don't send an absolute path to the client
  • make sure application files and resources are read-only
  • scan the file a user uploads for virus/malware

Memory Management (?)

  • input/output controls for untrusted data
  • buffer should be as large as specified
  • if the destination buffer size is equal to the source buffer size, it may not null terminate the stream (?)
  • check the buffer boundaries if calling it in a loop
  • make sure there's no danger of writing past the allocated space
  • truncuate input streams to a reasonable length before passing them to copy/concat function
  • don't rely on garbage collection
    • explicitly close resources
      • connections
      • objects
      • file handles
  • use non-executable stacks when possible
  • avoid known vulnerable functions like strcat, strcopy, prntif (?)
  • free the RAM

General Coding Practices

  • use tested and approved managed code instead of reinventing the wheel
  • use task-specific built-in APIs to conduct OS tasks
    • don't allow the application to issue commands directly to the OS, especially through application-intended command shells
  • use checksums/hashes to verify the integrity of the interpreted code, libraries, executables, config files
  • use locking to prevent multiple simultaneous requests, prevent race conditions
  • protect shared variables and resources from inappropriate concurrent access (?)
  • explicitly initialize all variables/data stores during declaration or just before first usage (?)
  • raise privileges needed by application as late as possible and terminate soon after
  • understand math calc in your language: byte size discrepancies, signed and unsigned distinctions, truncations, large and small numbers
  • don't pass user-supplied data to any dynamic execution function
  • restrict users from generating new code/altering existing code
  • review all secondary apps/code/libraries
  • implement safe updating
    • use and verify cryptographic signatures for your code
  • use TLS to transfer code to server

Cloud Computing

Service Oriented Architecture (SOA) and Microservices

  • closely mapped to business workflows
  • contains sub-services optionally
  • "unknown environment"
    • customers don't need to know how it works, just what it does and how to access
  • self-contained
    • doesn't rely on state of other services, exposes a clear input/output interface
  • allows application components to communicate over different protocols
  • allows integration of services from different vendors
  • parallels with
    • Unix Philosophy (each tool should do one thing very well)
    • agile

API Connectivity Issues

  • API keys must be secured
  • communications should use HTTPS

SAML (security assertion markup language)

  • XML-based framework for exchanging security-related information
    • user auth
    • entitlement
    • attributes
  • often used with SOAP
  • allows us to take advantage of SSO (sign sign-on)
  • the info is communicated in the form of Assertions
    • contain info about any acts of auth
    • attribute assertions -- name, address, etc.
  • binding communications
    • bind to communication assertions over a network protocol

Infrastructure as Code (IoC)

  • allows us to create IT environments with a little bit of code
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment