Securing Applications and Data · ⁨アプリケーションとデータの保護⁩

Learning Objective 5.1.A: Explain how adversaries can exploit application and file vulnerabilities to cause loss, damage, disruption, or destruction.

• 5.1.A.1 An adversary can read any unencrypted files if they have access to the device or drive storing the files.
• 5.1.A.2 Computers have standard users and administrative users. Administrative users have access to control system settings and can typically access any files or applications on a system. If regular users are given administrative privileges on a computer, and an adversary can compromise a user’s account, then the adversary will have elevated privileges on the system.
• 5.1.A.3 When access control settings are weakly configured, many users often have permission to view and sometimes even edit files on a system. Adversaries can take advantage of weak access control settings to steal or destroy files or disrupt an application.

Learning Objective 5.1.B: Explain how application attacks exploit vulnerabilities.

• 5.1.B.1 Applications are programs that run instructions on computers; they are executable data. Some applications run locally on a user’s computer, while other applications, like web applications, run on a server and are accessed by users through a network.
• 5.1.B.2 Many applications take user input through open-ended input fields where users can type characters (e.g., letters, numbers, punctuation). Developers should include user input checks in their application, such as numeric input when asked for a number of items, to ensure that the user input matches what is expected; the application should reject input outside of the expected parameters. This process of verifying that user input meets expected criteria before processing it is called data validation. Applications that fail to validate user input are vulnerable to injection-type attacks, where adversaries insert unexpected character strings in input fields to alter the behavior of a program.
• 5.1.B.3 Structured query language (SQL) is a computer language used to request information from databases and make changes to databases or entries in databases. Applications that query a database using unvalidated or unsanitized input from users are vulnerable.
• 5.1.B.4 An SQL-injection attack places SQL commands and control characters into a user-input field in an application, which can lead to a breach of confidentiality by causing the application to return more information than it should, or a breach of integrity by modifying or deleting data in the database.
• 5.1.B.5 Websites are written using hypertext markup language (HTML), and many websites use Javascript to create dynamic content on websites or web applications. Because Javascript commands run in the browser of the user visiting the website, those commands can access sensitive data stored in the browser like usernames, passwords, and cryptographic keys.
• 5.1.B.6 A cross site scripting (XSS) attack injects malicious code into a website that a user’s browser then executes. The malicious code can be embedded in a link the user clicks (a Type I or Reflected XSS attack) or it can be inserted onto a website through a comment field, forum post, or visitor log, which would affect any user visiting that website (a Type II or Stored XSS attack).
• 5.1.B.7 When applications take user input, that input is written to a buffer. A buffer is a designated section of computer memory with a fixed size. If the amount of data the user enters exceeds the size of the buffer, it can overflow into adjacent memory locations and overwrite other parts of the computer’s memory.
• 5.1.B.8 A buffer overflow attack feeds more data into memory than was allotted, which can cause a system to crash or to execute code outside the scope of a program’s security policy, effectively allowing the adversary to perform unauthorized actions on a computer, such as accessing, modifying, or deleting files.
• 5.1.B.9 The files that run web applications are stored in directories on servers. When users access web applications, their browsers send GET requests using hypertext transfer protocol (HTTP). A GET request accesses a file somewhere in the filesystem of the server.
• 5.1.B.10 In a directory traversal attack, adversaries modify URLs and GET requests to attempt to access sensitive data (e.g., usernames and passwords) on a server’s file system.
  • Illustrative examples for 5.1.B.10:
    • A web server stores images for a website it hosts in the /var/www/images/ directory. An adversary modifies a URL requesting an image to ../../../etc/passwd. The .. moves one directory up in the file system; so the three consecutive .. returns the path to the root, and from there the adversary is attempting to access the passwd file that would return a list of all the authorized usernames on the device.

Learning Objective 5.1.C: Assess and document risks from application and data vulnerabilities.

• 5.1.C.1 Data security risks can involve a compromise of confidentiality when unauthorized persons can access sensitive data, integrity when data can be manipulated or altered from its intended state, and availability when data can be destroyed or encrypted to prevent others from accessing it.
• 5.1.C.2 High risks from data vulnerabilities often involve highly sensitive data (e.g., data that is governed by laws or regulations) that could be compromised through a highly likely exploit.
  • Illustrative examples for 5.1.C.2:
    • The company developing the next jet engine that will be used by the Air Force in its planes is storing the technical specifications for the engine on an unencrypted drive.
• 5.1.C.3 Moderate risks from data vulnerabilities often involve sensitive data not having strong enough encryption or strict enough access controls.
  • Illustrative examples for 5.1.C.3:
    • A company stores its customers’ PII in a spreadsheet, and the spreadsheet is encrypted using a small key.
• 5.1.C.4 Low risks from data vulnerabilities often involve less sensitive information being encrypted with shorter keys or having access controls that are not strict enough.
  • Illustrative examples for 5.1.C.4:
    • An organization’s CEO stores his private memos to his executive staff on a company share drive that is unencrypted and has no access controls.

Learning Objective 5.3.A: Explain how encryption can be used to protect files.

• 5.3.A.1 The purpose of cryptography is to hide information. A cryptographic algorithm defines a process for encrypting and decrypting information. Encryption is the process of hiding the information, and decryption is the process of reversing the encryption to retrieve the original information.
• 5.3.A.2 An encryption algorithm defines a process for combining the information to be encrypted with a predefined key. The information to be encrypted is called the plaintext. The output of the encryption algorithm is called the ciphertext.
• 5.3.A.3 The number of possible keys that can be used in an encryption algorithm is called the keyspace. The larger the keyspace, the longer it will take an adversary to discover the correct key by random chance.
• 5.3.A.4 Cryptographic algorithms are classified by whether they use one key or two keys.
  • Symmetric encryption algorithms use the same key to encrypt and decrypt information.
  • Asymmetric encryption algorithms use two different keys—one to encrypt information and the other to decrypt information.
• 5.3.A.5 Cryptographic algorithms are also classified by whether they process information one bit at a time or in fixed-size chunks of bits.
  • Block encryption handles information in fixed-size chunks called blocks, producing an output block for each input block.
  • Stream encryption handles input information continuously, producing output one element at a time.

Learning Objective 5.3.B: Apply symmetric encryption algorithms to encrypt and decrypt data.

• 5.3.B.1 Computer-based encryption algorithms operate on binary data. The most common symmetric encryption algorithm is the Advanced Encryption Standard (AES). AES encryption is used to secure Wi-Fi transmissions, internet browsing, file encryption on disks, and hardware-level encryption on processors.
• 5.3.B.2 AES is a symmetric key block cipher that encrypts data in 128-bit blocks (16 bytes). AES can operate with keys of varying lengths. Longer keys produce more secure encryption but require more time to encrypt and decrypt.
• 5.3.B.3 Symmetric encryption and decryption can be performed using the command line, specialized software, or web-based tools.
  • On a command line interface, users can encrypt or decrypt with OpenSSL.
  • Specialized software like AES Crypt is an open source tool that can encrypt and decrypt files.
  • There are many web-based tools for encrypting and decrypting files.
• 5.3.B.4 Using OpenSSL in a CLI, a user can encrypt and decrypt a file using the following commands (note that the encryption key is derived from the password provided):
  • To encrypt a file named test with AES using a 128-bit key, use the command: openssl enc -aes-128-cbc -e -in test -k password -out test.enc
  • To decrypt the encrypted file using the same key, use the command: openssl enc -aes-128-cbc -d -in test.enc -k password -out text

Learning Objective 5.4.A: Determine the appropriate asymmetric key to use when sending or receiving encrypted data.

• 5.4.A.1 Asymmetric encryption allows users to communicate securely without prearranging a shared secret key.
• 5.4.A.2 When using asymmetric encryption, each entity that will be receiving data must first generate a key pair. Key pairs are binary strings of equal length that are generated at the same time through a mathematical process. One key is designated as the public key and the other as the private key. The keys are mathematical inverses of each other— each key reverses its partner. Either key can be used to encrypt information, but only the other key in the key pair will then be able to decrypt it.
• 5.4.A.3 Once the receiver generates the key pair, the private key must be stored securely. If the private key is exposed, shared, stolen, corrupted, or compromised the key pair must be deleted and a new key pair must be generated, because the security of the encryption algorithm rests on the security of the private key. The public key is published for anyone to view and use.
• 5.4.A.4 To send information securely to someone, the sender will use the receiver’s public key to encrypt the data and send it. Only the receiver who has the private key will be able to decrypt and read the information.

Learning Objective 5.4.B: Explain why the length of a key impacts the security of encrypted data.

• 5.4.B.1 Longer keys result in larger keyspaces. For binary keys, an n-bit length key has a keyspace of $2^n$.
• 5.4.B.2 Using an application to randomly guess an n-bit length encryption key means that on average an adversary will be able to guess the correct key in $2^n \div 2$ (or $2^{n-1}$) guesses.
• 5.4.B.3 Although longer keys are more secure, they also require more time to encrypt and decrypt messages.
• 5.4.B.4 Computational processing power and efficiency continue to improve, allowing software to guess keys faster. Key-length recommendations for both symmetric and asymmetric encryption algorithms are periodically increased to account for increased processing power.
• 5.4.B.5 Key-length comparison is only valid when comparing keys for the same cryptographic algorithm.
  • Illustrative examples for 5.4.B.5:
    • An AES 256-bit key is more secure than an AES 128-bit key.
    • An RSA 4096-bit key is more secure than an RSA 2048-bit key.
    • RSA and AES keys cannot be directly compared to one another in determining the level of security.

Learning Objective 5.4.C: Apply asymmetric encryption algorithms to encrypt and decrypt data.

• 5.4.C.1 Common asymmetric encryption algorithms include RSA and elliptic curve cryptography (ECC). Asymmetric algorithms are used in many applications, including digital signatures and digital certificates.
• 5.4.C.2 As with symmetric encryption, asymmetric encryption and decryption can be performed using the command line, specialized software, or web-based tools.
  • On a command line interface, users can encrypt or decrypt with OpenSSL.
  • Specialized software like RSA Encryption Tool is an open source tool that can encrypt and decrypt files.
  • There are many web-based tools for encrypting and decrypting files.
• 5.4.C.3 In a CLI, a user can generate an asymmetric key pair and encrypt or decrypt files as necessary.
  • To generate a 2048-bit RSA key pair and save the key to a file named rsa.pem use the command: openssl genrsa -out rsa.pem 2048
  • To extract the public key from rsa.pem into a file named public.pem, use the command: openssl rsa -pubout -in rsa.pem -outform PEM -out public.pem
  • To encrypt the file test using RSA encryption and the key file public.pem, use the command: openssl pkeyutl -encrypt -pubin -inkey public.pem -in test -out test.enc
  • To decrypt the test.enc file using the rsa.pem file, run the command: openssl pkeyutl -decrypt -inkey rsa.pem -in test.enc -out test

Learning Objective 5.5.A: Identify the application security principles of secure by design and security by default.

• 5.5.A.1 Secure by design is an initiative that encourages companies to include security in all phases of product development including design. When organizations implement secure by design, security is a design principle not just a technical feature.
• 5.5.A.2 Secure by design includes three design principles:
  • i. Companies should take ownership of customer security outcomes. Companies should build products that meet the security needs of their customers.
  • ii. Companies should embrace radical transparency and accountability. Sharing relevant security-related product news and updates quickly increases security for everyone.
  • iii. Companies should build organizational structure and leadership to implement secure by design. Companies need leaders who are focused on security and have a security-first posture.
• 5.5.A.3 Secure by design includes the concept of secure by default, which is the idea that security features for software and devices should be enabled by default. Devices and software should be secure to use out of the box, with security features already enabled.

Learning Objective 5.5.B: Explain how user input sanitization protects applications.

• 5.5.B.1 When users enter input into an application, the application typically encases that input in special characters to process it. The characters that encase the user input are called control characters and include the single quote, the double quote, and the semicolon.
• 5.5.B.2 When creating a program that takes user input, programmers should use a function to verify that user input meets their expected criteria and does not include any control characters that could be used to manipulate the system. This verification function can sanitize user input by removing potentially malicious characters, or it can give the user an error and force the user to provide different input. This can protect against many application attacks, including:
  • SQL injection attacks
  • XSS attacks
  • Directory traversal attacks