A successful injection attack can result in the following conditions:

• Denial of Service
• Lack of Accountability
• Disclosing Sensitive Information
• Data Loss / Corruption
• Complete Takeover

Limited only by the ability of the code running the parser

You can use the defense in depth strategy to mitigate injection. By limiting permissions and rights to the absolute minimum required to perform tasks, you can limit the damage that occurs if an attacker does manage to compromise an application—the attacker is limited by the rights of that application.

Injection Example

Consider the following SQL fragment:

‘x = x + ‘ + input + ‘;’

This expression results in the instructions, or the set of code that should be executed.

Consider the following inputs for the code:

input = ’12′

input = ’12;print(“foo”);’

Consider the first value when the input is 12. The program takes the value of x, adds 12 to it, and stores the result as the new value of x. Now, consider the second input. Because you are assembling the code and data together into a single string, the parser has no way to determine the difference between data and code.

The program considers the value of the string and determines that two expressions were actually intended, one to increment x and another to print the value foo. At this point, the malicious user has identified a vulnerable part of the application and can execute code under the context of the parser or interpreter.

Languages Vulnerable to Injection Attacks

Nearly every language or interpreter is vulnerable to an injection attack in the right threat environment. Injection attacks can occur in the following languages:

• SQL
• JavaScript/HTML
• LDAP
• XPath
• XSLT

The difference between an established language like LDAP, and a custom interpreter written to allow grouping of where clauses in SQL, is very small in the eyes of a malicious user. If a language has a parser or an interpreter, and if the input can be confused for instructions in the language or the way the language is applied, then the language is vulnerable to an injection attack.

Injection attacks can also occur in the following components:

• Server code and models or expressions
• Regular expressions
• Conditional constructs

Injection Details

All languages use some kind of control construct to express the meaning of phrases. Even in languages that are syntax free, the code is in the words themselves. In most practical languages; however, control codes are used predominantly or exclusively. Let’s look at a few commonly used control constructs.

• Single quote (‘) in SQL
• Null (\0) byte in C-style strings
• (<) and (>) in HTML, XML, SGML
• Semi colon (;) in ALGOL and derived programming languages

Injection uses specially crafted input that invokes these semantic control codes. When a malicious user can manipulate, influence, or control these semantic codes, then they can manipulate the meaning of a program to a parser or interpreter.

SQL Injection: Example

Now, you will look at an example of SQL injection. Authenticating a user against a database is a common programming practice. However, by modifying the username, you can perform an SQL injection attack.

SQL Injection: Input is Evil

The discussion on injection illuminates one of the most important concepts related to the OWASP Top 10: All input should be considered evil.

Almost every attack begins with user input; any input you receive could be evil and you need to validate it before you trust the input.

SQL Injection: Technique – Protecting Against Input

You can use a number of techniques, at the code and architecture level, to make your software more secure; however, these techniques will not protect you all the time. Even when used in conjunction with other techniques, these techniques may not be able to prevent all malicious input. Be sure to use defense-in-depth, redundant layers of defense, in order to reduce your risk as much as possible.

Click each tab to learn about the techniques to prevent malicious input.

Code

You can prevent malicious input by using the following techniques:

• Block list (blacklist)
• Allow list (whitelist)
• Escaping

 

The block and allow lists help you to strictly define what valid input looks like.

Use a whitelist wherever possible; use blacklists only as a secondary defense. Use escaping whenever user input may be echoed back to the user in HTML or any other form where it may be interpreted as script.

Example (Allow list)

If you have a GET parameter, and you are going to convert it into a 32-bit signed integer, you first validate that the input is made up of 1 to 12 digits optionally preceded by a hyphen (-). This is the only valid input that could signify an integer; all other input can simply be an error state.

Example (Block list)

A block list provides a list of disallowed input. If you are trying to protect against regular expression injection, you might choose to disallow the pound (#) character so that a malicious user could not comment out a line. If you chose a reasonable set of control characters from your parser or interpreter language, you can increase your defense against malicious input.

You can also use the escaping technique to provide extra metadata to the interpreter to tell it that the input is data and not code.

Example (Escaping)

You could encode all pound (#) characters with a preceding back slash (\) to tell the parser that the following character is a literal and not a control character.

You can also notate the difference between code and data. For SQL injection, this is the single most effective way to prevent injection attacks. SQL allows you to specify input at a completely different point than the instructions (code) that it is to execute. In this way, the parser can unambiguously determine the difference between code and data. Even using this technique, there are specific circumstances where a malicious user could still get input injected into code; however, it is that much more difficult and in many cases impossible.

Architecture

Instead of taking arbitrary user input when providing the user a set of choices, you can encode the choices into a table and provide the pointers or indexes in that table. This way, the user can manipulate only the pointer or index to the table, resulting in a selection that is always valid-the value exists in the table, or the index or pointer is invalid.

You can use the following architecture-level techniques to prevent attacks based on malicious input.

Object class for user input

–   UserInput<T>

–   UserInput<T>.Validate

–   UserInput<T>.Value

Table Indirection

Knowledge Check

Which of the following techniques can be used to protect against injection attacks?

Threat 2: Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) is a specific type of injection attack. Cross-Site Scripting affects browsers and primarily targets HTML and JavaScript languages. These attacks often use the HTTP protocol indirectly for performing some attacks. XSS is injection into a browser that occurs via HTML, JavaScript, embedded extensions, or other client-side technology. This threat is usually considered separate from general injection because of the browser-specific ways this attack occurs and because of its prevalence.

XSS attacks are categorized by the source of the malicious input―sometimes input is from the server, sometimes from the client. For all XSS attacks, the vulnerability results because some data (input) is interpreted to be instructions (code) by the browser. In all XSS attacks, this execution of code is performed in the context of the vulnerable server.

Click each tab to learn more about the types of XSS.

Reflected

A reflected attack occurs when a client sends malicious input to a server, and the malicious input is returned back to the client. The client executes code in the context of the current user.

A reflected XSS attack occurs in the following sequence:

1.  Malicious user convinces victim to send request to server with malicious

input.

2.  The server echoes malicious input back to client.

3.  The victim browser considers this script as coming from server.

Example

Consider a link for a programming book, as shown in the adjacent image. Would you click on a picture of a book that you wanted? However, instead of an actual link to the book on Amazon, you get the message shown in the image.

Your browser takes you to Amazon.com, but with code that the malicious user has supplied as input to the GET parameter “book”. If code executes on this site, the browser (and the victim) assumes that it has come from Amazon and not the site with the malicious book link. The malicious code could send the victim’s Amazon authentication cookie to the attacker, which would allow the attacker use the victim’s credit card.

Persistent

A persistent attack occurs when a client sends malicious input to a server, and the malicious input is stored at the server. Later, the input is returned to another client and the data is executed as code in the context of the current user.

A persistent XSS attack occurs in the following sequence:

1.  The attacker submits input to the server.

2.  The server stores the data.

3.  The server later returns data to different clients.

4.  Stored data is executed by the client as if it is coming from the server.

Consider a forum on a technical support web site. The forum takes input and stores it into a database. Let’s say the input is actually from a malicious user. When a victim browses that forum, the server retrieves the data from the database and renders it back to the victim. Because of vulnerability in the way the server renders the content into the browser, the malicious input is actually executed by the victim’s browser. The execution is in the context of the vulnerable web site, not the malicious user.

This attack is similar to a reflected attack, except that at the code layer, the variable that has the malicious data does not come from the request. Instead it comes from the internal database that houses the state for the application.

Malicious data can come from many places, such as the network, a database, a file, or a registry key. Malicious data can even get into the resource section of a binary loaded into your application.

DOM-based

A DOM-based attack occurs when malicious input is never read from the server but is instead sent by the malicious user from some previous state in the browser. The malicious input in this case is not attacking vulnerability on the server but the vulnerable client-side code instead.

In DOM-based XSS attacks, the client has code that is vulnerable to the attack.

In this type of attack, the malicious input does not pass from the server to the client in any form, but instead passes from the client in one site context to a client in another site context.

Just like on the server, JavaScript code must handle input very carefully. To prevent a DOM-based XSS attack, you should validate any input that comes from another Web site.

Example

Consider Web site code that prints the URL of the referrer page on the screen. An unsophisticated implementation would simply get the value from the referrer and write it to the web page. However, if the referrer location contained an embedded script block, the script would be written and executed as if it were actual code.

Just because the code is already running on the client doesn’t mean that you are safe―even client code can be vulnerable to XSS attacks.

Mitigating XSS Attacks

Let’s look at a few potential sources of input that a malicious user can control, and mitigation techniques that you can use to prevent malicious input.

Potential Sources of Input

A malicious user can control the following input sources:

• Window.location
• Document.referrer
• SERVER VARIABLES/Headers
• GET/POST parameters
• Database, file, or registry
• Cookies

Mitigation Techniques

You can use the following mitigation techniques to prevent malicious input:

• Allow list – Regex or list lookup.
• Escaping – Consider a trusted library for this functionality.
• Block list

You can also use defense-in-depth by enabling extra flags on cookies. The HttpOnly flag indicates that the cookie should not be available to the client script. Secure cookies indicate that the cookie holds sensitive data and should be sent only over an encrypted channel.

Knowledge Check

Match the XSS types with their corresponding explanations.

Threat 3: Broken Authentication and Session Management

Let’s look at the next threat―broken authentication and session management.

Broken authentication and session management is caused by poorly implemented custom code or misconfigured off-the-shelf code. The HTTP protocol does not support authentication and session management; so many developers create a custom implementation to work with HTTP. Frequently, these implementations are written without a complete understanding of their complexity.

Before creating a custom implementation, determine if a suitable framework component already exists, or if a small extension to an existing component would satisfy the requirement. If you do need to write custom code, make sure that you understand the threat environment inherent in an authentication and session system. Review the requirements and ensure that each is met, and review common problems to avoid common mistakes.

Authentication System: Mandatory Requirements

When implementing an authentication or session system, review the following requirements.

Click each requirement to learn more about its explanation.

Credentials are always protected: An authentication system will usually need to pass some secret over the network. If you are passing secrets or credentials over the network, they must be protected by encryption or hashed with a salt.

Strong passwords are required: The password complexity requirements depend on the data being stored. Consider a password that is at least eight characters long, and requires upper and lowercase letters, numbers, and punctuation.

Consider using a pass-phrase instead of a password and support the following pass-phrase formats.

• Multiple words combined 32 to 96 characters long.
• Punctuation marks.

Session IDs are not exposed in URL: After a user has been authenticated, a session ID or authentication token is given to the user. The user sends this token to the server in every request to indicate to the server that he has already been authenticated. In effect, the token is a replacement for the original authentication credentials. The token must not be exposed to theft, because taking the session ID allows an attacker to hijack the user’s session.

Session IDs are newly created during authentication, preventing session fixation attacks: New session ID should be created for each login to prevent session fixation attacks.

In a session fixation attack, a malicious user can usurp the session ID of a victim and take over his session. In this attack, the victim is tricked into logging into the web site, but instead of getting a new session ID, the victim uses the attacker-provided session ID.

Session IDs must be cryptographically random: Session IDs should be cryptographically random to prevent malicious users from guessing the session IDs.

Session IDs are only accepted from cookies: Session IDs should be cryptographically random to prevent malicious users from guessing the session IDs.

Log the user out after a period of inactivity: The session management system should include functionality to log users out after a period of inactivity. The logout functionality should invalidate the authentication token and require the user to log in again.

Use CAPTCHA to prevent automated attacks: A CAPTCHA distinguishes a real person from automated software. It is a test that is reasonably simple for a human to complete but difficult for a computer.

Consider a CAPTCHA system to protect your authentication systems from automated attacks.

Weak Choices for Session IDs

When implementing an authentication and session system, you should also consider the location of the storage of the session state. The client needs to store the session state to indicate to the server the authenticity of the client. Without this capability, the client would be forced to re-authenticate for each new request.

This page details some of the weak choices that can be made for the storage of the client state: URLs, persistent cookies, and form variables.

The best place to store the session ID is in a nonpersistent cookie that has the httpOnly flag set and the secure flag set.

Click each tab to learn more about the weak choices for the storage of the session state.

URL: You can easily share a URL with others, and you can easily copy and paste a URL into an e-mail message or chat session. URL is also sent to third parties automatically in the form of the referrer header.

Whenever the browser agent transitions from one Web site to another, it tells the new site where it is coming from, including any session ID that is stored in the URL.

You can also easily access a URL by using JavaScript. The JavaScript in the client can read the URL, and the URL will be available across frames such that a child or parent frame can access it.

Persistent Cookies: A persistent cookie is available to the browser even if you shut down the machine, reboot, and come back to a Web site. In that intervening time, some other person could have used the machine, or the cookie might have been stolen. Instead, use nonpersistent cookies. The browser automatically deletes a nonpersistent cookie when the browser is closed.

You can also use JavaScript to access a cookie. Fortunately, a cookie can be marked with httpOnly, which makes it unavailable from client code.

Form Variables: Some authentication systems store data in the form variable on the client. You can access form variables using JavaScript, and there are no mitigation techniques.

From an engineering perspective, systems based on using form variables are usually limited because many Web interactions do not use a form to interact with the server.

Recommendations for Authentication

A session-based system identifies a user returning to a Web site for personalization and identification and authenticates a new or returning user to the Web site to provide access to restricted resources. Although it is tempting to use a single cookie for both purposes, subtle differences make authentication and identification mutually exclusive.

Requirements of an Authentication Token

• It is a replacement for a user’s credentials.
• It allows access to restricted parts of the Web site.
• It should always use a non-persistent cookie because the cookie should be deleted when the user closes the browser.
• As an optimization for highly scalable Web sites, a completely random session ID can be replaced with an encrypted token of the user’s ID in the system along with a timestamp. This way, the session ID does not have to be “remembered” by the server and can be shared with any server that has the correct decryption key. This technique allows a highly scalable Web application to be split across many servers.

Requirements of an Identification Token

• It is not strictly necessary and it identifies returning users to the site.
• As such, it must use a persistent cookie so that it is not deleted when the user closes the browser.
• It should be public information; if stolen or changed, it should not cause significant concern.
• It is not a replacement for the credentials and should not allow access to restricted resources of a Web site.

Knowledge Check

Which of the following are authentication systems mandatory requirements?

Threat 4: Insecure Direct Object References

Insecure direct object references occur when an application does not validate that the client has access to a resource pointed by a reference. This frequently happens when the application sends the client a set of links to URLs that have references directly to the objects, such as a database row. A malicious user manipulates the reference to access other, restricted URLs, and the data pointed by these URLs may be available to the malicious user.

Additionally, depending on the functionality of the URL, a malicious user can access the data to modify and tamper it or elevate privileges. And, predictable IDs might lead to complete disclosure. For example, identity columns in a database are completely predictable, and a malicious user can easily determine all of the IDs in the system.

Example Objects

The following objects are susceptible to direct object reference vulnerabilities:

• Files and filenames
• Registry keys
• Ports and network resources
• Tables, columns, and rows in a database
• Data from an XML document

Like injection and XSS, evil input is the root cause of this threat. Always validate input before trusting it.

Insecure Direct Object References Illustrated

Here is an example to help you understand insecure direct object references. In the end, you will notice that while clicking the actual URL and rendering the account page, there is no authorization check and no check at time of use. As a result, the malicious user realizes that the URL provides access to all of the accounts in the system.

Insecure Direct Object References: TOCTOU

Time of Check Time of Use vulnerabilities occur any time a resource is validated and then a malicious user is able to alter the reference before the resource is used. Usually this occurs because an authorization check is performed on one page and the use of the resource is on a different page. In between these two points, a malicious user can change the reference to point to a resource for which he or she is not actually authorized.

You must assume that any resource references that are a result of user input are potentially malicious. If a resource has not been recently validated, an additional authorization check must be performed to validate that the user in question does indeed have access to the resource. To help prevent insecure direct object references, you can use session-based indirection. (Session-based Indirection is a programming technique used to provide a lookup index for a resource instead of providing a direct reference. This indirect method for referencing a resource makes it much less likely that an attacker can gain access to additional resources that are on the server but not purposefully exposed by the application under attack.)

Example

A user has permission to download five images and they are asked to select one. If you give them five links to the pictures directly, they might be able to guess that they can access additional pictures that they shouldn’t have access to just by changing the URL to reference a different picture. Instead, you can put the five links in a table so that the table has the direct links and the user just selects the appropriate index. When the user selects one of the five valid indexes you retrieve the corresponding URL from the table and return the image to the user.

Knowledge Check

Which of the following are the results of insecure direct object references?

Threat 5: Cross-Site Request Forgery (CSRF)

Cross-site request forgery (CSRF), occurs when an action performed by a Web application on behalf of a user does not protect itself from forged requests. If a malicious user can forge a request, and convince a victim to send the request, the malicious user can perform any action the victim is authorized for.

Because many intranets support a single sign-on environment where authentication to a site can be performed transparently, the victim need not even use the application prior to being tricked into sending the forged request. Even if the victim is not authenticated and the application does not integrate with a single sign-on system, many authentication systems will intercept a request, require authentication, and then transparently transfer a client back to the original requested location. Because of this, even unauthenticated victims are subject to such attacks.

Results

A successful CSRF threat results in the following consequences:

• Elevation of privilege
• Denial of Service
• Spoofing
• Tampering
• Repudiation

To the vulnerable web site, there is no way to determine that the request is from a malicious user or the victim. If the victim can perform an action, so can the malicious user.

CSRF Illustrated

Let’s see an example to understand CSRF. A malicious user lures a victim to read some malicious content (in a web site or e-mail). A malicious request is automatically sent to the vulnerable site (in an IMG tag or something similar), or the user might actually click or submit something to initiate the request.

If the conditions are right, the malicious request includes the victim’s credentials when sent to the vulnerable site. If it works, the unauthorized transaction is accepted or returns sensitive data to the malicious user.

Regardless of the success or failure of the attack, the attack is invisible to the potential victim.

Mitigating CSRF Attacks

The primary technique to protect against CSRF attacks is to share a secret with the client. To forge a client request, the attacker needs to guess or predict the shared secret. If you use a cryptographically strong secret, it is virtually impossible to guess.

Click each tab to see options for a cryptographically strong secret.

Nonce: A nonce is a one-time cryptographically random token that is returned to the client. For each request, a different nonce is created, so secrets are not reused. The nonce is sent to the client, and also saved on the server, and then compared when the operation request comes in. The downside of a nonce is that it needs to be stored on the server. If it’s stored in memory, it limits system scalability across multiple web or application servers.

HMAC: An HMAC is an encrypted hash or “keyed hash” of the page combined with the session ID. If you create an HMAC of the Page URL, plus the User ID or Session ID a comparison value can be created that will make distributed attacks very difficult. The downside is that every time the user returns to the page it is possible that the same page URL and user ID might be generated, making it possible to steal the secret and reuse it. So you should add a timestamp to the HMAC to ensure the secret value is unique for each request. The timestamp would be concatenated with the page URL and user ID. Like a salt, the timestamp plain text need not be kept secret or protected, and is most easily sent to the client in a hidden form field or placed in a state cookie. During the request, the timestamp is retrieved and added to the URL and ID to generate the comparison HMAC.

Mitigating CSRF Attacks – Defense in Depth Techniques

The following defense-in-depth techniques help mitigate CRSF attacks and should be used in coordination with primary mitigation techniques:

Do not use GET parameters. Although it’s possible to perform CSRF attacks via POST parameters, it limits the types of manipulation a malicious user can perform on the victim to forge the request.

Do not put the secret in the URL; the URL should not to contain any kind of secret. Broken authentication and session can be seen in weblogs and accessed via JavaScript.

Send successful logins to a well-known location instead of automatic redirection. Do not resubmit POST parameters if you need to perform redirection.

Knowledge Check

Which of the following are the results of cross-site request forgery?

Threat 6: Security Misconfiguration

After you deploy your Web application online, it undoubtedly will encounter a number of attacks. To prevent these attacks from being successful, you need to follow sound operational practices related to security.

Inadequate operational practices can lead to exploits of security features or of known vulnerabilities. Improper permissions may allow malicious users to perform actions that they shouldn’t.

Misconfiguration Types

Missing patches: Patches, hotfixes, service packs, and updates contain the latest security fixes and need to be applied when they are available.

Misconfigured or disabled security features: If a security feature is disabled or not configured, it cannot provide protection.

Default accounts: Default accounts may allow a malicious user to automatically login with the credentials published in product documentation.

Unnecessary/unused services or features: These represent an increased risk for security defects. Bugs exist even in the best-written code, By disabling unused and unnecessary services, code, and DLLs, you limit the amount of code that needs to be maintained and patched. When in doubt, turn features off, and turns them back on only if you need them. (Not recommended for production systems).

Administrative back doors: Administrative back doors are known as front doors in the hacking community. It’s absolutely critical to secure these administrative endpoints for what they are: the keys to the kingdom. Do not rely on a malicious user overlooking the functionality; it can always be discovered. Security through obscurity is no security at all.

Parts of the Stack Vulnerable to Misconfiguration

• OS
• Environment/Platform
• Web or Application Server
• Database Server
• Application(s)
• Components and Libraries
• Services

Security Misconfiguration: Dynamic Threat Environment

The online world is a dynamic environment where threats develop and manifest every single day. To mitigate and maintain a secure environment, you need a process that can quickly adapt to these threats. A repeatable process is required to constantly reevaluate the environment and address new or growing threats, and should include the following:

• Updating the environment: This includes changes like adding or removing network segments, and changing configuration.
• New products: New products or functionality may be needed to deal with a threat that did not exist when the application was released.
• New service pack or patches: Use a regular process to apply the latest service packs, patches, hotfixes, and updates to all of your software, from top to bottom.

In addition, your development, test, and staging environments should precisely match the production environment. If your environments don’t match, you might discover on release day that your application doesn’t work as expected.

Example

Consider the following real-world scenario we encountered with a customer. The team was working on an application using NTLM authentication, and they were developing a major revision to the application. None of the developers were actually using NTLM during development because they were not members of the domain. They considered setting up a matching domain but didn’t want to administer it, and it seemed like a trivial detail. Two weeks before the application was released, the program manager realized that no one has tested the application with NTLM, but decided he wasn’t concerned because he felt NTLM wouldn’t cause them any problems. However, during testing, one of the testers discovered that the database connection pooling incorporated in the new version didn’t work with NTLM. There was no time to fix the software, so they had to change the production environment instead, causing a lot of last-minute work and significant risk.

If your development, test, and staging environments don’t match, you might discover too late that your application doesn’t work correctly because some vital pieces are missing.

Mitigating Security Misconfiguration: Repeatable Hardening

A well-defined process provides your first line of protection against a dynamic threat environment. A regular, repeatable hardening process is required to make sure your environment is protected against the latest threats.

Keep the following in mind as you create and implement your process:

• Research all stack components for potential vulnerabilities
  • Vendor/project sites
  • Security sites
  • Security mailing lists/aliases
  • Search for any additional information
  • Review all settings and configurations
    • Pay close attention to security features
    • Review all enabled features
      • Disable any unnecessary features
      • Repeat the process:
        • At regular intervals; monthly, bimonthly
        • Every time a deployment or configuration changes

Knowledge Check

Which of the following are involved in the hardening process?

Threat 7: Insecure Cryptographic Storage

The most common error regarding cryptography is the failure to use it. Most people significantly underestimate the value of their data and the cost of a data loss. Insecure cryptographic storage is the misapplication or missing application of cryptography to a software system.

The level of effort you use to protect your data depends on its sensitivity. Sensitive Information includes personal information, such as health records, social security numbers, and financial data, including credit card numbers. You can even consider order history or date of birth as sensitive.

The other type of sensitive information is security information. Usually, this information is tied to an authentication or session management system. This information enables an individual to act as a specific principal on a system; anyone who can access this information can be that principal, so it needs to be well guarded.

Causes of Insecure Cryptography

• Failure to encrypt sensitive information
• Unsalted hash
• Unsafe key generation
• Unsafe key storage
• Failure to rotate keys
• Bad cryptography
  • Poor/weak algorithm choice
  • Custom cryptographic algorithms
  • Insufficient cryptographic protocols

Cryptography Fundamentals

To use cryptography effectively, you need to be aware of six fundamental principles.

Click each tab to learn more about these principles.

Randomness: Random numbers play an extremely important part in many aspects of cryptography. Many implementations of pseudo-random number generators (PRNG or RNG) are unacceptable for use in cryptography because they generate predictable number sequences. Given an element from a sequence, if you can determine with a high probability or with certainty the next number in a sequence of random numbers, then the PRNG cannot be used within the domain of cryptography.

Rand, Rnd, and Random functions use a predictable sequence of numbers, provided by Linear Congruential Generator (LCG). Most cryptography APIs provide their own random number generator, which produce cryptographically random sequences of numbers, though at a higher cost than an LCG. When using random numbers with cryptography, be certain that they are random enough.

Encryption: Encryption is a method of converting plain text into cipher text with the use of a key. The plain text should not be retrievable from the cipher text without knowing the value of the key. Decryption is the reverse process of turning the cipher text back into plain text.

Encryption algorithms come in many forms. Symmetric algorithms use the same key value for both encryption and decryption, while asymmetric algorithms use different keys for encryption and decryption. Asymmetric algorithms are at the basis of key exchange protocols and public key cryptography. Another fundamental difference between different encryption algorithms is defined by the data the algorithm is used on. Stream ciphers are used for data in transit and are often implemented for network applications. Block ciphers operate on fixed-sized blocks of data at rest, although block ciphers can be used in ways to simulate a stream cipher.

Never use custom algorithms; they are unlikely to be secure or well-designed. Creating real cryptographic algorithms requires significant knowledge of advanced mathematics. Don’t create your own algorithm unless you have an advanced degree in mathematics and are publishing your algorithm for peer review.

Hash: A hash is a one-way function that, given an input value, returns a fixed-bit output value; it is common to many computing applications. In a cryptographic hash, it is computationally infeasible to determine anything about the input of a cryptographic hash based on the computed output hash value.

Cryptographic hashes are useful for protecting values for which the original input is unimportant. Hashes also play an important role in other cryptographic applications like keyed hashes, block encryption, and signatures.

A standard hash is subject to an offline attack, most often characterized by the use of a rainbow table. A malicious user can precompute potential hash values and store them before attempting an attack. By adding a cryptographically random additional value to your hash, the hacker needs to compute the secret value with the additional salt, which can make such an offline attack infeasible. You add a salt to a hash by choosing a random value and adding it to the value to be hashed. The combined value is hashed, and often the salt is then stored in plain text along with the hash value. If the hashed value needs to be compared with input (for instance to check a password), the input to be verified is combined once again with the salt and then the hash is compared to the stored hash.

Nonce: A nonce is a one-time use random value. Typically, a nonce is used to modify the challenge or response in an authentication system to make it more difficult to break.

Signature: A digital signature combines public-key cryptography with a cryptographic hash. A digital signature ensures that a signature is provably from the holder and that the data that was signed has not been changed in any way. The plain text is hashed and that hash is then encrypted with the private key of the signer.

Anyone who wants to verify the signature can decrypt the hash with the author’s public key, perform their hash of the plain text, and compare the hash. If they are the same, the content has not changed. Only the author’s public key can be used to decrypt the hash encrypted by the author’s private key.

Protocols: A protocol defines the set of rules for using different cryptographic building blocks. IPSec, SSL, and Kerberos all describe how to use the other building blocks to provide a cryptographic function.

IPSec and SSL are network encryption protocols, Kerberos performs authentication, and EFS encrypts parts of the file system on Windows. Custom authentication mechanisms, as discussed in Broken Authentication and Session Management threat, are also protocols. Creating new protocols requires a complete understanding of the cryptographic building blocks as well as how to successfully assemble them. Attacking the building blocks themselves is very difficult; most cryptography failures result from a weak protocol created by an unknowledgeable developer.

Mitigating Insecure Cryptographic Storage: Securing Keys

Key generation is critical to any use of symmetric encryption. The following factors help you secure keys:

• Complexity
  • 8 character 10-radix vs. 8 character 64-radix
  • Generation
    • Requires a cryptographic random number generator
    • Storage
      • Not in code, in your database, or in a file
      • Rotation
        • How much data can one key unlock?

Example

You generated a key that is 20 characters long and is stored in DPAPI. Your application has been running for ten years, and your original key is still in use. If some of your data was compromised and someone finally decrypts the data and determines the key, how much data have you lost? Did you lose the data that was originally compromised? Or did you lose the originally compromised data as well as all other data encrypted with the same password for the last ten years?

Knowledge Check

Which of the following may result in cryptographic weakness?

Threat 8: Failure to Restrict URL Access

Some threats are caused by a failure to restrict URL access from unauthorized users. This is a subset threat caused by insecure direct object references.

Your application should perform authorization holistically, checking at the beginning of each request to ensure that the client is authorized to access the resource.

Protecting an application by hiding links from a user who does not have access does not provide real access control. A malicious user can find out about hidden links using a number of methods:

• Network sniffing
• Running the application in a local environment
• Brute force
• Deceiving an administrator

Typical Impact

• Failure to restrict URL access allows attackers to:
• Invoke functions and services that they are not authorized for
• Access other users’ accounts and data
• Perform privileged actions

Failure to Restrict URL Access Illustrated

The following animation illustrates the failure to restrict URL access threat.

Mitigating Failure to Restrict URL Access

When you develop a Web application, keep in mind the following to mitigate attacks related to unauthorized URL access:

• For each URL, a site needs to perform the following:
  • Restrict access to authenticated users (if not public)
  • Enforce any user- or role-based permissions (if private)
  • Completely disallow requests to unauthorized page types (such as
  • config files, log files, and source files)
  • Verify your architecture by:
    • Using a simple and positive model at every layer
    • Being sure that you actually have a mechanism at every layer
    • Using policy mechanisms; do not hard code anything
    • Verify the implementation by:
      • Forgetting automated analysis approaches
      • Verifying that each URL in your application is protected
      • Verifying the server configuration to disallow requests to
      • unauthorized file types
      • Using your browser to forge unauthorized requests

Knowledge Check

Which of the following depicts the typical impact of failure to restrict URL Access?

Threat 9: Insufficient Transport Layer Protection

Insufficient transport layer protection occurs when SSL or another transport layer security protocol is not used to encrypt vulnerable data. You should always use SSL to protect a session ID or an authentication token in an authentication system.

A session ID tells the server that the client is authenticated, providing a set of credentials for a specific period. If SSL is not used, a malicious user can simply sniff vulnerable session IDs and use them to impersonate the victim.

Another common issue with this threat is bad SSL certificates, which causes a client to become accustomed to saying “yes” to certificate error warnings to use a vulnerable site. This threat can result in a downgrade attack, which allows a malicious user to place himself between a victim and a vulnerable web site. The malicious user performs a man-in-the-middle attack, where he is able to convince both the server and the client victim that only weak encryption is supported. After this weak encryption is negotiated, the malicious users can brute-force decrypt the encrypted transport session and get access to the plain text. You can prevent this attack by using strong algorithms.

Encrypting the connection from your client may not be sufficient. For instance, a rogue administrator at a hosting provider could steal credit card details from the network if your database connection is not encrypted. Use SSL, IPSec, or another transport layer security protocol to protect the connections between the physical tiers of your application.

Mitigating Insufficient Transport Layer Protection

The following guidelines will help you implement transport layer protection. Ensure that:

• You enable SSL or IPSEC.
• Your transport layer security protects all secure resource exchanges (any place authentication token is used.)
• You set the secure flag on session ID cookies or authentication token cookies. Additionally, when any important information is sent over the wire, use IPSec or SSL to encrypt the information.
• You avoid mixed SSL, which is content on a single page that comes from both SSL and non-SSL sources.
• You use SSL or IPSec for communication to the data tier as well.
• SSL certificates are valid.
  • Not expired
  • Use the correct name (CN)
  • Not revoked
  • Trusted authority
  • You use extended validation certificates.
    • Makes address bar green
    • Strong algorithms are supported; reject weak ones.
    • You implement strong cryptography.
      • At least 2048-bit key exchange
      • At least 256-bit encryption

Threat 10: Unvalidated Redirects and Forwards

Unvalidated forwards can allow a malicious user to spoof your site. The malicious user provides the victim with what looks like a link to your site but actually redirects the victim to a malicious location. Many authentication systems use redirection to return a requester to an authorized URL after login, so the user may not notice that the site is incorrect.

To protect an application against unvalidated redirects and forwards, you need to validate the input as well as the referrer header, which can be controlled or manipulated by a malicious user.

Results

Unvalidated redirects and forwards can result in the following consequences:

• Complete spoof of your site. A phishing attack could redirect the client to a malicious Web site. A malicious user can also use redirects in combination with a CSRF attack. For example, if the vulnerable action checks the referrer to validate that it comes from your vulnerable site, the unvalidated forward makes the mitigation insufficient.
• Bypassed authorization checks. In most common Web platforms, an API call exists that directly transfers a client to another location, bypassing authorization checks. If such an API is used to implement an unvalidated redirector, a malicious user simply needs to use the redirect as the entry point to all other resources on the site.

Mitigating Unvalidated Redirects and Forwards

To mitigate unvalidated redirects and forwards, use the following guidelines:

• Never use internal transfer without authorizing the user for the target URL. In general, it is far easier to use a redirect method, which will issue a 302 response to the client and ask the client to make another request for the target URL. At that point, it will be like any other request for the target.
• Wherever possible, restrict the usage of your forward functionality to some set of authorized users, instead of all unauthorized users.
• Use weblogs to identify potential code. Look for HTTP status codes in the 300 series: 301, 302, 303, and 307.
• Where possible, use redirect, or redirect to static locations.
• When redirecting to a parameter, validate the parameter to make sure that it is an expected redirect. Use table indirection where possible to turn a dynamic set of potential choices into a table of valid keys. At the very least, allow only relative redirects.

Table Indirection Technique

If you have a potential set of valid locations that the client is allowed to redirect to, consider using table indirection. Maintain a table of allowed URIs, and then allow the client to specify the keys into the table only and not the actual URI itself.

 

When the key is returned, look up the URI in the table and then redirect to that location.

In the following URL, the color blue indicates user input, and the color grey is the unencoded value of the redirect parameter.

/Login.aspx?redirect=%2fAccount%3Fid%3d1234(/Account?id=1234)

becomes

/Login.aspx?redirectKey=13&param1=1234

Even if your system requires additional data to be sent to the location, the table indirection can still be successful. Simply take the additional parameter and combine it with the URI value from the table. Be careful of any type of injection attack here; even though you are restricting the malicious user, you still need to validate the data in “param1”.

Knowledge Check

Sort the techniques based on the threats. Which of the following may be included in the Insufficient transport layer protection category?

Threat 10: Unvalidated Redirects and Forwards

Unvalidated forwards can allow a malicious user to spoof your site. The malicious user provides the victim with what looks like a link to your site but actually redirects the victim to a malicious location. Many authentication systems use redirection to return a requester to an authorized URL after login, so the user may not notice that the site is incorrect.

To protect an application against unvalidated redirects and forwards, you need to validate the input as well as the referrer header, which can be controlled or manipulated by a malicious user.

Results

Unvalidated redirects and forwards can result in the following consequences:

• Complete spoof of your site. A phishing attack could redirect the client to a malicious Web site. A malicious user can also use redirects in combination with a CSRF attack. For example, if the vulnerable action checks the referrer to validate that it comes from your vulnerable site, the unvalidated forward makes the mitigation insufficient.
• Bypassed authorization checks. In most common Web platforms, an API call exists that directly transfers a client to another location, bypassing authorization checks. If such an API is used to implement an unvalidated redirector, a malicious user simply needs to use the redirect as the entry point to all other resources on the site.

Mitigating Unvalidated Redirects and Forwards

To mitigate unvalidated redirects and forwards, use the following guidelines:

• Never use internal transfer without authorizing the user for the target URL. In general, it is far easier to use a redirect method, which will issue a 302 response to the client and ask the client to make another request for the target URL. At that point, it will be like any other request for the target.
• Wherever possible, restrict the usage of your forward functionality to some set of authorized users, instead of all unauthorized users.
• Use weblogs to identify potential code. Look for HTTP status codes in the 300 series: 301, 302, 303, and 307.
• Where possible, use redirect, or redirect to static locations.
• When redirecting to a parameter, validate the parameter to make sure that it is an expected redirect. Use table indirection where possible to turn a dynamic set of potential choices into a table of valid keys. At the very least, allow only relative redirects.

Table Indirection Technique

If you have a potential set of valid locations that the client is allowed to redirect to, consider using table indirection. Maintain a table of allowed URIs, and then allow the client to specify the keys into the table only and not the actual URI itself.

 

When the key is returned, look up the URI in the table and then redirect to that location.

In the following URL, the color blue indicates user input, and the color grey is the unencoded value of the redirect parameter.

/Login.aspx?redirect=%2fAccount%3Fid%3d1234(/Account?id=1234)

becomes

/Login.aspx?redirectKey=13&param1=1234

Even if your system requires additional data to be sent to the location, the table indirection can still be successful. Simply take the additional parameter and combine it with the URI value from the table. Be careful of any type of injection attack here; even though you are restricting the malicious user, you still need to validate the data in “param1”.

Knowledge Check

Sort the techniques based on the threats. Which of the following may be included in the Unvalidated redirects and forwards category?