CompTIA Security+ (SY0-601): Secure Software Development
This section explains the structured process of developing secure software through various SDLC phases, including planning, design, implementation, and maintenance. It contrasts traditional waterfall with Agile and DevOps methodologies and emphasizes key security principles such as defense in depth and never trusting user input to enhance application security.
SDLC
Software Development Life Cycle:
An organized process of developing a secure application throughout the life of the project
Waterfall Model
Project Planning > Requirements > Analysis > Design > Coding > Testing > Deployment
Key Terms
SDLC
Software Development Life Cycle:
An organized process of developing a secure application throughout the life of the p...
SDLC Phases
Planning & Analysis
Software/Systems Design
Implem...
Agile
Software development is performed in time-boxed or small increments to allow more adaptivity to change
DevOps
Software development and information technology operations
SDLC Principles: Defense in Depth
Layering of security controls is more effective and secure than relying on a single control
SDLC Principles: Never Trust User Input
Any input that is received from a user should undergo input validation prior to allowing it to be utilized by an applica...
Related Flashcard Decks
Study Tips
- Press F to enter focus mode for distraction-free studying
- Review cards regularly to improve retention
- Try to recall the answer before flipping the card
- Share this deck with friends to study together
| Term | Definition |
|---|---|
SDLC | Software Development Life Cycle: Waterfall Model |
SDLC Phases | Planning & Analysis Software/Systems Design Implementation Testing Integration Deployment Maintenance |
Agile | Software development is performed in time-boxed or small increments to allow more adaptivity to change |
DevOps | Software development and information technology operations |
SDLC Principles: Defense in Depth | Layering of security controls is more effective and secure than relying on a single control |
SDLC Principles: Never Trust User Input | Any input that is received from a user should undergo input validation prior to allowing it to be utilized by an application |
SDLC Principles: Minimize Attack Surface | Reduce the amount of code used by a program, eliminate unneeded functionality, and require authentication prior to running additional plugins |
SDLC Principles: Create Secure Defaults | Default installations should include secure configurations instead of requiring an administrator or user to add in additional security |
SDLC Principles: Authenticity & Integrity | Applications should be deployed using code signing to ensure the program is not changed inadvertently or maliciously prior to delivery to an end user |
SDLC Principles: Fail Securely | Applications should be coded to properly conduct error handling for exceptions in order to fail securely instead of crashing |
SDLC Principles: Rely on Trusted SDKs | SDKs must come from trusted source to ensure no malicious code is being added |
Black-box Testing | Occurs when a tester is not provided with any information about the system or program prior to conducting the test |
White-box Testing | Occurs when a tester is provided full details of a system including the source code, diagrams, and user credentials in order to conduct the test |
Gray-box Testing | (Combination of Black & White-box) The tester partially understands the application’s internal working structure |
Structured Exception Handling (SEH) | Structured Exception Handling: Provides control over what the application should do when faced with a runtime or syntax error |
Input Validation | Applications verify that information received from a user matches a specific format or range of values |
Static Analysis | Source code of an application is reviewed manually or with automatic tools without running the code |
Dynamic Analysis | Analysis and testing of a program occurs while it is being executed or run |
Fuzzing | Injection of randomized data into a software program in an attempt to find system failures, memory leaks, error handling issues, and improper input validation |
Backdoors | Code placed in computer programs to bypass normal authentication and other security mechanisms Backdoors are a poor coding practice and should not be utilized |
Directory Traversal | Method of accessing unauthorized directories by moving through the directory structure on a remote server |
Arbitrary Code Execution | Occurs when an attacker is able to execute or run commands on a victim computer (not remotely) |
RCE | Remote Code Execution: Occurs when an attacker is able to execute or run commands on a remote computer |
Buffer Overflow | Occurs when a process stores data outside the memory range allocated by the developer |
Buffer | A temporary storage area that a program uses to store data Over 85% of data breaches were caused by a buffer overflow |
Stack | Reserved area of memory where the program saves the return address when a function call instruction is received |
"Smash the Stack" | Occurs when an attacker fills up the buffer with NOP so that the return address may hit a NOP and continue on until it finds the attacker’s code to run |
Address Space Layout Randomization | Method used by programmers to randomly arrange the different address spaces used by a program or process to prevent buffer overflow exploits |
XSS (3 Types) | Cross-Site Scripting: Stored/Persistent Reflected DOM-based Prevent XSS with output encoding and proper input validation |
XSRF/CSRF | Cross-Site Request Forgery: One domain is forging a request to another to modify a value Example: You're on a website and click a link to an external site, but it deletes your account on the original site Prevent XSRF with tokens, encryption, XML file scanning, and cookie verification |
SQL Injection | Attack consisting of the insertion or injection of an SQL query via input data from the client to a web application SQL injection is prevented through input validation and using least privilege when accessing a database If you see ` OR 1=1; on the exam, it’s an SQL injection |
Injection Attack | Insertion of additional information or code through data input from a client to an application SQL Most common type is an SQL injection |
XML Vulnerabilities | XML data submitted without encryption or input validation is vulnerable to spoofing, request forgery, and injection of arbitrary code |
XML Bomb (Billion Laughs Attack) | XML encodes entities that expand to exponential sizes, consuming memory on the host and potentially crashing it |
XML Eternal Entity (XXE) | An attack that embeds a request for a local resource To prevent XML vulnerabilities from being exploited, use proper input validation |
Race Conditions | A software vulnerability when the resulting outcome from execution processes is directly dependent on the order and timing of certain events, and those events fail to execute in the order and timing intended by the developer A race condition vulnerability is found where multiple threads are attempting to write a variable or object at the same memory location |
Race Conditions: Dereferencing | A software vulnerability that occurs when the code attempts to remove the relationship between a pointer and the thing it points to. Race conditions are difficult to detect and mitigate |
Time of Check to Time of Use (TOCTTOU) | The potential vulnerability that occurs when there is a change between when an app checked a resource and when the app used the resource |
Preventing Race Conditions/TOCTTOU | Develop applications to not process things sequentially if possible Implement a locking mechanism to provide app with exclusive access |
Design Vulnerabilities: Insecure Components | Any code that is used or invoked outside the main program development process Code Reuse |
Design Vulnerabilities: Insufficient Logging/Monitoring | Any program that does not properly record or log detailed enough information for an analyst to perform their job Logging and monitoring must support your use case and answer who, what, when, where, and how |
Design Vulnerabilities: Weak of Default Configurations | Any program that uses ineffective credentials or configurations, or one in which the defaults have not be changed for security Many applications choose to simply run as root or as a local admin Utilize scripted installations and baseline configuration templates to secure applications during installation |
LDAP Injections | LDAP typically stores authentication info (user/pass) Example: Manipulated Query |
SSL Stripping/HTTP Downgrade | Combines an on-path with a downgrade attack (attacker sits between client/server) Attacker modifies data between victim & web server Done via: Proxy server, ARP spoofing, or rogue AP |
Dead Code | Section of source code of a program which is executed but whose result is never used in any other computation. |
OWASP | Open Web Application Security Project: |