Flashcards
Software Security Concepts 2
Cards in this deck (41)
- 1Software QualityPractice that describes the desirable attributes of software products. Its main focus is reliability, which is related not to the number of bugs, but how often are they triggered
- 2BufferA memory storage region that temporarily holds data while it is being transferred from one location to another
- 3StackLinear data structure, within the computer's memory, that temporarily stores methods, local variables and reference variables. When the computing task is complete, the memory of the variable will be automatically erased
- 4HeapHierarchical data structure, within the computer's memory, that stores global variables. It supports dynamic memory allocation
- 5Buffer OverflowA program anomaly that occurs when data is written outside of the boundaries of the memory allocated to a particular data structure. It causes adjacent memory locations to be overwritten
- 6Stack-Based Buffer OverflowThe most common type of buffer overflow. It leverages stack memory that only exists during the execution time of a function
- 7Heap-Based Buffer OverflowA more difficult version of buffer overflow. It involves flooding the memory space allocated for a program beyond memory used for current runtime operations
- 8CanaryDefense method against buffer overflow. It pushes an extra random value onto the stack between local variables and return address. If a buffer overflow occurs, the first data to be corrupted is the canary. A failed verification of the canary data will therefore alert of an overflow
- 9RAD (Return Address Defender)Defense method against buffer overflow. The return address is copied to another place and it is checked before return. This does not alter the stack frame relatively to the expected
- 10ASLR (Address Space Layout Randomization)Defense method against buffer overflow. The stack, heap and global data are stored in random addresses each time the process is loaded. Attackers can no longer learn where their target is through trial and error, because the address will be different every time
- 11Non-Executable Address SpacesDefense method against buffer overflow that prevents execution on memory pages allocated for stack and heap
- 12Guard Memory PagesDefense method against buffer overflow that interleaves non-valid memory addresses between valid ones
- 13CanonicalizationMethod that reduces the input to its simplest equivalent known form. For example, converts case insensitive strings to all lower case
- 14NormalizationMethod that converts the input to a standard form (not necessarily the simplest). For example, using a standard form of Unicode
- 15SanitizationThe process of ensuring that data does not violate the security policy. It applies to both input and output. It often converts valid but insecure input into invalid. For example, prevents the user from inputting JavaScript or SQL
- 16ValidationThe process of checking inputs to ensure that they fall within the intended input domain of the receiver. It prevents errors by disallowing invalid inputs, however it does not modify the input. For example, checks if a person's name contains symbols or digits
- 17Regular ExpressionExpression that specifies the valid input model. For example, validates an image file name for a set of formats, like jpeg, jpg, gif or png
- 18Input FuzzingA powerful testing method that uses a large range of randomly generated inputs to test whether a program/function correctly handles abnormal inputs. It is simple, free of assumptions and assists with reliability, as well as security. However, it can take a lot of time. It is also capable of using templates to generate classes of known inputs that can be a problem
- 19Injection AttackA type of attack caused by invalid input that is wrongly interpreted and leads to unintended execution of some part of the program. It is often passed as a parameter to another powerful program, utility or subsystem, most often in scripting languages like SQL
- 20Object SerializationThe process of putting the relevant state of the object into a streamable representation. That can mean converting it to a byte stream
- 21Object DeserializationThe process of restoring an object from a serial representation and ensuring its invariants. Deserialization of untrusted data can lead to exploits. If an attacker knows the serialized layout of objects or object trees, he can manipulate the serialized representation of the object. This can lead to DoS attacks, visualization of sensitive data, falsification of data or execution of gadget code
- 22Race ConditionThis exploit occurs when an assumption needs to hold true for a period of time, but actually may not. Whether it does is a matter of exact timing. There is always a window of vulnerability. That is, there is a period of time when violating the assumption leads to incorrect behavior
- 23TOCTTOU (Time-of-Check to Time-of-Use)A type of race condition. It occurs when there is a window of vulnerability between checking a resource for use and effectively using it. In that window of time, it’s possible that the resource changes making the checked condition invalid
- 24Dirty COW (Copy-on-Write)A type of race condition that affected the Linux kernel. It results from lack of indivisibility in write() function on Copy-on-Write pages. In this case, write() performs three things: it makes a copy of the memory page, it changes the page table of the process to point to it, and it writes to the memory. In recent kernels, the code of write() is now indivisible which makes a single critical section
- 25Threat ModelingA technique used to identify the attacks a system must resist and the defenses that will bring it to a desired defensive state. It assesses security risks of a software system from an adversary’s perspective. It identifies, communicates and understands threats and mitigations to reduce the risk to an acceptable level
- 26Alternatives to Threat ModelingStatic analysis of code, Dynamic analysis like input fuzzing, Penetration testing, Production bugs reports, Incident response
- 27Goals of Threat ModelingConception of a secure design from the start.
Documentation of threats and mitigations.
Shared understanding of threats spread to all of the development team.
Threats to guard against are included in the requirements.
Creation of security mechanisms to include in the design.
More efficient effort management.
Basis for prescribing secure implementation practices.
Basis for testing system security after implementation - 28How to Create a Threat Model What are we building?Understand the system, description and architecture.
Assets, data flows, processes, people and roles.
Drilldown details - 29How to Create a Threat Model What can go wrong?Identify threats and assumptions that apply to the system's scope.
Use databases of attacks, adversary tactics and techniques.
Create attack trees - 30How to Create a Threat Model What are we going to do?Turn findings into actions.
Prioritize risks and mitigate using security mechanisms - 31How to Create a Threat Model Did we do a good enough job?Test
Log
Monitor - 32DFD (Data Flow Diagram)Visual and hierarchical model of how a system processes data. Level 0 models all system in a high-level view, while level 1 models sub-systems, drilldown high-level views
- 33Trust BoundaryUsed in DFD diagrams. It intersects data flows and must be made explicit for threat boundaries since many ties are ignored when specifying architecture only. It occurs everywhere two (or more) principals (OS users, processes in different systems, user roles, different apps on mobile, database identities, …) interact. Processes talking through a network always have a trust boundary between them. Threads inside the same process are inside the same boundary. They share the same privileges, access rights, and identifiers
- 34STRIDE Threat ModelWhen threat modeling, one must be aware of the main possible threats: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
- 35Spoofing IdentityThis type of threat allows an attacker to pose as another user or allows a rogue server to pose as a valid server. It can be mitigated through the use of authentication
- 36Tampering with DataThreat that involves malicious modification of data. Can be mitigated with the guarantee of integrity and permissions
- 37RepudiationThreat associated with users who deny performing an action without other parties having any way to prove otherwise. Can be mitigated through fraud prevention, logging and signatures
- 38Information DisclosureThreat that involves the exposure of information to individuals who are not supposed to have access to it. Can be mitigated using permissions and encryption
- 39DoS (Denial of Service)Attack that denies service to valid users by making the system unavailable or unusable. Can be mitigated with the assurance of availability
- 40Elevation of PrivilegeAn unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the system. Can be mitigated with authorization and isolation
- 41Attack TreeA branching, hierarchical data structure that represents a set of potential vulnerabilities. It is used to effectively exploit the information available on attack patterns. Security analysts can use it to guide design and strengthen countermeasures
Information
- Description
- Mestrado Segurança Informática Flashcards on Software Security Concepts 2, created by Inês Macedo on 13/06/2021.
- Created by
- Inês Macedo
- Views
- 0
- Rating