Chapter 9 Flashcards
Continuous Integration
is a development practice that checks code into a shared repository on a consistent ongoing basis. In continuous integration environments, this can range from a few times a day to a very frequent process of check-ins and automated builds.
Since continuous integration relies on an automated build process, it also requires automated testing.
Continuous Deployment
Which rolls out tested changes into production automatically as soon as they have been tested.
Improper Error Handling
Which often results in error messages that shouldn’t be exposed outside of a secure environment being accessible to attackers or the general public. Since errors often include detailed information about what is going on at the moment the error occurs, attackers can use them to learn about the application, databases, or even to get stack trace information providing significant detail they can leverage in further attacks. Errors that don’t appear to provide detailed information can still allow attackers to learn more about the application, as differing responses can give attackers clues about how successful their efforts are. As a security practitioner, you should pay careful attention to application vulnerability reports that show accessible error messages, as well as the content of those messages.
Dereferencing
Issues are often due to null pointer dereferences. This means that a pointer with a value of NULL (in other words, one that isn’t set) is used as though it contains an expected value. This type of error almost always leads to a crash unless caught by an error handler. Race conditions, like those mentioned in a moment, are also a common place to find a dereferencing issue.
Insecure Object References
occur when applications expose information about internal objects, allowing attackers to see how the object is identified and stored in a backend storage system. Once an attacker knows that, they may be able to leverage the information to gain further access, or to make assumptions about other data objects that they cannot view in this way.
Race Conditions
Rely on timing. An application that needs to take action on an object may be sensitive to what is occurring or has occurred to that object. Although race conditions are not always reliable, they can be very powerful, and repeated attacks against a race condition can result in attackers succeeding.
Broken Authentication
Is exactly what it sounds like. Improperly implemented authentication may allow attackers who are not logged in, or who are not logged in as a user with the correct rights, access to resources. Implementing a strong and reliable authentication (and authorization!) system is an important part of application coding.
Sensitive Data Exposure
May occur when any of a number of flaws are exploited. The simplest version of this is when the application does not properly protect sensitive data, allowing attackers to access it.
Insecure Components
Include a broad range of issues introduced when a component of an application or service is vulnerable and thus it introduces that vulnerability to the application. Understanding all of the components and modules that make up an application is critical to determining whether it may have known vulnerabilities that exist due to those components.
Insufficient logging and monitoring
Will result in being unable to determine what occurred when something does go wrong. Part of a strong security design is determining what should be logged and monitored, ensuring that it is appropriately captured, and then building processes and systems to handle those logs and events so that the right thing happens when they occur.
Weak or default configurations
Are common when applications and services are not properly set up or when default settings are used. One common example of this is using a default password for a service or database connection. Many application vulnerability scanners look for these default configurations, making it even easier for attackers to find them.
Use of insecure functions
Can make it much harder to secure code. Functions like strcpy, which don’t have critical security features built in, can result in code that is easier for attackers to target. In fact, strcpy is the only specific function that the CySA+ objectives call out, likely because of how commonly it is used for buffer overflow attacks in applications written in C.
strcpy
Allows data to be copied without caring whether the source is bigger than the destination. If this occurs, attackers can place arbitrary data in memory locations past the original destination, possibly allowing a buffer overflow attack to succeed.
Mobile Platforms
Have their own operating systems, and their own platform security controls. They also have their own security tools like the iOS Keychain and Face ID. They store data in ways that can be specific to the device, with Android devices often offering both on-board storage and storage via microSD cards, which can make tampering easier for attackers. Most of the common issues for mobile platforms, however, are similar to those found in other platforms. As of this writing, OWASP’s most recent mobile vulnerability list includes insecure communication, insecure authentication and authorization, insufficient cryptography, code quality, and reverse engineering—all issues with other platforms.
Embedded Systems
Computer systems that are part of a larger system with a small number of dedicated functions
System-on-chip (SoC)
Which embed a complete computer in a chip, can provide additional security because they’re not as accessible, but that often comes with less frequent updates or an inability to update them easily.
Client-Server Model
In this model, clients (web browsers, applications, or other clients) communicate with one or more servers that provide information to them. Web applications work this way, and security practitioners need to understand that attacks may be conducted against the clients, against the network, against the traffic sent between the client and server, and against the server itself. Thus, the attack surface of a client-server application is broad, and appropriate security measures must be implemented for each component.
Firmware
Is the embedded software used by a computer or hardware device. Firmware flaws can be hard to fix, since not all devices are designed to update their firmware. Attackers who want to target firmware will often seek to acquire a copy of the firmware, either by directly connecting to the device and downloading it or by acquiring the firmware itself from a download site or other means. After that, standard reverse engineering and other software exploitation techniques can be applied to it to identify flaws that may be worth exploiting.
Risk Assessment
Is important to understand what risks the application faces and how to prioritize remediation of those issues. Continuous assessment is recommended for applications using regularly scheduled testing tools that can inform the application risk assessment process.
Input Validation
helps prevent a wide range of problems, from cross-site scripting (XSS) to SQL injection attacks.
Output Encoding
Translates special characters into an equivalent but safe version before a target application or interpreter reads it. This helps to prevent XSS attacks by preventing special characters from being inserted that cause the target application to perform an action.
WAF
Can prevent attacks against vulnerable applications and offer a line of defense for applications that don’t have an available patch or that cannot be taken offline for patching.
