Introduction
In this article, we going to look at software security in terms of The Seven Pernicious Kingdoms. Whilst software security has been a major concern in the modern world, analysts have realized that most of the problems found in the source-code itself. The security flaws surrounding web applications and websites are a result of how they are written. Developers in most cases work towards achieving what the user wants to accomplish and in most cases, they never look at the weaknesses in the code the use because all they aim to do is to fulfill the user requirements specifications.
In recent developments, as cyberattacks became common, there was a need to look at how and why these attacks occurred. With the help of releases such as the OWASP …, 2010, 2013, 2017 organizations had some sort of guide as to what to inspect in their web applications before they could deploy them. In the same manner, the Seven Pernicious Kingdoms is a taxonomy created by Tsipenyuk, Chess, and McGraw [Tsipenyuk, Chess, McGraw, 2005]. The term kingdom is used as biologists use it in their taxonomy of living organisms: to indicate a high-level grouping of similar members and in this case, it is used to refer to web security flaws.
The ordering of the kingdoms gives an estimate of their relative importance. The complete taxonomy can found
here.
In this article, we are going to take a descriptive approach to the Seven Pernicious Kingdoms.
The Seven Pernicious Kingdoms
- Input Validation and Representation
- API Abuse
- Security Features
- Time and State
- Errors
- Code Quality
- Encapsulation
Environment
One may wonder why they are called The Seven Pernicious Kingdoms and yet it’s a list of eight. This is based on the approach by George Miller who identified that people are good at keeping track of seven, plus or minus two things at a time.
Because organizations want to maintain security, developers are urged to develop applications that are secure at all costs but sometimes there is no knowing if the code they write is secure or not. At some stage, this pushed to the development of the Common Vulnerabilities and Exposures (CVE) database. The CVE database allows developers to submit vulnerabilities in a software or hardware product they would have discovered.
The CVE database would save the vulnerability with a unique ID, but it does not provide any categorization or structure for the vulnerability. This lack of categorization then led to the creation of The Seven Pernicious Kingdoms. It gives a structured way of classifying vulnerabilities (phylum) into larger, broader security flaws i.e. kingdoms. This will also help developers to write secure code as it highlights the key things to look out for.
A phylum is any particular coding error e.g. Command Injection. Command Injection is a phylum and is contained within the kingdom "Input Validation and Representation", which includes Command Injection, along with buffer overflows, SQL Injection among other similar flaws.
The Seven Pernicious Kingdoms: A Descriptive Approach
Input Validation and Representation
Most security problems are a result of user input. Trusting user input may be detrimental to the application's security. Through the use of malicious SQL/Commands, attackers may be able to gain unauthorized access to the system and cause harm to the organization. Input validation and representation problems are caused by meta-characters, numeric representation, and alternate encodings. Attacks such as Command Injection, SQL Injection, Cross-site Scripting, and buffer-overflow come under Input Validation and Representation.
Buffer Overflow
Writing outside the bounds of allocated memory can corrupt data, crash the program, or cause the execution of an attack payload.
Command Injection
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Cross-Site Scripting
Sending unvalidated data to a Web browser can result in the browser executing malicious code (usually scripts).
XML Validation
Failure to enable validation when parsing XML gives an attacker the opportunity to supply malicious input.
API Abuse
An API normally involves two parties, the first party that calls the API (caller) and the other that responds to the API (callee). In most cases, API Abuse is caused by the caller failing to honor its end of the bargain. For example, if a program fails to call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller abuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated.
Dangerous Function
Functions that cannot be used safely should never be used.
Directory Restriction
Improper use of the chroot() system call may allow attackers to escape a chroot jail.
Heap Inspection
Do not use realloc() to resize buffers that store sensitive information.
J2EE Bad Practices: getConnection()
The J2EE standard forbids the direct management of connections.
J2EE Bad Practices: Sockets
Socket-based communication in web applications is prone to error.
Often Misused: Authentication
Do not rely on the name the getlogin() family of functions returns because it is easy to spoof.
Often Misused: Exception Handling
A dangerous function can throw an exception, potentially causing the program to crash.
Often Misused: File System
Passing an inadequately sized output buffer to a path manipulation function can result in a buffer overflow.
Often Misused: Privilege Management
Failure to adhere to the principle of least privilege amplifies the risk posed by other vulnerabilities.
Often Misused: Strings
Functions that manipulate strings to encourage buffer overflows.
Unchecked Return Value
Ignoring a method’s return value can cause the program to overlook unexpected states and conditions.
Security Features
Security Features are concerned with authentication, access control, confidentiality, and cryptography as well as user privilege management. There is a need to get web application security features right in the first place. A good example of a security flaw is hard-coding the user default password.
Insecure Randomness
Standard pseudo-random number generators cannot withstand cryptographic attacks.
Least Privilege Violation
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
Time and State
When developers write their code they assume that their code will be executed sequentially as it is done in their local environment or on test servers. In the real-world, applications may operate on multi-tasking operating systems running on multi-core, multi-CPU, or distributed machines where these rules cannot be applied. These platforms juggle multiple users and multiple threads of control, two events may take place at exactly the same time. Distributed computation is about time and state. That is, in order for more than one component to communicate, the state must be shared, and all that takes time. These defects are related to unexpected interactions between threads, processes, time, and information. These interactions happen through the shared state: semaphores, variables, the file system, and, basically, anything that can store information.
Deadlock
Inconsistent locking discipline can lead to deadlock.
Failure to Begin a New Session upon Authentication
Using the same session identifier across an authentication boundary allows an attacker to hijack authenticated sessions.
File Access Race Condition: TOCTOU
The window of time between when a file property is checked and when the file is used can be exploited to launch a privilege escalation attack.
Insecure Temporary File
Creating and using insecure temporary files can leave application and system data vulnerable to attack.
J2EE Bad Practices: System.exit()
A Web application should not attempt to shut down its container.
J2EE Bad Practices: Threads
Thread management in a Web application is forbidden in some circumstances and is always highly error-prone.
Signal Handling Race Conditions
Signal handlers may change the shared state relied upon by other signal handlers or application code causing unexpected behavior.
Error Handling
Error Handling deserves a kingdom of its own because of the way errors vary in a web application ranging from how API errors are handled to revealing too much information in an error message exception.
Catch NullPointerException
Catching NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer.
Empty Catch Block
Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
Overly-Broad Catch Block
Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
Overly-Broad Throws Declaration
Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
Code Quality
Poor code quality provides an opportunity for attackers to manipulate the application and make it perform unintended functionalities. The application itself may also misbehave and cause poor usability. Entering an infinite loop may enable a denial-of-service attack and allow an attacker to take advantage of some poorly thought-out error handling code. There is a need for developers to ensure that their code meets specified quality before they can deploy their applications.
Double Free
Calling free() twice on the same memory address can lead to a buffer overflow.
Inconsistent Implementations
Functions with inconsistent implementations across operating systems and operating system versions cause portability problems.
Memory Leak
Memory is allocated but never freed leading to resource exhaustion.
Null Dereference
The program can potentially dereference a null pointer, thereby raising a NullPointerException.
Obsolete
The use of deprecated or obsolete functions may indicate neglected code.
Undefined Behavior
The behavior of this function is undefined unless its control parameter is set to a specific value.
Uninitialized Variable
The program can potentially use a variable before it has been initialized.
Unreleased Resource
The program can potentially fail to release a system resource.
Use After Free
Referencing memory after it has been freed can cause a program to crash.
Encapsulation
Data hiding (encapsulation) means restricting data from being misused by other processes running concurrently. E.g. mobile code cannot be abused by other mobile code or differentiation between unvalidated data and validated or confidential data and data that is supposed to be displayed.
Comparing Classes by Name
Comparing classes by name can lead a program to treat two classes as the same when they actually differ.
J2EE Misconfiguration: Weak Access Permissions
Permission to invoke EJB methods should not be granted to the ANYONE role.
Data Leaking Between Users
Data can "bleed" from one session to another through member variables of singleton objects, such as Servlets, and objects from a shared pool.
Leftover Debug Code
Debug code can create unintended entry points in an application.
Mobile Code: Object Hijack
Attackers can use Cloneable objects to create new instances of an object without calling its constructor.
Mobile Code: Use of Inner Class
Inner classes are translated into classes that are accessible at package scope and may expose code that the programmer intended to keep private to attackers.
Mobile Code: Non-Final Public Field
Non-final public variables can be manipulated by an attacker to inject malicious values.
Private Array-Typed Field Returned From a Public
Method
The contents of a private array may be altered unexpectedly through a reference returned from a public method.
Public Data Assigned to Private Array-Typed Field
Assigning public data to a private array is equivalent to giving the public access to the array.
System Information Leak
Revealing system data or debugging information helps an adversary learn about the system and form an attack plan.
Trust Boundary Violation
Commingling trusted and untrusted data in the same data structure encourages programmers to mistakenly trust unvalidated data.
Environment
This kingdom is concerned with any critical security issues concerning the product but not including source-code. Configuration files that govern the program’s behavior and compiler flags used to build the program are some of the examples in this kingdom. Everything else in the kingdoms has to do with source-code thus this kingdom is included to encompass other security issues beyond the source-code flaws.
OWASP Top 10 mapping to the Seven Pernicious Kingdoms
Here is the mapping of the kingdoms to OWASP top 10,
- Input Validation and Representation
- Cross-Site Scripting (XSS) Flaws
- Injection Flaws
- Unvalidated Input
- API Abuse
- Security Features
- Broken Access Control
- Insecure Storage
- Time and State
- Errors
- Code Quality
- Encapsulation
- Environment
- Insecure Configuration Management
Conclusion
The Seven Pernicious Kingdoms serve as a guide to developers, analysts, and organizations to use when developing their applications for deployment on the public internet.
This may save them from common attacks that are being used today, thereby saving them a lot of money and maintaining a good reputation with their users.
Join the conversation! Your thoughts help the community grow.