Secure Coding Practices

Wyatt Hooper, Victor Kumar, Ethan Rice, and Landan Shelton

Secure Coding Practices – A Definition
Secure coding is the principles of designing code that adheres to secure coding best
practices, safeguarding and protecting published code from known, unknown, and
unexpected vulnerabilities such as security exploits, the loss of cloud secrets, embedded
credentials, shared keys, confidential business data and personally identifiable
information.
The Four Pillars of Software Security
1. Knowledge and awareness
- Every employee needs a degree of knowledge and awareness to make good decisions.
The employee’s lack of knowledge might result in devastating cybercrime. The
organization head’s lack of knowledge might result in disastrous decisions regarding
information technology and security.
- Includes:
- Legal requirements
- Organization internal rules (written policies, procedures, etc.)
- Privacy threats
The Four Pillars of Software Security
2. Protection of computing devices
- Computing devices need to be secure. This includes smartphones, tablets, laptops,
desktops, servers, networking devices, etc.
- Includes
- Inventorying all devices, as well as a process to commission them and decommission them
- Ensuring physical security and control over the devices
- Proper configuration of devices
- Updating of devices
- Malware protection
- Controlled access of devices
The Four Pillars of Software Security
3. Protection of data
- Data needs to be protected from data breaches, and available when needed. Certain
data breaches could trigger reporting requirements.
- Includes
- Inventory data (to a reasonable degree)
- Securing cloud accounts properly with complex, unique passwords as well as a second factor of
authentication (such as 2FA)
- Delete unneeded data
- Backup data regularly
The Four Pillars of Software Security
4. Protection of networks and safe use of the Internet
- Data is flowing constantly between internal devices and through the Internet.
- Includes:
- Routers and switches are securely configured, including unique (and non-default) passwords, keeping
them updated, and disabling unneeded features.
- Wi-Fi networks encrypted and require a strong password to join, and changing the password
periodically.
- Avoid or minimize use of public networks.
- Encrypting data in transit whenever practical.
Why is Secure Coding Important?
It demonstrates a shift in responsibility by naming the developer as responsible for the
code security rather than a security team. It introduces an abstraction layer that scans
existing code and any new code as it is committed into a code repository.
It helps enforce the best practices that, in turn, enforce production-ready code standards as
well as prevent human error and developers that cut corners to meet strict deadlines.
Risks of Insecure Coding
Insecure coding endangers customers using the company’s software, therefore also
damaging the company’s reputation. Includes many risks and will be discussed later. A
few examples:
- Injection errors
- Cross-Site Scripting (XSS)
- Authentication failures
- Misconfiguration of security
Software Assurance (SwA)
2 Definitions can be applied
1. The level of confidence that software functions as intended and is free of
vulnerabilities, either intentionally or unintentionally designed or inserted as part of
the software throughout the lifecycle.
2. The planned and systematic set of activities that ensure that software life cycle
processes and products conform to requirements, standards, and procedures.
OWASP SAMM
Open Worldwide Application Security Project – Software Assurance Maturity Model
SAMM is an open framework to help organizations formulate and implement a strategy
for software security that is tailored to specific risks facing the organization. SAMM
helps:
- Evaluate an organization’s existing software security practices.
- Build a balanced software security assurance program in well-defined iterations.
- Demonstrate concrete improvements to a security assurance program.
- Define and measure security-related activities throughout an organization.
Secure SDLC
Secure SDLC is the process of integrating security into the Software Development
Lifecycle. It results in security requirements being gathered alongside the functional
requirements, risk analysis being undertaken during the design phase, and security testing
happening in parallel with development.
It seeks to make security everybody’s responsibility, enabling software development that
is secure from its inception.
Microsoft SDL
Microsoft’s SDL introduces security and privacy considerations through all phases of the
development process, helping developers build highly secure software, address security
compliance requirements, and reduces development costs.
They do this with a series of practices.
Microsoft SDL Practices – 1
Provide Training
- Effective training will complement and re-enforce security policies, SDL practices,
standards, and requirements of software security, and be guided by insights derived
through data or newly available technical capabilities.
- Everyone should understand the attacker’s perspective and goals, rather than try to
make everyone a security expert.
Microsoft SDL Practices – 2
Define Security Requirements
- Security requirements should be continually updated to reflect the changes in
required functionality and changes to the threat landscape.
- Factors include legal and industry requirements, internal standards and coding
practices, reviews of previous incidents, and known threats.
Microsoft SDL Practices – 3
Define Metrics and Compliance Reporting
- Define the minimum acceptable levels of security quality early to hold engineering
teams accountable to meet that criteria. Defining them early helps the team
understand the risks associated with security issues, identify and fix security defects
during development, and apply the standards throughout the entire project.
Microsoft SDL Practices – 4
Perform Threat Modeling
- Can be applied at the component, application, or system level
- Allows the development team to consider, document, and (importantly) discuss the
security implications of designs in the context of their planned operational
environment and in a structured fashion.
Microsoft SDL Practices – 5
Establish Design Requirements
- Since the SDLC is typically thought of as assurance activities that help engineers
implement “secure features”, in that the features are well engineered with respect to
security.
- Engineers will typically rely on security features, such as cryptography,
authentication, logging, etc.
- It is crucially important that these are applied consistently and with a consistent
understanding of the protection those features provide.
Microsoft SDL Practices – 6
Define and Use Cryptography Standards
- A common way of ensuring data is protected is to use encryption.
- However, an incorrect choice in any aspect of cryptography can be catastrophic, and
best left to experts that can develop encryption standards.
- A good general rule is to only use industry-vetted encryption libraries, ensuring
they’re implemented in a way that allows them to be replaced if needed.
Microsoft SDL Practices – 7
Manage the Security Risk of Using Third-Party Components
- It’s important to understand the impact that a security vulnerability of a third-party
component impacts the larger system they are integrated in.
- Having an accurate inventory of third-party components and a plan to respond when
new vulnerabilities are discovered will go a long way toward mitigating the risk, but
additional validations should be considered.
Microsoft SDL Practices – 8
Use Approved Tools
- Define a publish a list of approved tools and their associated security checks, such as
compiler/linker options and warnings. Engineers should strive to use the latest
version of approved tools, such as compiler versions, and to take advantage of new
security analysis functionality and protections.
Microsoft SDL Practices – 9
Perform Static Analysis Security Testing (SAST)
- Analyzing the source code prior to compilation provides a highly scalable method of
security code review and helps ensure that secure coding policies are being followed.
- Typically integrated into the commit pipeline to identify vulnerabilities each time the
software is built or packaged
Microsoft SDL Practices – 10
Perform Dynamic Analysis Security Testing (DAST)
- Perform run-time verification of fully compiled or packaged software to check
functionality that will only be apparent when all components are integrated and
running.
- Typically done using a tool or suite of prebuilt attacks or tools that can specifically
monitor application behavior for memory corruption, use privilege issues, and other
critical security problems.
Microsoft SDL Practices – 11
Perform Penetration Testing
- Penetration testing is a security analysis of a software system performed by skilled
security professionals simulating the actions of a hacker.
- Objective is to uncover potential vulnerabilities resulting from code errors, system
configuration faults, or other operational deployment weaknesses.
- Usually finds the broadest variety of vulnerabilities
Microsoft SDL Practices – 12
Establish a Standard Incident Response Process
- Preparing an Incident Response Plan is crucial for helping to address new threats that
can emerge over time.
- The plan should include who to contact in case of a security emergency, and establish
the protocol for security servicing, which includes plans for code inherited from other
groups within the organization and for third-party code.
- Should be tested before it is needed.
SEI CERT
What is SEI?
- Founded in 1968, the Software Engineering Institute (SEI) is a Federally Funded Research and
Development Center (FFRDC) based at Carnegie-Mellon University. One of only 10 FFRDCs
sponsored by the U.S Department of Defense (DoD), the SEI conducts R&D in software engineering,
systems engineering, cybersecurity, and many other areas of computing, working to introduce private-
sector innovations into government.
What is SEI CERT?
- The Computer Emergency Response Team (CERT) is a division of the SEI which focuses on
improving the security and resilience of computer systems and networks. CERT is well respected for
its expertise and works closely with organizations from both private and public sectors.
SEI CERT Coding Standards
What are they?
- SEI CERT Coding Standards define best practices for proper use of features within specific languages
to avoid security flaws in software. Each standard provides detailed information and examples for
what to avoid as well as how to obtain desired results. SEI CERT Coding Standards are consistently
updated and available for C, C++, Java, Perl, Android OS.
- Although updates to the standards are coordinated and performed by CERT, their contents are
recognized as collective wisdom from the software development and software security communities.
Why do we need them?
- These standards reinforce secure software system development, acting as a preventative measure for
combatting security vulnerabilities caused by simple errors and incomplete understandings of features
used during software development.
- For platform flexibility and performance, programming languages such as C and C++ allow for
undefined, unspecified behavior, often causing developers to inadvertently add security flaws.
SEI CERT Coding Standards
How is it used in secure coding practices?
- Guidelines for secure coding practices in software development.
- Can be used as a baseline to create system specific coding standards.
- Reference guide for training and tool development and use.
- To assure compliance with security requirements and mandated regulations.
- Minimize technical debt.
- Integration with development processes.
- Establishes criteria for secure code review.
- Integrated with general coding standards.
SEI CERT C Coding Standard example
- STR32-C. Do not pass a non-null-terminated character sequence to a library function that expects a
string
SEI CERT C++ Coding Standard example
- MSC52-CPP. Value-returning functions must return a value from all exit paths.
Secure Code Review
What is it?
- Secure code review is the process of systematically examining software source code with the goal of
identifying and fixing security vulnerabilities.
- It is an integral part of development within the Secure SDLC, encompassing the processes involved in
the performance of security testing in parallel with software development and its resulting actions.

Focus: Methods/Tools:
- Authentication and Authorization - Static Analysis
- Data Validation - Dynamic Analysis
- Error Handling - Penetration Testing
- Session Management - Code Review Checklists
- Security Configuration - Manual Code Reviews
- Logging
- Encryption
Secure Code Review
Why do it?

- Identify security vulnerabilities early and often.

- Track vulnerabilities throughout the product life cycle and make determination of their impact and
priority, allowing implementation of solutions as deemed necessary.
- Minimize security exploits prior to software release.
- Industries such as healthcare, aerospace, and finance often mandate compliance with specified secure
code review practices.
- Iterative confirmation of compliance with specified secure coding standards.
- Minimize technical debt.
- Increased maintainability and pattern usage.
- Reinforce quality assurance.
Secure Code Review
Tasks:

- Planning
- Review Preparation
- Review Execution
- Issue Identification
- Issue Remediation
- Verification
- Documentation
MITRE
What is MITRE?

- Founded in 1958, MITRE is a non-profit company meant to serve as objective advisers in systems engineering to government
agencies, both military and civilian. Since 2014, MITRE has operated the nation’s first and only FFRDC dedicated to cybersecurity
and the advancement of secure technologies. MITRE has published a wealth of standards and knowledge relating to information
security, and is well respected within the industry.

What is CVE?

- Common vulnerabilities and exposures (CVE) is a database of specific instances of vulnerabilities identified within a specific product
or system.

What is CWE?

- Common Weakness Enumeration (CWE) is a community developed, categorized list of software and hardware vulnerabilities that
have been identified as the cause of flaws in systems and listed in a CVE. An encyclopedia of community recognized vulnerabilities.
Can be used as a secure coding standard.

MITRE Frameworks:

- These knowledge bases create the foundation for the development of system specific threat models and methodologies.
- ATT&CK, D3FEND, Engage, Caldera
IBM SPbD@IBM
What is IBM?
- Founded in 1911, International Business machines (IBM) is a global technology company that offers a
wide range of computer based products, services, and solutions.
What is SPbD@IBM?
- IBM Security and Privacy by Design (IBM SPbD@IBM) is a streamlined and agile set of focused
security and privacy practices which reinforces embedding security and privacy into the design of
products and services. SPbD@IBM is aligned with the United States National Institute of Standards
and Technology (NIST’s) Secure Software Development Framework (SSDF).
SEI CERT Top 10 Practices
What is it?
- A list of secure coding practices developed by the Software Engineering Institute (SEI).
- It provides a set of guidelines and recommendations to help developers write secure code
and prevent vulnerabilities.

How is it used in secure coding practices?

- These practices are used in secure coding practices by providing specific guidance on
how to address common security issues in software development.
- These practices are based on extensive research and analysis of real-world vulnerabilities,
making them a valuable resource for improving the security of software systems.
Top 10 Practices
1. Validate inputs
2. Heed compiler warnings
3. Architect and design for security policies
4. Keep it simple
5. Default deny
6. Adhere to principle of least privilege
7. Sanitize data sent to other systems
8. Practice defense in depth
9. Use effective quality assurance techniques
10. Adopt a secure coding standard
SEI CERT Practice 1
Validate Inputs:
- Validate inputs from all untrusted data sources.
- Proper input validation can eliminate the vast majority of software vulnerabilities.
- Be suspicious of most external data sources, including command line arguments,
network interfaces, environmental variables, and user controlled files.

Example: When processing user input from sources like command line arguments, always
verify the data’s integrity and format. This prevents common security risks such a
injection attacks.
SEI CERT Practice 2
Heed Compiler Warnings:
- Compile code using the highest warning level available for your compiler and
eliminate warnings by modifying the code.
- Use static and dynamic analysis tool to detect and eliminate additional security flaws.

For example: You’re coding and compiling with GCC. The compiler warns about
uninitialized variables in a function. You can fix this by initializing the variables properly.
Additionally, you can use a static analysis tool to detect memory leaks, which you can
then fix by deallocating memory correctly. By heeding these warnings and using analysis
tools, you can improve code reliability and security.
SEI CERT Practice 3
Architect and Design for Security Policies:
- Create software architecture and design your software to implement and enforce
security policies.

For example: If your system requires different privileges at different times, consider
dividing the system into distinct intercommunicating subsystems, each with a appropriate
privilege set.
SEI CERT Practice 4
Keep It Simple:
- Keep the design as simple and small as possible.
- Complex designs increase the likelihood that errors will be made in their
implementation, configuration, and use.

For example: Instead of creating a complex system with more coupling, a simple design
might involve breaking down this system into smaller, more manageable modules with
clear interfaces. This simplification can make it easier to understand, maintain, and
reducing the risk of vulnerabilities.
SEI CERT Practice 5
Default Deny:
- Base access decisions on permission rather than exclusion. This means that, access is
denied and the protection scheme identifies conditions under which access is
permitted.

For example: In a file system, focus on who can access files instead of who can’t. Only let
users in the “admin” group modify configuration files. This way you can reduce the risk of
unauthorized access.
SEI CERT Practice 6
Adhere to the principle of least privilege:
- Every process should execute with the least set of privileges necessary to complete
the job.
- Any elevated permission should only be accessed for the least amount of time
required to complete the privileged task. This approach reduced the opportunities an
attack has to execute arbitrary code with elevated privileges.

For example: A web server might only need read access to files. Elevate permission
temporarily for specific tasks like accessing sensitive data can limit the chance of
attackers exploiting them.
SEI CERT Practice 7
Sanitize Data Sent to Other Systems:
- Sanitize all data passed to complex subsystems such as command shells, relational
databases, and commercial off-the-shelf (COTS) components. Attackers may be able
to invoke unused functionality in these components through the use of SQL,
command, or other injection attacks.
- This is not an input validation problem because the complex subsystem being
invoked does not understand the context in which the call is made. Because the
calling process understands the context, it is responsible for sanitizing the data before
invoking the subsystem.
SEI CERT Practice 8
Practice Defense in Depth:
- Manage risk with multiple defensive strategies, so that if one layer of defense turns
out to be inadequate, another layer of defense can prevent a security flaw from being
an exploitable vulnerability and/or limit the consequences of a successful exploit.

For example: combining secure programming techniques with secure runtime

environments should reduce the likelihood that vulnerabilities remaining in the code at
deployment time to be exploited in the operational environment.
SEI CERT Practice 9
Use Effective Quality Assurance Techniques:
- Good quality assurance techniques can be effective in identifying and eliminating
vulnerabilities.
- Fuzz testing, penetration testing, and source code audits should all be incorporated as part
of an effective quality assurance program.
- Independent security reviews can lead to more secure systems.
- External reviewers bring an independent perspective.

Example: In web application development project, incorporating fuzz testing, penetration, and
source audits help identify and fix vulnerabilities. Bringing in external security experts for
independent views add an extra layer of assurance, ensuing a more secure final product.
SEI CERT Practice 10
Adopt a Secure Coding Standard:
- Develop or apply a secure coding standard for your target development language and
platform.

Example: In a C++ software project, you could adopt the SEI CERT C++ Coding
Standard. This standard provides specific guidelines and the best practices for writing
secure C++ code, covering areas such as memory management, pointer usage, and
exception handling. By using this standard, developers can minimize the risk of common
vulnerabilities like overflows and memory leaks.
MITRE CWE
What is it?
- MITRE CWE, stands for Common Weakness Enumeration.
- It is a community developed list of software and hardware weaknesses.

Purpose:
- The primary purpose of MITRE CWE is to provide a standardized catalog of
vulnerabilities, enabling organizations to better understand, identify, and address
security weaknesses in software systems.
MITRE CWE
Development
- MITRE CWE is developed and maintained by MITRE Corporation in collaboration
with the global cybersecurity community.

Why use MITRE CWE

- Common Language: It serves as a common language for describing and categorizing
software vulnerabilities, facilitating communication and collaboration among
stakeholders.
- Integration with Standards and Tools: MITRE CWE integrates seamlessly with other
cybersecurity standards, frameworks, and tools.
MITRE CWE Used in Practice
1. Vulnerability Identification: Software engineerings use MITRE CWE to identify
common weaknesses and vulnerabilities in software systems. By referring to the CWE
catalog, they can recognize known patterns of vulnerabilities and assess whether their
code is susceptible to similar issues.
2. Code Reviews and Testing: During code reviews and testing phases, software engineers
reference MITRE CWW to check for potential vulnerabilities in the codebase.
3. Risk Assessment and Prioritization: MITRE CWE aids in risk assessment by providing a
standardardized framework for categorizing vulnerabilities based on severity, impact,
and exploitability. They can prioritize their efforts to address vulnerabilities that pose the
greatest risk to the software system.
CWE Top 25
What is it?
- CWE stands for Common Weakness Enumeration
- It is a list of the top 25 most dangerous software weaknesses
- Released yearly by the MITRE Corporation
1) Out of Bounds Write
- What is it?
- This is when the product writes before, after, or otherwise outside of the correct buffer.
- What causes it?
- Lack of input validation.
- Indexing errors.
- Why is it a problem?
- Memory that is not supposed to be modified could be modified.
- This vulnerability could lead to a crash.
- Sensitive data could be corrupted.
- Prevention steps
- Use a vetted library like SafeStr to protect against string induced overflows.
2) Cross-site Scripting
- What is it?
- This is when an attacker is able to inject malicious script into a web page that is then served to others.
- What causes it?
- This occurs when a product either does not, or incorrectly neutralizes input before placing it in an
output.
- Why is it a problem?
- That output is often placed in a web page and served to other users.
- In some cases, arbitrary commands/code can be run on the victim’s computer.
- Prevention steps
- Use a library/framework that does not allow for this vulnerability to occur. For example, OWASP
ESAPI’s Encoding Module.
- Duplicate security checks.
3) SQL Injection
- What is it?
- SQL Injections occur when an attacker uses malicious SQL code or manipulates SQL queries in order to gain access to systems or
data that should be hidden
- What causes it?
- Insufficient architecture security tactics are the root cause of this vulnerability.
- Why is it a problem?
- These kinds of attacks can result in data leaks that range from sensitive company data, to private personal information about users.
- Prevention steps
- Use libraries/frameworks that do not allow or at least avoid this vulnerability.
- Perform duplicate security checks.
- Types of SQL Injection Attacks
- Boolean-Based
- Error-Based
- Union-Based
- Time-Based
4) Use After Free
- What is it?
- The process of referencing memory after it has been freed.
- What causes it?
- Improper memory management.
- Mismanagement of Dynamically Allocated Memory.
- Why is it a problem?
- It could lead to the corruption of valid data.
- It could cause a segmentation faults.
- Prevention steps
- Choose a language that provides automatically managed memory.
- Be sure to set freed pointers to NULL.
5) OS Command Injection
- What is it?
- An attack in which the goal is execution of arbitrary commands.
- What causes it?
- It is caused by an application passing unsafe, user-supplied data.
- This could take place using a form.
- Why is it a problem?
- The commands will run with the same privileges as the application.
- Sensitive data could be made known to attackers.
- Files and database records could be deleted.
- Prevention steps
- This is preventable by using specific API calls instead of OS Commands.
6) Improper Input Validation
- What is it?
- It is when a product receives input, but doesn’t validate or improperly validates it.
- What causes it?
- This vulnerability stems from the implementation phase.
- A programmer who isn’t aware that an attacker can modify inputs might take steps to ensure
input validation.
- Ex: Many programmers aren’t aware that cookies can be altered.
- Why is it a problem?
- It could cause programs to crash, increase the consumption of resources, or even expose data.
- Prevention steps
- A safe mindset is to assume that all input is malicious and then prepare from there.
- Use libraries or frameworks like Struts.
7) Out of Bounds Read
- What is it?
- Similarly to OB Write, it is when a product attempts to read outside the intended buffer.
- What causes it?
- Accessing an invalid position.
- Improper indexing issues.
- Why is it a problem?
- It can cause crashes and lead to other vulnerabilities.
- Malicious actors could access some sensitive data.
- Prevention steps
- This can be mitigated by utilizing errors or printing warning messages.
 8) Path Traversal
- What is it?
- The use of external input to build a pathname that identifies a file in a restricted directory.
- What causes It?
- This occurs during the implementation phase.
- Why is it a problem?
- Attackers can gain access to restricted files and directories
- Prevention steps
- Ensure that error messages are minimal and not too revealing.
- In case the code is controlled by a 3rd party, you can use firewalls.

/users/cwe/profiles/../../../etc/passwd

When the file is opened, the operating system resolves the "../" and actually accesses this file:
/etc/paswd
9) Cross-Site Request Forgery (CSRF)
- What is it?
- This is when the application can’t, or doesn’t, sufficiently verify whether a request was intentionally
provided by the user.
- What causes it?
- Bad practice in the Architecture and Design phase.
- Why is it a problem?
- “Web browsers are trusting creatures. If you give them some code, the will run it.” - Tim Scott
- Social engineering can be used to trick people into furthering the forgery through emails, etc.
- Prevention steps
- You can use a CSRF Token.
10) Unrestricted Upload of File with Dangerous Type
- What is it?
- This is when product allows the attacker to upload files of dangerous types
- What causes It?
- This occurs during the architecture and design phase
- Crucial security tactics are overlooked.
- Why is it a problem?
- Arbitrary code execution can take place. Especially for PHP files which does not restrict file types.
- Prevention steps
- Create new file names so no external input is used.
- A good strategy is also enforcement by conversion
11) Missing Authorization
- What is it?
- This is when a product does not perform authorization whenever an actor attempts to access resources.
- What causes it?
- Overlooked security methods in the architecture and design phase
- Developers may introduce weaknesses in the implementation phase due to a lack of knowledge.
- Why is it a problem?
- An attacker could both read from and write to sensitive data as well as gain certain privileges.
- Prevention steps
- Use libraries/frameworks that do not allow this weakness lik JAAS and OWASP ESAPI’s Access
Control feature
12) Null Pointer Dereference
- What is it?
- This occurs when an application dereferences a pointer that it expects to be valid but is NULL.
- What causes it?
- Race Conditions
- Simple Omissions
- Why is it a problem?
- It results in the failure of the process even if error handling is available, it can cause issues.
- Prevention steps
- You should sanity-check pointers before use
13) Improper Authorization
- What is it?
- This occurs when an actor claims to have a given identity and the product does not sufficiently validate
that claim
- What causes it?
- Improper implementation of an architectural security tactics.
- Why is it a problem?
- This vulnerability can lead to the exposure of sensitive data as well as the inner workings of some
systems to attackers.
- Prevention steps
- You should use libraries/frameworks like OWASP ESAPI’s Authorization feature
14) Integer Overflow or Wraparound
- What is it?
- This is when a product performs a calculation that can produce an integer overflow.
- What causes it?
- An integer is too large to be stored in it’s associated representation
- Ex: 8-bit integer addition of 127 + 1 results in −128, a two's complement of 128
- Why is it a problem?
- It can lead to data corruption, buffer overflows, incorrect calculations, etc.
- Prevention steps
- If possible, you should use a language that allows bounds checking.
- You can also use integer handling packages like SafeInt for C++ or IntegerLib for C.
15) Deserialization of Untrusted Data
- What is it?
- The product deserializes untrusted data without verifying its validity.
- What causes it?
- This occurs in the Architecture and Design phase as well as the Implementation phase.
- Things like improper error handling or no input validation exacerbate this issue.
- Why is it a problem?
- Attackers can modify data/objects
- Prevention steps
- You can use signing and sealing features to assure data has not been touched.
- Hash-based message Authentication Codes
16) Command Injections
- What is it?
- Similar to OS Injections but for web applications.
- What causes it?
- This is caused by attackers manipulating input in order to inject additional commands.
- Why is it a problem?
- This could lead to arbitrary command/code execution.
- Prevention steps
- Perform input validation under the assumption that all input is malicious.
- Where possible, use library calls to recreate desired functionality.
17) IROBMB
Improper Restriction of Operations within the Bounds of a Memory Buffer
- What is it?
- This is when the product performs operations on a memory buffer while being able to read from and write
to a memory location outside of the buffer.
- What causes it?
- Some languages allow direct accessing of memory locations and don’t ensure that they are valid for the
memory being referenced.
- Why is it a problem?
- If memory is accessible to an attacker, it can lead to arbitrary code execution, as well as relevant memory
being corrupted.
- Prevention steps
- When possible, use a language that does its own memory management.
18) Use of Hard Coded Credentials
- What is it?
- This is when the product contains credentials such as passwords or cryptographic keys.
- What causes it?
- The use of hard coding credentials
- Why is it a problem?
- It is almost guaranteed that attackers will be able to access account information and other sensitive
data.
- Prevention steps
- Store passwords outside of the code
- If it must contain hard coded credentials, perform strict access controls to limit the entities that can
access the feature.
19) Server-side Request Forgery
- What is it?
- This is when a web server receives a URL from upstream, the web server then also receives the
contents without sufficiently validating that the request is being sent to the correct destination
- What causes it?
- Improper input validation
- Insufficient access control
- Why is it a problem?
- Sensitive data and internal resources can unintentionally be made available to bad actors.
- Prevention steps
- Network segmentation could be a successful approach to prevention. By isolating internal systems
through the use of firewalls access will be more often denied to attackers.
20) Missing Authorization for Critical Functions
- What is it?
- This is when a product doesn’t perform authorization for functionalities that require a provable user
identity.
- What causes it?
- Missing security tactics in the Architecture and Design phase.
- Why is it a problem?
- This can expose critical functionality and essentially gives the attacker the same functionality.
- Prevention steps
- Divide the software into increasingly secure privilege areas.
- For any security checks on server-side, perform those same checks on the client side.
- Use libraries/frameworks to mitigate the likelihood of this occurring.
21) Race Conditions
- What is it?
- This is when a product contains code that runs simultaneously with other code.
- What causes it?
- Two or more segments of code are running concurrently, they both require exclusive access to some
resource, but a window of time exists where the resource is shared, and thus modified by both code
segments.
- Why is it a problem?
- Race conditions can lead products/programs into an unexpected, unrecoverable state, which in turn
could cause a crash.
- Prevention steps
- Minimization of the sharing of resources
- When possible, use synchronization primitives. These essentially aid in threading the kernel.
22) Improper Privilege Management
- What is it?
- This is when the product does not adequately assign or modify privileges for users.
- What causes it?
- This error is introduced through poor implementation of architecture and security tactics.
- Why is it a problem?
- This vulnerability can lead to attackers gaining privileges that are not intended.
- Prevention steps
- Follow the Principle of Least Privilege.
- Carefully manage the setting and modifications of privileges.
23) Code Injection
- What is it?
- This is when the product contains externally influenced code but is not able to neutralize its effects downstream.
- What causes it?
- This vulnerability is caused by lacking implementation of security tactics.
- Why is it a problem?
- Injectable code could lead to a remote vulnerability.
- Attackers could access sensitive resources.
- Almost all data immediately loses integrity when this vulnerability is exploited.
- Prevention steps
- Run the code in a “sandbox” environment that supports strict boundaries between the code and internal
resources.
- Use static analysis and testing tools in the testing phase of software development.
- Use dynamic tools to carry out fuzz testing, robustness testing, and fault injection.
24) Incorrect Authorization
- What is it?
- This is when the product incorrectly performs an authorization check and in turn, allows the attacker to
get around access restrictions.
- What causes it?
- This can occur when a single-user environment is ported to a multi-user environment.
- This can also occur as a result of a developer introducing weaknesses in the implementation phase.
- Why is it a problem?
- An attacker could both read and modify sensitive data and information.
- Attackers could gain privileges not meant for them.
- Prevention steps
- Modularity: Divide the product into increasing levels of security.
- Use a library/framework that supports authorization control such as OWASP ESAPI or JAAS.
25) Incorrect Default Permissions
- What is it?
- This is when by default, file permissions are set to allow anyone to access and modify the files.
- What causes it?
- This vulnerability can be introduced in nearly every phase of the development process.
- Why is it a problem?
- People who are not meant to be able to read from, write to, or access data, can now do so.
- Prevention steps
- Modularize the system and create “safe areas” with hard set lines and boundaries and do not allow
sensitive data to go outside of those boundaries.
Seven Pernicious Kingdoms
The seven pernicious kingdoms is an abstract collection of software vulnerabilities that
share a common theme or feature.

The kingdom part of the name comes from the biological definition for a kingdom, that is,
“A collection of phyla that share a common factor.”

The list itself is not set in stone by design. This allows for the addition or removal of new
“phyla” or the modification of kingdoms over time.
How is it Used in Secure Coding Practices?
The Seven Pernicious Kingdoms are used in secure coding practices as a kind of
cautionary tale. They are there for review and you should reference them to ensure you are
not potentially adding any of these errors or mis-practices into the project that you are
working on. It also serves as a way to modularize many of these errors and group them
into their own categories.
The Seven Pernicious Kingdoms Taxonomy
1) Input Validation and Representation
2) API Abuse
3) Security Features
4) Time and State
5) Errors
6) Code Quality
7) Encapsulation
Input Validation and Representation
Many of the issues caused in this category stem from metacharacters, alternate encodings,
and numeric representations.

Some examples from this category would be:

- Buffer Overflows
- Cross-Site Scripting
- Integer Overflows
- SQL Injections

By properly validating input and ensuring that data is represented properly, many of the
issues faced in this kingdom can be largely mitigated.
API Abuse
API is the acronym for Application Programming Interface.

API Abuse is the practice of exploiting vulnerabilities inside of the said APIs.

An example could be something like using an API for data scraping or intentionally
causing buffer overflows.

Combatting API Abuse requires both preventative measures as well as sound response
strategies.

Some common approaches to this are implementing strong authorization mechanisms and
enforcing rate limiting.
Security Features
Security Features are concerned with topics like authentication, access control,
cryptography and privilege management.

A major point among all the subpoints of Security Features is the focus on controlling who
has access to what and ensuring that the entity accessing it is trustworthy.

Password Management is another major focus of this kingdom.

Things like Hard-Coded Passwords and weak cryptography appear in this kingdom.
Time and State
“Most programmers anthropomorphize their work. They think about one thread of control
carrying out the entire program in the same way they would if they had to do the job
themselves.” - Tsipenyuk, Chess, McGraw
- Time related vulnerabilities encompass the area concerning timestamps, timeouts, or
time related operations.
- State related vulnerabilities encompass the area concerning the management of state
changes.
Errors
While it seems like a broad topic, there are two main ways to introduce an error related
vulnerability.

1) Handling errors poorly

2) Producing errors that give out too much information

An example of handling errors poorly could be an instance in which a program is unable

to gracefully handle errors and results in the crashing of the program or process.
Code Quality
Poor code quality is an invitation to an attacker to attempt and press the system in ways that it
might not be capable of recovering from.

Poor code quality encompasses areas and errors such as:

- Double Free
- Memory Leaks
- Undefined Behaviors
- Uninitialized Variables
- Use After Free

Code quality is critically important as it is not restricted to its own kingdom. Poor code quality
leads to increased risks of attack in every other kingdom as well.
Encapsulation
While it is a main principle of software engineering, it has a great influence of software
security as well.

With respect to the 7 kingdoms, encapsulation refers to the containment of sensitive data
within the software components to restrict access to it by outside influences.

Some aspects of encapsulation are information hiding, access control, and modularity.

Encapsulation focuses on setting boundaries in a software sense and some of the

vulnerabilities like data leaking between users and object hijacking display that very
clearly.
OWASP Top 10
OWASP is the Open Web Application Security Project. The top 10 list is an awareness document for developers. It
contains a general consensus among experts to be the top 10 most prevalent security risks to web applications.

The list is comprised of the following:

1) Broken Access Control

2) Cryptographic Failures
3) Injections
4) Insecure Design
5) Security Misconfiguration
6) Vulnerable and Outdated Components
7) Identification and Authentication Failures
8) Software and Data Integrity Failures
9) Security Logging and Monitoring Failures
10) Server-Side Request Forgery
What Role does the OWASP Top 10 Serve?
The OWASP Top 10, while not a comprehensive list serves a crucial role in secure coding
practices. It is a guiding document that can help developers avoid a wide majority of
pitfalls that they might otherwise find themselves in.

OWASP recognizes that the document is “A first step towards more secure coding
practices.”
Roles and Purposes Continued
It also accomplishes a few of the following roles, but is also not limited to these:

1) Guidance - The OWASP Top 10 helps to guide developers as they work on and with a
project.
2) Education - This document helps to make risks and vulnerabilities more widely
known, this helps to bring faulty practices into the spotlight and hopefully inspire
better, more secure coding practices.
3) Quality Assurance - This document could be used as a benchmark when testing code.
If it complies with the OWASP guidelines, there’s a good chance it is more secure
code than would have been created without referencing it.
Sources
● https://www.checkpoint.com/cyber-hub/cloud-security/what-is-secure-coding/
● https://johnbandler.medium.com/bandlers-four-pillars-of-cybersecurity-6d0761f04f82
● https://csrc.nist.gov/glossary/term/software_assurance
● https://owasp.org/www-project-samm/
● https://www.checkpoint.com/cyber-hub/cloud-security/what-is-secure-sdlc/
● https://www.microsoft.com/en-us/securityengineering/sdl/practices
● https://www.appknox.com/cyber-security-jargons/secure-coding
● https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html
● https://owasp.org/www-community/attacks/
● https://cheatsheetseries.owasp.org/cheatsheets/
● https://cwe.mitre.org/documents/sources/SevenPerniciousKingdoms.pdf
● https://eva.fing.edu.uy/mod/page/view.php?id=77012
● https://cwe.mitre.org/
● https://www.sei.cmu.edu/our-work/secure-development/
● https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard
● https://www.sei.cmu.edu/about/index.cfm
● https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88046682
● https://ldra.com/sei-cert/
● https://www.threatintelligence.com/blog/secure-code-reviews
● https://www.ibm.com/support/pages/ibm-security-and-privacy-design