Skip to content

NajiElKotob/Awesome-Secure-Coding

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

258 Commits

Resources

Resources

 
 

Acronyms-and-Definitions.md

Acronyms-and-Definitions.md

 
 

Code.md

Code.md

 
 

README.md

README.md

 
 

Report-Malicious-Software.md

Report-Malicious-Software.md

 
 

Repository files navigation

Awesome Secure Coding

~ Outlines are based on CertNexus CSC (Cyber Secure Coder) Secure coding is a set of practices that applies security considerations to how software will be coded and encrypted to best defend against cyber attack or vulnerabilities. [NTT Security AppSec Solutions]

{Awesome Works in Progress}

  1. Identifying the Need for Security in Your Software Projects
  2. Handling Vulnerabilities
  3. Designing for Security
  4. Developing Secure Code
  5. Implementing Common Protections
  6. Testing Software Security
  7. Maintaining Security in Deployed Software
  8. References

1. Identifying the Need for Security in Your Software Projects

1.1. Identify Security Requirements and Expectations

1.2. Identify Factors That Undermine Software Security

1.3. Find Vulnerabilities in Your Software

1.4. Gather Intelligence on Vulnerabilities and Exploits

2. Handling Vulnerabilities

2.1. Handle Vulnerabilities Due to Software Defects and Misconfiguration

  • Software Defects
  • Causes of Software Defects
    • Flaw in the design; Bugs; 3rd party code; Change in the context; ...
  • Guidelines for Preventing Security Defects
  • Preventing Security Defects
  • Problems in Third*Party Code
  • Problems in Standard Libraries
  • Dependencies
  • Encryption Validation
  • Security of Host Systems and Service Providers
  • Guidelines for Using Third*Party Code and Services
  • Host Platform Configuration
  • Hypervisor Vulnerabilities
  • Guidelines for Managing Vulnerabilities in External Hosts and Services
  • Identifying Vulnerabilities in a Software Project
  • Examining the Project Files
  • Error Messaging
  • Error Handling
  • Fail-Safe | A system or plan that comes into operation in the event of something going wrong or that is in place to prevent such an occurrence.
  • Failure Recovery
  • Guidelines for Secure Error Handling
  • Identifying Software Defects and Misconfiguration

2.2. Handle Vulnerabilities Due to Human Factors

  • The Human Element in Software Security
  • Vulnerabilities Attributed to the Human Element
  • Social Engineering Attacks
  • User Input
  • Input Validation
    • Input Validation Cheat Sheet - owasp.org
      • Syntactic validation should enforce correct syntax of structured fields (e.g. SSN, date, currency symbol).
      • Semantic validation should enforce correctness of their values in the specific business context (e.g. start date is before end date, price is within expected range).
      • Tools
    • Blacklist vs Whitelist
  • Security Policy Enforcement
  • Guidelines for Managing People Risks
  • Managing People Risks

2.3. Handle Vulnerabilities Due to Process Shortcomings

  • Development Process Approaches
  • Building Security In
  • The CIA Triad
  • Requirements Phase
  • Design Phase
  • Development Phase
  • Testing Phase
  • Security Testing Tools
  • Deployment Phase
  • Maintenance Phase
  • Development Process Security
  • Guidelines for Software Development Processes
  • Managing Software Development Process Risks

3. Designing for Security

3.1. Apply General Principles for Secure Design

  • Security in the Design Phase
    • ~50% of software security issues are due to design flaws
    • The design phase refers to functions typically performed by a software architect (strategic design of the entire system)
    • Integrate security into every phase of your development process
  • Security by Obscurity vs. Security by Design
    • Open-source and the “security through obscurity” fallacy - efrontlearning.com
    • National Institute of Standards and Technology (NIST) specifically recommends against using closed source as a way to secure the software (i.e. “security through obscurity”)
    • Hiding source code is a bad way to assume you’ll achieve security, because even a powerful and highly proprietary company can’t guarantee that source code won’t leak out.
  • OWASP Security Design Principles ⭐
    • Secure Design Principles - OWASP
      • Minimize attack surface area learn more
      • Establish secure defaults
      • Least privilege
      • Defense in depth (aka layered defense)
      • Fail securely
      • Don't trust services
      • Separation of duties (aka separation of privilege)
      • Avoid Security by Obscurity
      • Economy of Mechanism (Keep It Simple, Stupid "KISS")
      • Fix security issues correctly
  • Software Design Patterns
    • In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. learn more
  • Security Patterns
  • Modular Design
  • Benefits of Modular Design
    • Small manageable tasks; Reduce errors; Resuse; Maintainability
    • With a modular design, the parts do not always add up to the whole. Even though each module is essentially secure, the system as a whole may not be secure due to the complexity of interactions between modules.
  • The Balance Between Defense in Depth and Simplicity
    • KISS (“Keep It Simple Security“)
    • The last layer of defense for your deployment should be the ability to respond quickly.
  • Guidelines for Avoiding Common Design Mistakes - synopsys.com
    • Avoiding Common Security Design Flaws
      • Earn or give, but never assume, trust. - ieee.org
      • Use an authentication mechanism that cannot be bypassed or tampered with.
      • Authorize after you authenticate.
      • Strictly separate data and control instructions, and never process control instructions received from untrusted sources.
      • Define an approach that ensures that all data are explicitly validated.
      • Use cryptography correctly.
      • Identify sensitive data and how they should be handled.
      • Always consider the users.
      • Understand how integrating external components changes your attack surface.
      • Be flexible when considering future changes to objects and actors.

3.2. Design Software to Counter Specific Threats

4. Developing Secure Code

4.1. Follow Best Practices for Secure Coding

  • Development Documentation and Deliverables
  • Application and Data Integrity
  • Common General Programming Errors
    • Inappropriate use of dangerous functions, APIs, and system calls
    • Use of deprecated libraries
    • Buffer overruns
    • Race conditions
    • Integer range issues
    • Out of bounds array indexing
    • Unhandled exceptions
    • Memory leaks
    • Dangling and null pointer references
    • Unused code
    • Uninitialized variables
    • Injection vulnerabilities
  • Insecure Deserialization
  • Guidelines for Secure Coding
  • Researching Your Secure Coding Checklist
  • Buffer Overrun Defects
  • Buffer Overflows
  • Guidelines to Prevent Buffer Overflow Defects
  • Buffer Overreads
  • Guidelines to Prevent Buffer Overread Defects
  • Integer Overflows
  • Guidelines to Prevent Integer Overflow Defects
  • Uncontrolled Format Strings
  • Insecure Output Encoding
  • XXE Attacks
  • Guidelines to Prevent Uncontrolled Format String Defects
  • Race Condition
  • Impact of Race Conditions on Threading/Multiprocessing
  • Guidelines to Prevent Race Condition Defects
  • Performing a Memory*Based Attack

4.2. Prevent Platform Vulnerabilities

  • OWASP Top Ten Platform Vulnerabilities
  • Authentication
  • Authorization
  • Broken Authentication
  • Guidelines to Prevent Web Vulnerability Defects
  • Guidelines to Prevent Mobile App Vulnerability Defects
  • Guidelines to Prevent Internet of Things Vulnerability Defects
  • Desktop Application Vulnerabilities
  • DLL Injection
  • Shellcode Injection
  • Debugger Security
  • Differences Among Desktop Platforms
  • Managed vs. Unmanaged
  • Desktop Application Attack Vectors
  • Development Tool and Project Configuration
  • Guidelines to Prevent Desktop Application Vulnerabilities
  • Finding Common Web Vulnerabilities Topic C: Prevent Privacy Vulnerabilities
  • Privacy Vulnerability Defects
  • Privacy by Design
  • Data Anonymization
  • Guidelines to Prevent Privacy Vulnerability Defects
  • Handling Privacy Defects

4.3. Prevent Platform Vulnerabilities

5. Implementing Common Protections

5.1. Limit Access Using Login and User Roles

  • Web Sessions
  • Secure Session Management
  • Methods for Passing Session IDs
  • Access Control
  • Guidelines for Secure Session Management
  • User Provisioning
  • Password Recovery
  • Account Lockouts
  • Guidelines for Secure Password Management
  • Handling Authentication and Authorization Defects

5.2. Protect Data in Transit and At Rest

  • Encryption
  • Uses for Encryption
  • Cryptographic Lifecycle
  • Symmetric Encryption
  • Asymmetric Encryption
  • Hashing
  • Digital Signatures
  • Digital Signature Non*repudiation
  • Digital Certificates
  • PKI
  • PKI Components
  • The PKI Process
  • Key Management
  • Key Management Factors
  • Certificate Revocation
  • Guidelines for Protecting Data in Transit and at Rest
  • Protecting Data in Transit and at Rest

5.3. Implement Error Handling and Logging

  • Error Handling
  • Uses for Error Handling
  • Error Messaging
  • Logging
  • Guidelines for Implementing Error Handling and Logging
  • Reviewing Error Handling
  • Improving Error Handling

5.4. Protect Sensitive Data and Functions

5.5. Protect Database Access

  • Case Study: SQL Injection Defect
  • Query Parameterization
  • Database Connection Credential Protection
  • Guidelines for Protecting Database Access
  • Protecting Database Access

6. Testing Software Security

6.1. Perform Security Testing

  • The Role of Testing
    • Test early and test often.
    • View software design and implementation from an attacker's perspective.
    • Think of threat modeling as a form of testing (Testing the design).
    • Mindsets; penetrate and patch, penetrate and improve, building security in
  • Phases of Software Testin
  • Development Testing
    • Separation of duties (SoD; also known as Segregation of Duties) is the concept of having more than one person required to complete a task.
    • Dynamic analysis is the testing and evaluation of an application during runtime. Static analysis is the testing and evaluation of an application by examining the code without executing the application. Learn more
  • Unit Testing
    • Input Validation; Output Encoding; Session Management (A&A); Encryption; Error Handling; Logging
  • Integration Testing
    • White box testing (Source Code); Gray box testing; Black box testing
  • Documentation and Deliverables for Testing
    • Input: Business requirements; SRS; Threat Models; Data flow Diagram
    • Output: Vulnerability Reports; Quality Assurance Reports
  • Manual Inspection and Code Review
    • Security Analysis | A detailed process to ensure that software operates at a level of security consistent with the potential harm that could result from the loss, inaccuracy, alteration, unavailability, or misuse of the data and resources that it uses, controls, and protects.
    • Looking at your code from a different perspective will find problems or ask questions that you haven't considered.
  • Code Review Strategies
    • Formal
      • Fagan Inspection | A formal analysis process that includes a series of structured activities involving multiple participants and phases—such as planning, inspection, rework, and verification. The objective is to reveal defects in programming code.
    • Informal
      • Over the wall (aks Pass Around)
      • Over the shoulder
      • Pair Programming
  • Guidelines for Security Testing
    • Performing Manual Inspection and Review
      • Web Server e.g., dotnet new web; dotnet watch
      • IP Address e.g., MVC - Block IP Address Using Action Filter
      • Query String (Whitelist, Length, Data type)
      • Authentication e.g., Authorize, AllowAnonymous
      • Directory browsing

6.2. Analyze Code to find Security Problems

  • Static Code Analysis
    • Static Code Analysis | The process of using a computer program to find problems in code, without actually executing the code.
  • Strategies for Using Static Analysis
  • Dynamic Code Analysis
  • Guidelines for Code Analysis
  • Performing Code Analysis

6.3. Use Automated Testing Tools to Find Security Problems

  • Automated Testing
  • Unit Testing
  • Guidelines for Using Automated Testing Tools
  • Using a Test Suite to Automate Unit Testing

7. Maintaining Security in Deployed Software

7.1. Monitor and Log Applications to Support Security

7.2. Maintain Security after Deployment

YouTube 📺

Tools

Articles

Magazines

  • LHN - latesthackingnews.com

Acronyms and Definitions

References

Monitoring

Cases

Learning

Articles

About

Awesome Secure Coding

Resources

Readme
Activity

Stars

13 stars

Watchers

2 watching

Forks

5 forks
Report repository

Releases

No releases published

Packages

No packages published

Contributors 2

  •  
  •