OWASP - User contributions [en]

Clickjacking Cheat Sheet

2012-11-16T16:12:29Z

Micheal w s mcnamee:

= DRAFT CHEAT SHEET - WORK IN PROGRESS =

= Introduction =

This article is focused on providing developer guidance on Clickjack/UI Redress attack prevention.

= References =

[https://www.owasp.org/index.php/Clickjacking https://www.owasp.org/index.php/Clickjacking]

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Glossary

2012-11-16T08:42:42Z

Micheal w s mcnamee: /

{{compactTOC}}

{{SecureSoftware}}

==0–9==
===3DES===
See also: [[#Triple DES|Triple DES]]
==A==
===Access Control List===
A list of credentials attached to a resource indicating whether or not the credentials have access to the resource.
===ACL===
Access Control List
===Active attack===
Any network-based attack other than simple eavesdropping — i.e., a passive attack).
===Advanced Encryption Standard===
A fast general-purpose block cipher standardized by NIST (the National Institute of Standards and Technology). The AES selection process was a multi-year competition, where Rijndael was the winning cipher.
===AES===
See also: [[#Advanced Encryption Standard|Advanced Encryption Standard]]
===Anti-debugger===
Referring to technology that detects or thwarts the use of a debugger on a piece of software.
===Anti-tampering===
Referring to technology that attempts to thwart the reverse engineering and patching of a piece of software in binary format.
===Architectural security assessment===
See also: [[#Threat model|Threat Model]]

===ASN.1===
Abstract Syntax Notation is a language for representing data objects. It is popular to use this in specifying cryptographic protocols, usually using DER (Distinguished Encoding Rules), which allows the data layout to be unambiguously specified.

See also: [[#Distinguished Encoding Rules|Distinguished Encoding Rules]].
===Asymmetric cryptography===
Cryptography involving public keys, as opposed to cryptography making use of shared secrets.

See also: [[#Symmetric cryptography|Symmetric cryptography]].
===Audit===
In the context of security, a review of a system in order to validate the security of the system. Generally, this either refers to code auditing or reviewing audit logs.

See also: [[#Audit log|Audit log]], [[#Code auditing|Code auditing]].
===Audit log===
Records that are kept for the purpose of later verifying that the security properties of a system have remained intact.
===Authenticate-and-encrypt===
When using a cipher to encrypt and a MAC to provide message integrity, this paradigm specifies that one authenticates the plaintext and encrypts the plaintext, possibly in parallel. This is not secure in the general case.

See also: [[#Authenticate-then-encrypt|Authenticate-then-encrypt]], [[#Encrypt-then-authenticate|Encrypt-then-authenticate]].

===Authenticate-then-encrypt===
When using a cipher to encrypt and a MAC to provide message integrity, this paradigm specifies that one authenticates the plaintext and then encrypts the plaintext concatenated with the MAC tag. This is not secure in the general case, but usually works well in practice.

See also: [[#Authenticate-and-encrypt|Authenticate-and-encrypt]], [[#Encrypt-then-authenticate|Encrypt-then-authenticate]].
===Authentication===
The process of verifying identity, ownership, and/or authorization.
==B==
===Backdoor===
Malicious code inserted into a program for the purposes of providing the author covert access to machines running the program.
===Base 64===
A method for encoding binary data into printable ASCII strings. Every byte of output maps to six bits of input (minus possible padding bytes).

===Big endian===
Refers to machines representing words most significant byte first. While x86 machines do not use big endian byte ordering (instead using little endian), the PowerPC and SPARC architectures do. This is also network byte order.

See also: [[#Little endian|Little endian]].
===Birthday attack===
Take a function f() that seems to map an input to a random output of some fixed size (a pseudo-random function or PRF). A birthday attack is simply selecting random inputs for f() and checking to see if any previous values gave the same output. Statistically, if the output size is S bits, then one can find a collision in 2S/2 operations, on average.
===Bit-flipping attack===
In a stream cipher, flipping a bit in the ciphertext flips the corresponding bit in the plaintext. If using a message authentication code (MAC), such attacks are not practical.
===Blacklist===
When performing input validation, the set of items that — if matched — result in the input being considered invalid. If no invalid items are found, the result is valid.

See also: [[#Whitelist|Whitelist]].

===Blinding===
A technique used to thwart timing attacks.
===Block cipher===
An encryption algorithm that maps inputs of size n to outputs of size n (n is called the block size). Data that is not a valid block size must somehow be padded (generally by using an encryption mode). The same input always produces the same output.

See also: [[#Stream cipher|Stream cipher]].
===Blowfish===
A block cipher with 64-bit blocks and variable length keys, created by Bruce Schneier. This cipher is infamous for having slow key-setup times.
===Brute-force attack===
An attack on an encryption algorithm where the encryption key for a ciphertext is determined by trying to decrypt with every key until valid plaintext is obtained.
===Buffer overflow===
A buffer overflow is when you can put more data into a memory location than is allocated to hold that data. Languages like C and C++ that do no built-in bounds checking are susceptible to such problems. These problems are often security-critical.
==C==
===CA===
See Certification Authority.
===Canary===
A piece of data, the absence of which indicates a violation of a security policy. Several tools use a canary for preventing certain stack-smashing buffer overflow attacks.

See also: [[#Buffer overflow|Buffer overflow]], [[#Stack smashing|Stack smashing]].
===Capture-replay attacks===
When an attacker can capture data off the wire and replay it later without the bogus data being detected as bogus.
===Carter-Wegmen Counter (data encryption mode)===
A parallelizable and patent-free high-level encryption mode that provides both encryption and built-in message integrity.

===CAST5===
A block cipher with 64-bit blocks and key sizes up to 128 bits. It is patent- free, and generally considered sound, but modern algorithms with larger block sizes are generally preferred (e.g., AES).

See also: [[#AES|AES]].
===CBC Mode===
See also: [[#Cipher-Block Chaining mode|Cipher-Block Chaining mode]].

===CBC-MAC===
A simple construction for turning a block cipher into a message authentication code. It only is secure when all messages MAC’d with a single key are the same size. However, there are several variants that thwart this problem, the most important being OMAC.

See also: [[#OMAC|OMAC]].
===CCM mode===
See also: [[#Counter mode with CBC-MAC (CCM)|Counter mode with CBC-MAC (CCM)]].

===Certificate===
A data object that binds information about a person or some other entity to a public key. The binding is generally done using a digital signature from a trusted third party (a certification authority).
===Certificate Revocation List===
A list published by a certification authority indicating which issued certificates should be considered invalid.
===Certificate Signing Request===
Data about an entity given to a certification authority. The authority will package the data into a certificate and sign the certificate if the data in the signing request is validated.
===Certification Authority===
An entity that manages digital certificates — i.e., issues and revokes. Verisign and InstantSSL are two well known CAs.
===CFB mode===
See also: [[#Cipher Feedback mode|Cipher Feedback mode]].
===Chain responder===
An OCSP responder that relays the results of querying another OCSP responder.

See also: [[#OCSP|OCSP]].

===Choke point===
In computer security, a place in a system where input is routed for the purposes of performing data validation. The implication is that there are few such places in a system and that all data must pass through one or more of the choke points. The idea is that funneling input through a small number of choke points makes it easier to ensure that input is properly validated. One potential concern is that poorly chosen choke points may not have enough information to perform input validation that is as accurate as possible.
===chroot===
A UNIX system call that sets the root directory for a process to any arbitrary directory. The idea is compartmentalization: Even if a process is compromised, it should not be able to see interesting parts of the file system beyond its own little world. There are some instances where chroot "jails" can be circumvented; it can be difficult to build proper operating environments to make chroot work well.
===Cipher-Block Chaining mode===
A block cipher mode that provides secrecy but not message integrity. Messages encrypted with this mode should have random initialization vectors.
===Cipher Feedback mode===
A mode that turns a block cipher into a stream cipher. This mode is safe only when used in particular configurations. Generally, CTR mode and OFB mode are used instead since both have better security bounds.
===Ciphertext===
The result of encrypting a message.

See also: [[#Plaintext|Plaintext]].
===Ciphertext stealing mode===
A block cipher mode of operation that is similar to CBC mode except that the final block is processed in such a way that the output is always the same length as the input. That is, this mode is similar to CBC mode but does not require padding.

See also: [[#Cipher-Block Chaining mode|Cipher-Block Chaining mode]], [[#Padding|Padding]].

===CLASP===
See also: [[#Comprehesive, Lightweight Application Security Process|Comprehesive, Lightweight Application Security Process]]

===Code auditing===
Reviewing computer software for security problems.

See also: [[#Audit|Audit]].
===Code signing===
Signing executable code to establish that it comes from a trustworthy vendor. The signature must be validated using a trusted third party in order to establish identity.
===Compartmentalization===
Separating a system into parts with distinct boundaries, using simple, well- defined interfaces. The basic idea is that of containment — i.e., if one part is compromised, perhaps the extent of the damage can be limited.

See also: [[#Jail|Jail]], [[#Chroot|Chroot]].
===Comprehesive, Lightweight Application Security Process===
An activity-driven, role based set of process components whose core contains formalized best practices for building security into your existing or new-start software development lifecycles in a structured, repeatable, and measurable way.

See also:
* [[:Category:OWASP CLASP Project|OWASP CLASP Project]]

===Context object===
In a cryptographic library, a data object that holds the intermediate state associated with the cryptographic processing of a piece of data. For example, if incrementally hashing a string, a context object stores the internal state of the hash function necessary to process further data.
===Counter mode===
A parallelizable encryption mode that effectively turns a block cipher into a stream cipher. It is a popular component in authenticated encryption schemes due to its optimal security bounds and good performance characteristics.
===Counter mode with CBC-MAC (CCM)===
An encryption mode that provides both message secrecy and integrity. It was the first such mode that was not covered by patent.

===CRAM===
A password-based authentication mechanism using a cryptographic hash function (usually MD5). It does not provide adequate protection against several common threats to password-based authentication systems. HTTP Digest Authentication is a somewhat better alternative; it is replacing CRAM in most places.
===CRC===
Cyclic Redundancy Check. A means of determining whether accidental transmission errors have occurred. Such algorithms are not cryptographically secure because attackers can often forge CRC values or even modify data maliciously in such a way that the CRC value does not change. Instead, one should use a strong, keyed message authentication code such as HMAC or OMAC.

See also: [[#HMAC|HMAC]], [[#Message Authentication Code|Message Authentication Code]], [[#OMAC|OMAC]].
===Critical extensions===
In an X.509 certificate, those extensions that must be recognized by any software processing the certificate. If a piece of software does not recognize an extension marked as critical, the software must regard the certificate as invalid.

===CRL===
See also: [[#Certificate Revocation List|Certificate Revocation List]].

===Cross-site request forgery===
[[CSRF]] is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attackers choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.
===Cross-site scripting===
A class of problems resulting from insufficient input validation where one user can add content to a web site that can be malicious when viewed by other users to the web site. For example, one might post to a message board that accepts arbitrary HTML and include a malicious code item.
===Cryptanalysis===
The science of breaking cryptographic algorithms.
===Cryptographic hash function===
A function that takes an input string of arbitrary length and produces a fixed- size output — where it is unfeasible to find two inputs that map to the same output, and it is unfeasible to learn anything about the input from the output.
===Cryptographic randomness===
Data produced by a cryptographic pseudo-random number generator. The probability of figuring out the internal state of the generator is related to the strength of the underlying cryptography — i.e., assuming the generator is seeded with enough entropy.
===Cryptography===
The science of providing secrecy, integrity, and non-repudiation for data.
===CSR===
See also: [[#Certificate Signing Request|Certificate Signing Request]].
===CSS===
Cross-site scripting. Generally, however, this is abbreviated to XSS in order to avoid confusion with cascading style sheets.

See also: [[#Cross-site scripting|Cross-site scripting]].
===CTR mode===
See also: [[#Counter mode|Counter mode]].
===CWC mode===
See also: [[#Carter-Wegmen Counter (data encryption mode)|Carter Wegmen + Counter mode]].

==D==
===DACL===
Discretionary Access Control List. In a Windows ACL, a list that determines access rights to an object.

See also: [[#Access Control List|Access Control List]].

===Davies-Meyer===
An algorithm for turning a block cipher into a cryptographic one-way hash function.
===Default deny===
A paradigm for access control and input validation where an action must explicitly be allowed. The idea behind this paradigm is that one should limit the possibilities for unexpected behavior by being strict, instead of lenient, with rules.
===Defense-in-depth===
A principle for building systems stating that multiple defensive mechanisms at different layers of a system are usually more secure than a single layer of defense. For example, when performing input validation, one might validate user data as it comes in and then also validate it before each use — just in case something was not caught, or the underlying components are linked against a different front end, etc.
===DEK===
Data encrypting key.
===Delta CRLs===
A variation of Certificate Revocation Lists that allows for incremental updating, as an effort to avoid frequently re-downloading a large amount of unchanged data.

See also: [[#Certificate Revocation List|Certificate Revocation List]].
===Denial of service attack===
Any attack that affects the availability of a service. Reliability bugs that cause a service to crash or go into some sort of vegetative state are usually potential denial-of-service problems.
===DES===
The Data Encryption Standard. An encryption algorithm standardized by the US Government. The key length is too short, so this algorithm should be considered insecure. The effective key strength is 56 bits; the actual key size is 64 bits — 8 bits are wasted. However, there are variations such as Triple DES and DESX that increase security while also increasing the key size.

See also: [[#Advanced Encryption Standard|Advanced Encryption Standard]], [[#Triple DES|Triple DES]].
===DESX===
An extended version of DES that increases the resistance to brute-force attack in a highly efficient way by increasing the key length. The extra key material is mixed into the encryption process, using XORs. This technique does not improve resistance to differential attacks, but such attacks are still generally considered unfeasible against DES.

See also: [[#DES|DES]].
===Dictionary attack===
An attack against a cryptographic system, using precomputating values to build a dictionary. For example, in a password system, one might keep a dictionary mapping ciphertext pairs in plaintext form to keys for a single plaintext that frequently occurs. A large enough key space can render this attack useless. In a password system, there are similar dictionary attacks, which are somewhat alleviated by salt. The end result is that the attacker — once he knows the salt — can do a “Crack”-style dictionary attack. Crack-style attacks can be avoided to some degree by making the password verifier computationally expensive to compute. Or select strong random passwords, or do not use a password-based system.
===Differential cryptanalysis===
A type of cryptographic attack where an attacker who can select related inputs learns information about the key from comparing the outputs. Modern ciphers of merit are designed in such a way as to thwart such attacks. Also note that such attacks generally require enough chosen plaintexts as to be considered unfeasible, even when there is a cipher that theoretically falls prey to such a problem.
===Diffie-Hellman key exchange===
A method for exchanging a secret key over an untrusted medium in such a way as to preserve the secrecy of the key. The two parties both contribute random data that factors into the final shared secret. The fundamental problem with this method is authenticating the party with whom you exchanged keys. The simple Diffie-Hellman protocol does not do that. One must also use some public-key authentication system such as DSA.

See also: [[#DSA|DSA]], [[#Station-to-station protocol|Station-to-station protocol]].
===Digest size===
The output size for a hash function.
===Digital signature===
Data that proves that a document (or other piece of data) was not modified since being processed by a particular entity. Generally, what this really means is that — if someone ‘signs’ a piece of data — anyone who has the right public key can demonstrated which private key was used to sign the data.
===Digital Signature Algorithm===
See also: [[#DSA|DSA]].
===Distinguished Encoding Rules===
A set of rules used that describes how to encode ASN.1 data objects unambiguously.

See also: [[#ASN.1|ASN.1]].

===Distinguished Name===
In an X.509 certificate, a field that uniquely specifies the user or group to which the certificate is bound. Usually, the Distinguished Name will contain a user’s name or User ID, an organizational name, and a country designation. For a server certificate, it will often contain the DNS name of the machine.
===DN===
See also: [[#Distinguished Name|Distinguished Name]].
===DoS===
Denial of Service.

See also: [[#Denial of service attack|Denial of service attack]].
===DSA===
The Digital Signature Algorithm, a public key algorithm dedicated to digital signatures which was standardized by NIST. It is based on the same mathematical principles as Diffie-Hellman.
==E==
===Eavesdropping attack===
Any attack on a data connection where one simply records or views data instead of tampering with the connection.
===ECB Mode===
See also: [[#Electronic Code Book mode|Electronic Code Book mode]].
===ECC===
See also: [[#Eliptic Curve Cryptography|Eliptic Curve Cryptography]].
===EGD===
See also: [[#Entropy Gathering Daemon|Entropy Gathering Daemon]].
===Electronic Code Book mode===
An encryption mode for block ciphers that is more or less a direct use of the underlying block cipher. The only difference is that a message is padded out to a multiple of the block length. This mode should not be used under any circumstances.
===Eliptic Curve Cryptography===
A type of public key cryptography that — due to smaller key sizes — tends to be more efficient that standard cryptography. The basic algorithms are essentially the same, except that the operations are performed over different mathematical groups (called eliptic curves).
===EME-OAEP padding===
A padding scheme for public key cryptography that uses a “random” value generated, using a cryptographic hash function in order to prevent particular types of attacks against RSA.

See also: [[#PKCS #1|PKCS #1 padding]].
===Encrypt-then-authenticate===
When using a cipher to encrypt and a MAC to provide message integrity, this paradigm specifies that one encrypts the plaintext, then MACs the ciphertext. This paradigm has theoretically appealing properties and is recommended to use in practice.

See also: [[#Authenticate-and-encrypt|Authenticate-and-encrypt]], [[#Authenticate-then-encrypt|Authenticate-then-encrypt]].
===Endianess===
The byte ordering scheme that a machine uses (usually either little endian or big endian).

See also:[[#Big endian|Big endian]], [[#Little endian|Little endian]].
===Entropy===
Refers to the inherent unknowability of data to external observers. If a bit is just as likely to be a 1 as a 0 and a user does not know which it is, then the bit contains one bit of entropy.
===Entropy Gathering Daemon===
A substitute for /dev/random; a tool used for entropy harvesting.
===Entropy harvester===
A piece of software responsible for gathering entropy from a machine and distilling it into small pieces of high entropy data. Often an entropy harvester will produce a seed for a cryptographic pseudo-random number generator.

See also: [[#Entropy|Entropy]], [[#Pseudo-random number generator|Pseudo-random number generator]].
===Ephemeral keying===
Using one-time public key pairs for session key exchange in order to prevent recovering previous session keys if a private key is compromised. Long-term public key pairs are still used to establish identity.
===Euclidian algorithm===
An algorithm that computes the greatest common divisor of any two numbers.
===Extended Euclidian algorithm===
An algorithm used to compute the inverse of a number modulo “some other number.”
==F==
===Fingerprint===
The output of a cryptographic hash function.

See also: [[#Message digest|Message digest]].
===FIPS===
Federal Information Processing Standard; a set of standards from NIST.
===FIPS-140===
A standard authored by the U.S. National Institute of Standards and Technology, that details general security requirements for cryptographic software deployed in a government systems (primarily cryptographic providers).

See also: [[#NIST|NIST]], [[#FIPS|FIPS]].
===Format string attack===
The C standard library uses specifiers to format output. If an attacker can control the input to such a format string, he can often write to arbitrary memory locations.
===Forward secrecy===
Ensuring that the compromise of a secret does not divulge information that could lead to data protected prior to the compromise. In many systems with forward secrecy, it is only provided on a per-session basis, meaning that a key compromise will not affect previous sessions, but would allow an attacker to decrypt previous messages sent as a part of the current session.

See also: [[#Perfect forward secrecy|Perfect forward secrecy]].
==G==
==H==
===Hash function===
A function that maps a string of arbitrary length to a fixed size value in a deterministic manner. Such a function may or may not have cryptographic applications.

See also: [[#Cryptographic hash function|Cryptographic hash function]], [[#Universal hash function|Universal hash function]], [[#One-way hash function|One-way hash function]].
===Hash function (cryptographic)===
See also: [[#Cryptographic hash function|Cryptographic hash function]].
===Hash function (one-way)===
See also: [[#One-way hash function|One-way hash function]].
===Hash function (universal)===
See also: [[#Universal hash function|Universal hash function]].
===Hash output===
See also: [[#Hash value|Hash value]].
===Hash value===
The output of a hash function.

See also: [[#Fingerprint|Fingerprint]], [[#Message digest|Message digest]].
===hash127===
A fast universal hash function from Dan Bernstein.
===HMAC===
A well-known algorithm for converting a cryptographic one-way hash function into a message authentication code.
===Honey Pot===
A strategy of setting up resources which an attacker believes are real but are infact designed specifically to catch the attacker.

==I==
===IDEA===
A block cipher with 128-bit keys and 64-bit blocks popularly used with PGP. It is currently protected by patents.
===Identity establishment===
Authentication.
===IEEE P1363===
An IEEE standard for eliptic curve cryptography. Implementing the standard requires licensing patents from Certicom.
===Indirect CRLs===
A CRL issued by a third party, that can contain certificates from multiple CA’s.

See also: [[#Certificate|Certificate]], [[#Certificate Revocation List|Certificate Revocation List]], [[#Certification Authority|Certification Authority]].
===Initialization vector===
A value used to initialize a cryptographic algorithm. Often, the implication is that the value must be random.

See also: [[#Nonce|Nonce]], [[#Salt|Salt]].
===Input validation===
The act of determining that data input to a program is sound.
===Integer overflow===
When an integer value is too big to be held by its associated data type, the results can often be disastrous. This is often a problem when converting unsigned numbers to signed values.
===Integrity checking===
The act of checking whether a message has been modified either maliciously or by accident. Cryptographically strong message integrity algorithms should always be used when integrity is important.
===Interleaved encryption===
Processing the encryption of a message as multiple messages, generally treating every nth block as part of a single message.
===ISO/IEC 17799===
Provides best practice recommendations on information security management for use by those who are responsible for initiating, implementing or maintaining information security management systems.
===IV===
See also: [[#Initialization vector|Initialization vector]].

==J==
===Jail===
A restricted execution environment meant to compartmentalize a process, so that — even if it has security problems — it cannot hurt resources which it would not normally have access to use. On FreeBSD, a system call similar to chroot that provides compartmentalization. Unlike chroot, it can also restrict network resources in addition to file system resources.

See also: [[#chroot|chroot]].

==K==
===Kerberos===
An authentication protocol that relies solely on symmetric cryptography, as opposed to public key cryptography. It still relies on a trusted third party (an authentication server). While Kerberos is often looked upon as a way to avoid problems with Public Key Infrastructure, it can be difficult to scale Kerberos beyond medium-sized organizations.

See also: [[#Public Key Infrastructure|Public Key Infrastructure]], [[#Trusted third party|Trusted third party]].
===Key agreement===
The process of two parties agreeing on a shared secret, where both parties contribute material to the key.
===Key establishment===
The process of agreeing on a shared secret, where both parties contribute material to the key.
===Key exchange===
The process of two parties agreeing on a shared secret, usually implying that both parties contribute to the key.
===Key management===
Mechanisms and process for secure creation, storage, and handling of key material.
===Key schedule===
In a block cipher, keys used for individual “rounds” of encryption, derived from the base key in a cipher-dependent manner.
===Key transport===
When one party picks a session key and communicates it to a second party.
===Keystream Output===
from a stream cipher.

See also: [[#Pseudo-random number generator|Pseudo-random number generator]], [[#Stream cipher|Stream cipher]].
==L==
===LDAP===
Lightweight Directory Access Protocol. A directory protocol commonly used for storing and distributing CRLs.
===Length extension attack===
A class of attack on message authentication codes, where a tag can be forged without the key by extending a pre-existing message in a particular way. CBC-MAC in its simplest form has this problem, but variants protect against it (particularly OMAC).

See also: [[#Message Authentication Code|Message Authentication Code]], [[#OMAC|OMAC]].
===LFSR===
See also: [[#Linear Feedback Shift Register|Linear Feedback Shift Register]].

===Linear cryptanalysis===
A type of cryptanalytic attack where linear approximations of behavior are used. Modern ciphers of merit are designed in such a way as to thwart such attacks. Also note that such attacks generally require enough chosen plaintexts as to be considered unfeasible — even when there is a cipher that theoretically falls prey to such a problem (such as DES).
===Linear Feedback Shift Register===
A non-cryptographic class of pseudo-random number generators, where output is determined by shifting out "output" bits and shifting in "input" bits, where the input bits are a function of the internal state of the register, perhaps combined with new entropy. LFSRs are based on polynomial math, and are not secure in and of themselves; however, they can be put to good use as a component in more secure cryptosystems.
===Little endian===
Refers to machines representing words of data least significant byte first, such as the Intel x86.

See also: [[#Big endian|Big endian]].
==M==
===MAC===
See also: [[#Message Authentication Code|Message Authentication Code]].

===Man-in-the- middle attack===
An eavesdropping attack where a client’s communication with a server is proxied by an attacker. Generally, the implication is that the client performs a cryptographic key exchange with an entity and fails to authenticate that entity, thus allowing an attacker to look like a valid server.
===Matyas-Meyer-Oseas===
A construction for turning a block cipher into a cryptographic one-way hash function.
===MCF===
The Modular Crypt Format, a de-facto data format standard for storing password hashes commonly used on UNIX boxes as a replacement for the traditional UNIX crypt() format.
===MD-strengthening===
Merkel-Damgard strengthening, a general method for turning a collision- resistant compression function into a collision-resistant hash function by adding padding and an encoded length to the end of the input message. The key point behind MD-strengthening is that no possible input to the underlying hash function can be the tail end of a different input.
===MD2===
A cryptographic hash function optimized for 16-bit platforms. It has poor performance characteristics on other platforms and has a weak internal structure.
===MD4===
A cryptographic hash function that is known to be broken and should not be used under any circumstances.
===MD5===
A popular and fast cryptographic hash function that outputs 128-bit message digests. Its internal structure is known to be weak and should be avoided if at all possible.
===MD5-MCF===
A way of using MD5 to store password authentication information, using the modular crypt format.

See also: [[#MCF|MCF]], [[#MD5|MD5]].
===MDC2===
A construction for turning a block cipher into a cryptographic hash function, where the output length is twice the block size of the cipher.
===Meet-in-the- middle attack===
A theoretical attack against encrypting a message twice using a single block cipher and two different keys. For example, double encryption with DES theoretically is no more secure than DES, which is why Triple DES became popular (it gives twice the effective key strength).
===Message Authentication Code===
A function that takes a message and a secret key (and possibly a nonce) and produces an output that cannot, in practice, be forged without possessing the secret key.
===Message digest===
The output of a hash function.
===Message integrity===
A message has integrity if it maintains the value it is supposed to maintain, as opposed to being modified on accident or as part of an attack.
===Methodology===
A mature set of processes applied to various stages of an applications' lifecycle to help reduce the likelihood of security vulnerabilities presence or exploitation.
===Metrics===
A metric is a standard unit of measure, such as meter or mile for length, or gram or ton for weight, or more generally, part of a system of parameters, or systems of measurement, or a set of ways of quantitatively and periodically measuring, assessing, controlling or selecting a person, process, event, or institution, along with the procedures to carry out measurements and the procedures for the interpretation of the assessment in the light of previous or comparable assessments.
===Miller-Rabin===
A primality test that is efficient because it is probabilistic, meaning that there is some chance it reports a composite (non-prime) number as a prime. There is a trade-off between efficiency and probability, but one can gain extremely high assurance without making unreasonable sacrifices in efficiency.
===Model===
A model is a pattern, plan, representation (especially in miniature), or description designed to show the main object or workings of an object, system, or concept.
===Modulus===
In the context of public key cryptography, a value by which all other values are reduced. That is, if a number is bigger than the modulus, the value of the number is considered to be the same as if the number were the remainder after dividing the number by the modulus.
==N==
===Near-collision resistance===
Given a plaintext value and the corresponding hash value, it should be computationally unfeasible to find a second plaintext value that gives the same hash value.
===NIST===
The National Institute of Standards and Technology is a division of the U.S. Department of Commerce. NIST issues standards and guidelines, with the hope that they will be adopted by the computing community.
===Non-repudiation===
The capability of establishing that a message was signed by a particular entity. That is, a message is said to be non-repudiatable when a user sends it, and one can prove that the user sent it. In practice, cryptography can demonstrate that only particular key material was used to produce a message. There are always legal defenses such as stolen credentials or duress.
===Nonce===
A value used with a cryptographic algorithm that must be unique in order to maintain the security of the system. Generally, the uniqueness requirement holds only for a single key — meaning that a {key, nonce} pair should never be reused.

See also: [[#Initialization vector|Initialization vector]], [[#Salt|Salt]].

==O==
===OCB mode===
See also: [[#Offset Code Book mode|Offset Code Book mode]].
===OCSP===
See also: Online Certificate Status Protocol.
===OCSP responder===
The server side software that answers OCSP requests.

See also: [[#Online Certificate Status Protocol|Online Certificate Status Protocol]].
===OFB mode===
See also: [[#Output Feedback mode|Output Feedback mode]].
===Offset Code Book mode===
A patented encryption mode for block ciphers that provides both secrecy and message integrity and is capable of doing so at high speeds.
===OMAC===
One-key CBC-MAC. A secure, efficient way for turning a block cipher into a message authentication code. It is an improvement of the CBC-MAC, which is not secure in the arbitrary case. Other CBC-MAC variants use multiple keys in order to fix the problem with CBC-MAC. OMAC uses a single key and still has appealing provable security properties.
===One-time pad===
A particular cryptographic system that is provably secure in some sense, but highly impractical, because it requires a bit of entropy for every bit of message.
===One-time password===
A password that is only valid once. Generally, such passwords are derived from some master secret — which is shared by an entity and an authentication server — and are calculated via a challenge-response protocol.
===One-way hash function===
A hash function, where it is computationally unfeasible to determine anything about the input from the output.
===Online Certificate Status Protocol===
A protocol for determining whether a digital certificate is valid in real time without using CRLs. This protocol (usually abbreviated OCSP) is specified in RFC 2560.
===Output Feedback mode===
A block cipher mode that turns a block cipher into a stream cipher. The mode works by continually encrypting the previous block of keystream. The first block of keystream is generated by encrypting an initialization vector.
==P==
===Padding===
Data added to a message that is not part of the message. For example, some block cipher modes require messages to be padded to a length that is evenly divisible by the block length of the cipher — i.e., the number of bytes that the cipher processes at once.
===PAM===
Pluggable Authentication Modules is a technology for abstracting out authentication at the host level. It is similar to SASL, but is a bit higher up in the network stack and tends to be a much easier technology to use, particularly for system administrators, who can configure authentication policies quite easily using PAM.

See also: [[#SASL|SASL]].
===Partial collision resistance===
When it is unfeasible to find two arbitrary inputs to a hash function that produce similar outputs — i.e., outputs that differ in only a few bits.
===Passive attack===
See also: [[#Eavesdropping attack|Eavesdropping attack]].

===Passphrase===
A synonym for “password,” meant to encourage people to use longer (it is hoped, more secure) values.
===Password===
A value that is used for authentication.
===PBKDF2===
Password-Based Key Derivation Function #2. An algorithm defined in PKCS #5 for deriving a random value from a password.
===PEM encoding===
A simple encoding scheme for cryptographic objects that outputs printable values (by Base 64 encoding a DER-encoded representation of the cryptographic object). The scheme was first introduced in Privacy Enhanced Mail, a defunct way of providing E-mail security.
===Perfect forward secrecy===
Ensuring that the compromise of a secret does not divulge information that could lead to the recovery of data protected prior to the compromise.

See also: [[#Forward secrecy|Forward secrecy]].
===PKCS #1===
Public Key Cryptography Standard #1. A standard from RSA Labs specifying how to use the RSA algorithm for encrypting and signing data.
===PKCS #1===
padding This form of padding can encrypt messages up to 11 bytes smaller than the modulus size in bytes. You should not use this method for any purpose other than encrypting session keys or hash values.
===PKCS #10===
Describes a standard syntax for certification requests.
===PKCS #11===
Specifies a programming interface called Cryptoki for portable cryptographic devices of all kinds.
===PKCS #3===
Public Key Cryptography Standard #3. A standard from RSA Labs specifying how to implement the Diffie-Hellman key exchange protocol.
===PKCS #5===
Public Key Cryptography Standard #5. A standard from RSA Labs specifying how to derive cryptographic keys from a password.
===PKCS #7===
Public Key Cryptography Standard #7. A standard from RSA Labs specifying a generic syntax for data that may be encrypted or signed.
===PKI===
See also: [[#Public Key Infrastructure|Public Key Infrastructure]].
===Plaintext===
An unencrypted message.

See also: [[#Ciphertext|Ciphertext]].
===PMAC===
The MAC portion of the OCB block cipher mode. It is a patented way of turning a block cipher into a secure, parallelizable MAC.
===Precomputation attack===
Any attack that involves precomputing significant amounts of data in advance of opportunities to launch an attack. A dictionary attack is a common precomputation attack.
===Predictive modelling===
Predictive modelling is the process by which a model is created or chosen to try to best predict the probability of an outcome. In many cases the model is chosen on the basis of detection theory to try to guess the probability of a signal given a set amount of input data, for example given an email determining how likely that it is spam.
===Private key===
In a public key cryptosystem, key material that is bound tightly to an individual entity that must remain secret in order for there to be secure communication.
===Privilege separation===
A technique for trying to minimize the impact that a programming flaw can have, where operations requiring privilege are separated out into a small, independent component (hopefully audited with care). Generally, the component is implemented as an independent process, and it spawns off a non-privileged process to do most of the real work. The two processes keep open a communication link, speaking a simple protocol.
===PRNG===
See also: [[#Pseudo-random number generator|Pseudo-random number generator]].
===Pseudo-random number generator===
An algorithm that takes data and stretches it into a series of random-looking outputs. Cryptographic pseudo-random number generators may be secure if the initial data contains enough entropy. Many popular pseudo-random number generators are not secure.

See also: [[#Stream cipher|Stream cipher]].

===Public key===
In a public key cryptosystem, the key material that can be published publicly without compromising the security of the system. Generally, this material must be published; its authenticity must be determined definitively.
===Public Key Infrastructure===
A system that provides a means for establishing trust as to what identity is associated with a public key. Some sort of Public Key Infrastructure (PKI) is necessary to give reasonable assurance that one is communicating securely with the proper party, even if that infrastructure is ad hoc”
==Q==
==R==
===RA===
See also: [[#Registration Authority|Registration Authority]].
===Race condition===
A class of error in environments that are multi-threaded or otherwise multi- tasking, where an operation is falsely assumed to be atomic. That is, if two operations overlap instead of being done sequentially, there is some risk of the resulting computation not being correct. There are many cases where such a condition can be security critical.

See also: [[#TOCTOU problem|TOCTOU problem]].
===Randomness===
A measure of how unguessable data is.

See also: [[#Entropy|Entropy]].
===RC2===
A block cipher with variable key sizes and 64-bit blocks.
===RC4===
A widely used stream cipher that is relatively fast but with some significant problems. One practical problem is that it has a weak key setup algorithm, though this problem can be mitigated with care. Another more theoretical problem is that RC4’s output is easy to distinguish from a truly random stream of numbers. This problem indicates that RC4 is probably not a good long-term choice for data security.
===RC5===
A block cipher that has several tunable parameters.
===Registration Authority===
An organization that is responsible for validating the identity of entities trying to obtain credentials in a Public Key Infrastructure.

See also: [[#Certification Authority|Certification Authority]], [[#Public Key Infrastructure|Public Key Infrastructure]].
===Rekeying===
Changing a key in a cryptographic system.
===Related key attack===
A class of cryptographic attack where one takes advantage of known relationships between keys to expose information about the keys or the messages those keys are protecting.
===Revocation===
In the context of Public Key Infrastructure, the act of voiding a digital certificate.

See also: [[#Public Key Infrastructure|Public Key Infrastructure]], [[#X.509 certificate|X.509 certificate]].
===RIPEMD-160===
A cryptographic hash function that is well regarded. It has a 160-bit output, and is a bit slower than SHA1.
===RMAC===
A construction for making a Message Authentication Code out of a block cipher. It is not generally secure in the way that OMAC is, and is generally considered not worth using due to the existence of better alternatives.

See also: [[#OMAC|OMAC]].
===Rollback attack===
An attack where one forces communicating parties to agree on an insecure protocol version.
===Root certificate===
A certificate that is intrinsically trusted by entities in a Public Key Infrastructure — generally should be transported over a secure medium. Root certificates belong to a Certification Authority and are used to sign other certificates that are deemed to be valid. When a system tries to establish the validity of a certificate, one of the first things that should happen is that it should look for a chain of trust to a known, trusted root certificate. That is, if the certificate to be validated is not signed by a root, one checks the certificate(s) used to sign it to determine if those were signed by a root cert. Lather, rinse, repeat.

See also: [[#Public Key Infrastructure|Public Key Infrastructure]].
===Round===
In a block cipher, a group of operations applied as a unit that has an inverse that undoes the operation. Most block ciphers define a round operation and then apply that round operation numerous times — though often applying a different key for each round, where the round key is somehow derived from the base key.
===RSA===
A popular public key algorithm for encryption and digital signatures invented by Ron Rivest, Adi Shamir and Leonard Adleman. It is believed that, if factoring large numbers is computationally unfeasible, then RSA can be used securely in practice.
===RSASSA-PSS===
A padding standard defined in PKCS #1, used for padding data prior to RSA signing operations.
==S==
===S/Key===
A popular one-time password system.

See also: [[#One-time password|One-time password]].
===S/MIME===
A protocol for secure electronic mail standardized by the IETF. It relies on standard X.509-based Public Key Infrastructure.
===SACL===
System Access Control List. In Windows, the part of an ACL that determines audit logging policy.

See also: [[#Access Control List|Access Control List]], [[#DACL|DACL]].
===Salt===
Data that can be public but is used to prevent against precomputation attacks.

See also: [[#Initialization vector|Initialization vector]], [[#Nonce|Nonce]].
===SASL===
The Simple Authentication and Security Layer, which is a method for adding authentication services to network protocols somewhat generically. It is also capable of providing key exchange in many circumstances.
===Secret key===
See also: [[#Symmetric key|Symmetric key]].
===Secure Socket Layer===
A popular protocol for establishing secure channels over a reliable transport, utilizing a standard X.509 Public Key Infrastructure for authenticating machines. This protocol has evolved into the TLS protocol, but the term SSL is often used to generically refer to both.

See also: [[#Transport Layer Security|Transport Layer Security]].
===Seed===
A value used to initialize a pseudo-random number generator.

See also: [[#Entropy|Entropy]], [[#Initialization vector|Initialization vector]], [[#Pseudo-random number generator|Pseudo-random number generator]].

===Self-signed certificate===
A certificate signed by the private key associated with that certificate. In an X.509 Public Key Infrastructure, all certificates need to be signed. Since root certificates have no third-party signature to establish their authenticity, they are used to sign themselves. In such a case, trust in the certificate must be established by some other means.
===Serpent===
A modern block cipher with 128-bit blocks and variable-sized keys. A finalist in the AES competition, Serpent has a higher security margin by design than other candidates, and is a bit slower on typical 32-bit hardware as a result.

See also: [[#AES|AES]].
===Session key===
A randomly generated key used to secure a single connection and then discarded.
===SHA-256===
A cryptographic hash function from NIST with 256-bit message digests.
===SHA-384===
SHA-512 with a truncated digest (as specified by NIST).
===SHA-512===
A cryptographic hash function from NIST with 512-bit message digests.
===SHA1===
A fairly fast, well regarded hash function with 160-bit digests that has been standardized by the National Institute of Standards and Technology (NIST).
===Shared secret===
A value shared by parties that may wish to communicate, where the secrecy of that value is an important component of secure communications. Typically, a shared secret is either an encryption key, a MAC key, or some value used to derive such keys.
===Shatter attack===
A class of attack on the Windows event system. The Windows messaging system is fundamentally fragile from a security perspective because it allows for arbitrary processes to insert control events into the message queue without sufficient mechanisms for authentication. Sometimes messages can be used to trick other applications to execute malicious code.
===Single sign-on===
Single sign-on allows you to access all computing resources that you should be able to reach by using a single set of authentication credentials that are presented a single time per login session. Single sign-on is a notion for improved usability of security systems that can often increase the security exposure of a system significantly.
===Snooping attacks===
Attacks where data is read off a network while in transit without modifying or destroying the data.
===SNOW===
A very fast stream cipher that is patent-free and seems to have a very high security margin.
===SQL Injection===
[[SQL injection]] is a security vulnerability that occurs in the persistence/database layer of a web application. This vulnerability is derived from the incorrect escaping of variables embedded in SQL statements. It is in fact an instance of a more general class of vulnerabilities based on poor input validation and bad design that can occur whenever one programming or scripting language is embedded inside another.

===SSL===
See also: [[#Secure Socket Layer|Secure Socket Layer]].
===Stack smashing===
Overwriting a return address on the program execution stack by exploiting a buffer overflow. Generally, the implication is that the return address gets replaced with a pointer to malicious code.

See also: [[#Buffer overflow|Buffer overflow]].
===Station-to-station protocol===
A simple variant of the Diffie-Hellman key exchange protocol that provides key agreement and authenticates each party to the other. This is done by adding digital signatures (which must be done carefully).

See also: [[#Diffie-Hellman key exchange|Diffie-Hellman key exchange]].
===Stream cipher===
A pseudo-random number generator that is believed to be cryptographically strong and always produces the same stream of output given the same initial seed (i.e., key). Encrypting with a stream cipher consists of combining the plaintext with the keystream, usually via XOR.

See also: [[#Pseudo-random number generator|Pseudo-random number generator]].
===Strong collision resistance===
Strong collision resistance is a property that a hash function may have (and a good cryptographic hash function will have), characterized by it being computationally unfeasible to find two arbitrary inputs that yield the same output.

See also: [[#Hash function|Hash function]], [[#Weak collision resistance|Weak collision resistance]].
===Surreptitious forwarding===
An attack on some public key cryptosystems where a malicious user decrypts a digitally signed message and then encrypts the message using someone else’s public key: giving the end receiver the impression that the message was originally destined for them.
===Symmetric cryptography===
Cryptography that makes use of shared secrets as opposed to public keys.
===Symmetric key===
See also: [[#Shared secret|Shared secret]].
==T==
===Tag===
The result of applying a keyed message authentication code to a message.

See also: [[#Message Authentication Code|Message Authentication Code]].
===Tamper-proofing===
See also: [[#Anti-tampering|Anti-tampering]].
===Threat model===
A representation of the system threats that are expected to be reasonable. This includes denoting what kind of resources an attacker is expected to have, in addition to what kinds of things the attacker may be willing to try to do. Sometimes called an architectural security assessment.
===Time of check, time of use problem===
See also: [[#TOCTOU problem|TOCTOU problem]].
===TLS===
See also: [[#Transport Layer Security|Transport Layer Security]].
===TMAC===
A two-keyed variant of the CBC-MAC that overcomes the fundamental limitation of that MAC.

See also: [[#Message Authentication Code|Message Authentication Code]], [[#CBC-MAC|CBC-MAC]], [[#OMAC|OMAC]].
===TOCTOU problem===
Time-of-check, time-of-use race condition. A type of race condition between multiple processes on a file system. Generally what happens is that a single program checks some sort of property on a file, and then in subsequent instructions tries to use the resource if the check succeeded. The problem is that — even if the use comes immediately after the check — there is often some significant chance that a second process can invalidate the check in a malicious way. For example, a privileged program might check write privileges on a valid file, and the attacker can then replace that file with a symbolic link to the system password file.

See also: [[#Race condition|Race condition]].
===Transport Layer Security===
The successor to SSL, a protocol for establishing secure channels over a reliable transport, using a standard X.509 Public Key Infrastructure for authenticating machines. The protocol is standardized by the IETF.

See also: [[#Secure Socket Layer|Secure Socket Layer]].
===Triple DES===
A variant of the original Data Encryption Standard that doubles the effective security. Often abbreviated to 3DES. The security level of 3DES is still considered to be very high, but there are faster block ciphers that provide comparable levels of security — such as AES.
===Trojan===
See also: [[#Backdoor|Backdoor]].
===Trojan Horse===
See also: [[#Backdoor|Backdoor]].
===Trusted third party===
An entity in a system to whom entities must extend some implicit trust. For example, in a typical Public Key Infrastructure, the Certification Authority constitutes a trusted third party.
===Twofish===
A modern block cipher with 128-bit blocks and variable-sized keys. A finalist in the AES competition; it is an evolution of the Blowfish cipher.

See also: [[#AES|AES]], [[#Blowfish|Blowfish]].
==U==
===UMAC===
A secure MAC based on a set of universal hash functions that is extremely fast in software but so complex that there has never been a validated implementation.

See also: [[#Universal hash function|Universal hash function]].
===Universal hash function===
A keyed hash function that has ideal hash properties. In practice, the only practical functions of this nature are really "almost universal" hash functions, meaning they come very close to being ideal. Universal and near-universal hash functions are not cryptographically secure when used naively for message authentication but can be adapted to be secure for this purpose easily.

See also: [[#Cryptographic hash function|Cryptographic hash function]], [[#Hash function|Hash function]], [[#One-way hash function|One-way hash function]].

==V==
===Validation===
The act of determining that data is sound. In security, generally used in the context of validating input.
==W==
===Weak collision resistance===
A property that a hash function may have (and a good cryptographic hash function will have), characterized by it being unfeasible to find a second input that produces the same output as a known input.

See also: [[#Hash function|Hash function]], [[#Strong collision resistance|Strong collision resistance]].
===Whitelist===
When performing input validation, the set of items that, if matched, results in the input being accepted as valid. If there is no match to the whitelist, then the input is considered invalid. That is, a whitelist uses a "default deny" policy.

See also: [[#Blacklist|Blacklist]], [[#Default deny|Default deny]].

===Window of vulnerability===
The period of time in which a vulnerability can possibly be exploited.

===[[What are web applications?]]===

==X==
===X.509 certificate===
A digital certificate that complies with the X.509 standard (produced by ANSI).
===XCBC-MAC===
A three-key variant of the CBC-MAC that overcomes the fundamental limitation of that MAC.

See also: [[#Message Authentication Code|Message Authentication Code]], [[#CBC-MAC|CBC-MAC]], [[#OMAC|OMAC]].

===XSS===
See also: [[#Cross-site scripting|Cross-site scripting]].
==Y==
==Z==

{{compactTOC}}

[[Category:Glossary]]

Glossary

2012-11-16T08:41:23Z

Micheal w s mcnamee: /* XMACC */

{{compactTOC}}

{{SecureSoftware}}

==0–9==
===3DES===
See also: [[#Triple DES|Triple DES]]
==A==
===Access Control List===
A list of credentials attached to a resource indicating whether or not the credentials have access to the resource.
===ACL===
Access Control List
===Active attack===
Any network-based attack other than simple eavesdropping — i.e., a passive attack).
===Advanced Encryption Standard===
A fast general-purpose block cipher standardized by NIST (the National Institute of Standards and Technology). The AES selection process was a multi-year competition, where Rijndael was the winning cipher.
===AES===
See also: [[#Advanced Encryption Standard|Advanced Encryption Standard]]
===Anti-debugger===
Referring to technology that detects or thwarts the use of a debugger on a piece of software.
===Anti-tampering===
Referring to technology that attempts to thwart the reverse engineering and patching of a piece of software in binary format.
===Architectural security assessment===
See also: [[#Threat model|Threat Model]]

===ASN.1===
Abstract Syntax Notation is a language for representing data objects. It is popular to use this in specifying cryptographic protocols, usually using DER (Distinguished Encoding Rules), which allows the data layout to be unambiguously specified.

See also: [[#Distinguished Encoding Rules|Distinguished Encoding Rules]].
===Asymmetric cryptography===
Cryptography involving public keys, as opposed to cryptography making use of shared secrets.

See also: [[#Symmetric cryptography|Symmetric cryptography]].
===Audit===
In the context of security, a review of a system in order to validate the security of the system. Generally, this either refers to code auditing or reviewing audit logs.

See also: [[#Audit log|Audit log]], [[#Code auditing|Code auditing]].
===Audit log===
Records that are kept for the purpose of later verifying that the security properties of a system have remained intact.
===Authenticate-and-encrypt===
When using a cipher to encrypt and a MAC to provide message integrity, this paradigm specifies that one authenticates the plaintext and encrypts the plaintext, possibly in parallel. This is not secure in the general case.

See also: [[#Authenticate-then-encrypt|Authenticate-then-encrypt]], [[#Encrypt-then-authenticate|Encrypt-then-authenticate]].

===Authenticate-then-encrypt===
When using a cipher to encrypt and a MAC to provide message integrity, this paradigm specifies that one authenticates the plaintext and then encrypts the plaintext concatenated with the MAC tag. This is not secure in the general case, but usually works well in practice.

See also: [[#Authenticate-and-encrypt|Authenticate-and-encrypt]], [[#Encrypt-then-authenticate|Encrypt-then-authenticate]].
===Authentication===
The process of verifying identity, ownership, and/or authorization.
==B==
===Backdoor===
Malicious code inserted into a program for the purposes of providing the author covert access to machines running the program.
===Base 64===
A method for encoding binary data into printable ASCII strings. Every byte of output maps to six bits of input (minus possible padding bytes).

===Big endian===
Refers to machines representing words most significant byte first. While x86 machines do not use big endian byte ordering (instead using little endian), the PowerPC and SPARC architectures do. This is also network byte order.

See also: [[#Little endian|Little endian]].
===Birthday attack===
Take a function f() that seems to map an input to a random output of some fixed size (a pseudo-random function or PRF). A birthday attack is simply selecting random inputs for f() and checking to see if any previous values gave the same output. Statistically, if the output size is S bits, then one can find a collision in 2S/2 operations, on average.
===Bit-flipping attack===
In a stream cipher, flipping a bit in the ciphertext flips the corresponding bit in the plaintext. If using a message authentication code (MAC), such attacks are not practical.
===Blacklist===
When performing input validation, the set of items that — if matched — result in the input being considered invalid. If no invalid items are found, the result is valid.

See also: [[#Whitelist|Whitelist]].

===Blinding===
A technique used to thwart timing attacks.
===Block cipher===
An encryption algorithm that maps inputs of size n to outputs of size n (n is called the block size). Data that is not a valid block size must somehow be padded (generally by using an encryption mode). The same input always produces the same output.

See also: [[#Stream cipher|Stream cipher]].
===Blowfish===
A block cipher with 64-bit blocks and variable length keys, created by Bruce Schneier. This cipher is infamous for having slow key-setup times.
===Brute-force attack===
An attack on an encryption algorithm where the encryption key for a ciphertext is determined by trying to decrypt with every key until valid plaintext is obtained.
===Buffer overflow===
A buffer overflow is when you can put more data into a memory location than is allocated to hold that data. Languages like C and C++ that do no built-in bounds checking are susceptible to such problems. These problems are often security-critical.
==C==
===CA===
See Certification Authority.
===Canary===
A piece of data, the absence of which indicates a violation of a security policy. Several tools use a canary for preventing certain stack-smashing buffer overflow attacks.

See also: [[#Buffer overflow|Buffer overflow]], [[#Stack smashing|Stack smashing]].
===Capture-replay attacks===
When an attacker can capture data off the wire and replay it later without the bogus data being detected as bogus.
===Carter-Wegmen Counter (data encryption mode)===
A parallelizable and patent-free high-level encryption mode that provides both encryption and built-in message integrity.

===CAST5===
A block cipher with 64-bit blocks and key sizes up to 128 bits. It is patent- free, and generally considered sound, but modern algorithms with larger block sizes are generally preferred (e.g., AES).

See also: [[#AES|AES]].
===CBC Mode===
See also: [[#Cipher-Block Chaining mode|Cipher-Block Chaining mode]].

===CBC-MAC===
A simple construction for turning a block cipher into a message authentication code. It only is secure when all messages MAC’d with a single key are the same size. However, there are several variants that thwart this problem, the most important being OMAC.

See also: [[#OMAC|OMAC]].
===CCM mode===
See also: [[#Counter mode with CBC-MAC (CCM)|Counter mode with CBC-MAC (CCM)]].

===Certificate===
A data object that binds information about a person or some other entity to a public key. The binding is generally done using a digital signature from a trusted third party (a certification authority).
===Certificate Revocation List===
A list published by a certification authority indicating which issued certificates should be considered invalid.
===Certificate Signing Request===
Data about an entity given to a certification authority. The authority will package the data into a certificate and sign the certificate if the data in the signing request is validated.
===Certification Authority===
An entity that manages digital certificates — i.e., issues and revokes. Verisign and InstantSSL are two well known CAs.
===CFB mode===
See also: [[#Cipher Feedback mode|Cipher Feedback mode]].
===Chain responder===
An OCSP responder that relays the results of querying another OCSP responder.

See also: [[#OCSP|OCSP]].

===Choke point===
In computer security, a place in a system where input is routed for the purposes of performing data validation. The implication is that there are few such places in a system and that all data must pass through one or more of the choke points. The idea is that funneling input through a small number of choke points makes it easier to ensure that input is properly validated. One potential concern is that poorly chosen choke points may not have enough information to perform input validation that is as accurate as possible.
===chroot===
A UNIX system call that sets the root directory for a process to any arbitrary directory. The idea is compartmentalization: Even if a process is compromised, it should not be able to see interesting parts of the file system beyond its own little world. There are some instances where chroot "jails" can be circumvented; it can be difficult to build proper operating environments to make chroot work well.
===Cipher-Block Chaining mode===
A block cipher mode that provides secrecy but not message integrity. Messages encrypted with this mode should have random initialization vectors.
===Cipher Feedback mode===
A mode that turns a block cipher into a stream cipher. This mode is safe only when used in particular configurations. Generally, CTR mode and OFB mode are used instead since both have better security bounds.
===Ciphertext===
The result of encrypting a message.

See also: [[#Plaintext|Plaintext]].
===Ciphertext stealing mode===
A block cipher mode of operation that is similar to CBC mode except that the final block is processed in such a way that the output is always the same length as the input. That is, this mode is similar to CBC mode but does not require padding.

See also: [[#Cipher-Block Chaining mode|Cipher-Block Chaining mode]], [[#Padding|Padding]].

===CLASP===
See also: [[#Comprehesive, Lightweight Application Security Process|Comprehesive, Lightweight Application Security Process]]

===Code auditing===
Reviewing computer software for security problems.

See also: [[#Audit|Audit]].
===Code signing===
Signing executable code to establish that it comes from a trustworthy vendor. The signature must be validated using a trusted third party in order to establish identity.
===Compartmentalization===
Separating a system into parts with distinct boundaries, using simple, well- defined interfaces. The basic idea is that of containment — i.e., if one part is compromised, perhaps the extent of the damage can be limited.

See also: [[#Jail|Jail]], [[#Chroot|Chroot]].
===Comprehesive, Lightweight Application Security Process===
An activity-driven, role based set of process components whose core contains formalized best practices for building security into your existing or new-start software development lifecycles in a structured, repeatable, and measurable way.

See also:
* [[:Category:OWASP CLASP Project|OWASP CLASP Project]]

===Context object===
In a cryptographic library, a data object that holds the intermediate state associated with the cryptographic processing of a piece of data. For example, if incrementally hashing a string, a context object stores the internal state of the hash function necessary to process further data.
===Counter mode===
A parallelizable encryption mode that effectively turns a block cipher into a stream cipher. It is a popular component in authenticated encryption schemes due to its optimal security bounds and good performance characteristics.
===Counter mode with CBC-MAC (CCM)===
An encryption mode that provides both message secrecy and integrity. It was the first such mode that was not covered by patent.

===CRAM===
A password-based authentication mechanism using a cryptographic hash function (usually MD5). It does not provide adequate protection against several common threats to password-based authentication systems. HTTP Digest Authentication is a somewhat better alternative; it is replacing CRAM in most places.
===CRC===
Cyclic Redundancy Check. A means of determining whether accidental transmission errors have occurred. Such algorithms are not cryptographically secure because attackers can often forge CRC values or even modify data maliciously in such a way that the CRC value does not change. Instead, one should use a strong, keyed message authentication code such as HMAC or OMAC.

See also: [[#HMAC|HMAC]], [[#Message Authentication Code|Message Authentication Code]], [[#OMAC|OMAC]].
===Critical extensions===
In an X.509 certificate, those extensions that must be recognized by any software processing the certificate. If a piece of software does not recognize an extension marked as critical, the software must regard the certificate as invalid.
===CRL===
See also: [[#Certificate Revocation List|Certificate Revocation List]].

===Cross-site request forgery===
[[CSRF]] is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attackers choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.
===Cross-site scripting===
A class of problems resulting from insufficient input validation where one user can add content to a web site that can be malicious when viewed by other users to the web site. For example, one might post to a message board that accepts arbitrary HTML and include a malicious code item.
===Cryptanalysis===
The science of breaking cryptographic algorithms.
===Cryptographic hash function===
A function that takes an input string of arbitrary length and produces a fixed- size output — where it is unfeasible to find two inputs that map to the same output, and it is unfeasible to learn anything about the input from the output.
===Cryptographic randomness===
Data produced by a cryptographic pseudo-random number generator. The probability of figuring out the internal state of the generator is related to the strength of the underlying cryptography — i.e., assuming the generator is seeded with enough entropy.
===Cryptography===
The science of providing secrecy, integrity, and non-repudiation for data.
===CSR===
See also: [[#Certificate Signing Request|Certificate Signing Request]].
===CSS===
Cross-site scripting. Generally, however, this is abbreviated to XSS in order to avoid confusion with cascading style sheets.

See also: [[#Cross-site scripting|Cross-site scripting]].
===CTR mode===
See also: [[#Counter mode|Counter mode]].
===CWC mode===
See also: [[#Carter-Wegmen Counter (data encryption mode)|Carter Wegmen + Counter mode]].

==D==
===DACL===
Discretionary Access Control List. In a Windows ACL, a list that determines access rights to an object.

See also: [[#Access Control List|Access Control List]].

===Davies-Meyer===
An algorithm for turning a block cipher into a cryptographic one-way hash function.
===Default deny===
A paradigm for access control and input validation where an action must explicitly be allowed. The idea behind this paradigm is that one should limit the possibilities for unexpected behavior by being strict, instead of lenient, with rules.
===Defense-in-depth===
A principle for building systems stating that multiple defensive mechanisms at different layers of a system are usually more secure than a single layer of defense. For example, when performing input validation, one might validate user data as it comes in and then also validate it before each use — just in case something was not caught, or the underlying components are linked against a different front end, etc.
===DEK===
Data encrypting key.
===Delta CRLs===
A variation of Certificate Revocation Lists that allows for incremental updating, as an effort to avoid frequently re-downloading a large amount of unchanged data.

See also: [[#Certificate Revocation List|Certificate Revocation List]].
===Denial of service attack===
Any attack that affects the availability of a service. Reliability bugs that cause a service to crash or go into some sort of vegetative state are usually potential denial-of-service problems.
===DES===
The Data Encryption Standard. An encryption algorithm standardized by the US Government. The key length is too short, so this algorithm should be considered insecure. The effective key strength is 56 bits; the actual key size is 64 bits — 8 bits are wasted. However, there are variations such as Triple DES and DESX that increase security while also increasing the key size.

See also: [[#Advanced Encryption Standard|Advanced Encryption Standard]], [[#Triple DES|Triple DES]].
===DESX===
An extended version of DES that increases the resistance to brute-force attack in a highly efficient way by increasing the key length. The extra key material is mixed into the encryption process, using XORs. This technique does not improve resistance to differential attacks, but such attacks are still generally considered unfeasible against DES.

See also: [[#DES|DES]].
===Dictionary attack===
An attack against a cryptographic system, using precomputating values to build a dictionary. For example, in a password system, one might keep a dictionary mapping ciphertext pairs in plaintext form to keys for a single plaintext that frequently occurs. A large enough key space can render this attack useless. In a password system, there are similar dictionary attacks, which are somewhat alleviated by salt. The end result is that the attacker — once he knows the salt — can do a “Crack”-style dictionary attack. Crack-style attacks can be avoided to some degree by making the password verifier computationally expensive to compute. Or select strong random passwords, or do not use a password-based system.
===Differential cryptanalysis===
A type of cryptographic attack where an attacker who can select related inputs learns information about the key from comparing the outputs. Modern ciphers of merit are designed in such a way as to thwart such attacks. Also note that such attacks generally require enough chosen plaintexts as to be considered unfeasible, even when there is a cipher that theoretically falls prey to such a problem.
===Diffie-Hellman key exchange===
A method for exchanging a secret key over an untrusted medium in such a way as to preserve the secrecy of the key. The two parties both contribute random data that factors into the final shared secret. The fundamental problem with this method is authenticating the party with whom you exchanged keys. The simple Diffie-Hellman protocol does not do that. One must also use some public-key authentication system such as DSA.

See also: [[#DSA|DSA]], [[#Station-to-station protocol|Station-to-station protocol]].
===Digest size===
The output size for a hash function.
===Digital signature===
Data that proves that a document (or other piece of data) was not modified since being processed by a particular entity. Generally, what this really means is that — if someone ‘signs’ a piece of data — anyone who has the right public key can demonstrated which private key was used to sign the data.
===Digital Signature Algorithm===
See also: [[#DSA|DSA]].
===Distinguished Encoding Rules===
A set of rules used that describes how to encode ASN.1 data objects unambiguously.

See also: [[#ASN.1|ASN.1]].

===Distinguished Name===
In an X.509 certificate, a field that uniquely specifies the user or group to which the certificate is bound. Usually, the Distinguished Name will contain a user’s name or User ID, an organizational name, and a country designation. For a server certificate, it will often contain the DNS name of the machine.
===DN===
See also: [[#Distinguished Name|Distinguished Name]].
===DoS===
Denial of Service.

See also: [[#Denial of service attack|Denial of service attack]].
===DSA===
The Digital Signature Algorithm, a public key algorithm dedicated to digital signatures which was standardized by NIST. It is based on the same mathematical principles as Diffie-Hellman.
==E==
===Eavesdropping attack===
Any attack on a data connection where one simply records or views data instead of tampering with the connection.
===ECB Mode===
See also: [[#Electronic Code Book mode|Electronic Code Book mode]].
===ECC===
See also: [[#Eliptic Curve Cryptography|Eliptic Curve Cryptography]].
===EGD===
See also: [[#Entropy Gathering Daemon|Entropy Gathering Daemon]].
===Electronic Code Book mode===
An encryption mode for block ciphers that is more or less a direct use of the underlying block cipher. The only difference is that a message is padded out to a multiple of the block length. This mode should not be used under any circumstances.
===Eliptic Curve Cryptography===
A type of public key cryptography that — due to smaller key sizes — tends to be more efficient that standard cryptography. The basic algorithms are essentially the same, except that the operations are performed over different mathematical groups (called eliptic curves).
===EME-OAEP padding===
A padding scheme for public key cryptography that uses a “random” value generated, using a cryptographic hash function in order to prevent particular types of attacks against RSA.

See also: [[#PKCS #1|PKCS #1 padding]].
===Encrypt-then-authenticate===
When using a cipher to encrypt and a MAC to provide message integrity, this paradigm specifies that one encrypts the plaintext, then MACs the ciphertext. This paradigm has theoretically appealing properties and is recommended to use in practice.

See also: [[#Authenticate-and-encrypt|Authenticate-and-encrypt]], [[#Authenticate-then-encrypt|Authenticate-then-encrypt]].
===Endianess===
The byte ordering scheme that a machine uses (usually either little endian or big endian).

See also:[[#Big endian|Big endian]], [[#Little endian|Little endian]].
===Entropy===
Refers to the inherent unknowability of data to external observers. If a bit is just as likely to be a 1 as a 0 and a user does not know which it is, then the bit contains one bit of entropy.
===Entropy Gathering Daemon===
A substitute for /dev/random; a tool used for entropy harvesting.
===Entropy harvester===
A piece of software responsible for gathering entropy from a machine and distilling it into small pieces of high entropy data. Often an entropy harvester will produce a seed for a cryptographic pseudo-random number generator.

See also: [[#Entropy|Entropy]], [[#Pseudo-random number generator|Pseudo-random number generator]].
===Ephemeral keying===
Using one-time public key pairs for session key exchange in order to prevent recovering previous session keys if a private key is compromised. Long-term public key pairs are still used to establish identity.
===Euclidian algorithm===
An algorithm that computes the greatest common divisor of any two numbers.
===Extended Euclidian algorithm===
An algorithm used to compute the inverse of a number modulo “some other number.”
==F==
===Fingerprint===
The output of a cryptographic hash function.

See also: [[#Message digest|Message digest]].
===FIPS===
Federal Information Processing Standard; a set of standards from NIST.
===FIPS-140===
A standard authored by the U.S. National Institute of Standards and Technology, that details general security requirements for cryptographic software deployed in a government systems (primarily cryptographic providers).

See also: [[#NIST|NIST]], [[#FIPS|FIPS]].
===Format string attack===
The C standard library uses specifiers to format output. If an attacker can control the input to such a format string, he can often write to arbitrary memory locations.
===Forward secrecy===
Ensuring that the compromise of a secret does not divulge information that could lead to data protected prior to the compromise. In many systems with forward secrecy, it is only provided on a per-session basis, meaning that a key compromise will not affect previous sessions, but would allow an attacker to decrypt previous messages sent as a part of the current session.

See also: [[#Perfect forward secrecy|Perfect forward secrecy]].
==G==
==H==
===Hash function===
A function that maps a string of arbitrary length to a fixed size value in a deterministic manner. Such a function may or may not have cryptographic applications.

See also: [[#Cryptographic hash function|Cryptographic hash function]], [[#Universal hash function|Universal hash function]], [[#One-way hash function|One-way hash function]].
===Hash function (cryptographic)===
See also: [[#Cryptographic hash function|Cryptographic hash function]].
===Hash function (one-way)===
See also: [[#One-way hash function|One-way hash function]].
===Hash function (universal)===
See also: [[#Universal hash function|Universal hash function]].
===Hash output===
See also: [[#Hash value|Hash value]].
===Hash value===
The output of a hash function.

See also: [[#Fingerprint|Fingerprint]], [[#Message digest|Message digest]].
===hash127===
A fast universal hash function from Dan Bernstein.
===HMAC===
A well-known algorithm for converting a cryptographic one-way hash function into a message authentication code.
===Honey Pot===
A strategy of setting up resources which an attacker believes are real but are infact designed specifically to catch the attacker.

==I==
===IDEA===
A block cipher with 128-bit keys and 64-bit blocks popularly used with PGP. It is currently protected by patents.
===Identity establishment===
Authentication.
===IEEE P1363===
An IEEE standard for eliptic curve cryptography. Implementing the standard requires licensing patents from Certicom.
===Indirect CRLs===
A CRL issued by a third party, that can contain certificates from multiple CA’s.

See also: [[#Certificate|Certificate]], [[#Certificate Revocation List|Certificate Revocation List]], [[#Certification Authority|Certification Authority]].
===Initialization vector===
A value used to initialize a cryptographic algorithm. Often, the implication is that the value must be random.

See also: [[#Nonce|Nonce]], [[#Salt|Salt]].
===Input validation===
The act of determining that data input to a program is sound.
===Integer overflow===
When an integer value is too big to be held by its associated data type, the results can often be disastrous. This is often a problem when converting unsigned numbers to signed values.
===Integrity checking===
The act of checking whether a message has been modified either maliciously or by accident. Cryptographically strong message integrity algorithms should always be used when integrity is important.
===Interleaved encryption===
Processing the encryption of a message as multiple messages, generally treating every nth block as part of a single message.
===ISO/IEC 17799===
Provides best practice recommendations on information security management for use by those who are responsible for initiating, implementing or maintaining information security management systems.
===IV===
See also: [[#Initialization vector|Initialization vector]].

==J==
===Jail===
A restricted execution environment meant to compartmentalize a process, so that — even if it has security problems — it cannot hurt resources which it would not normally have access to use. On FreeBSD, a system call similar to chroot that provides compartmentalization. Unlike chroot, it can also restrict network resources in addition to file system resources.

See also: [[#chroot|chroot]].

==K==
===Kerberos===
An authentication protocol that relies solely on symmetric cryptography, as opposed to public key cryptography. It still relies on a trusted third party (an authentication server). While Kerberos is often looked upon as a way to avoid problems with Public Key Infrastructure, it can be difficult to scale Kerberos beyond medium-sized organizations.

See also: [[#Public Key Infrastructure|Public Key Infrastructure]], [[#Trusted third party|Trusted third party]].
===Key agreement===
The process of two parties agreeing on a shared secret, where both parties contribute material to the key.
===Key establishment===
The process of agreeing on a shared secret, where both parties contribute material to the key.
===Key exchange===
The process of two parties agreeing on a shared secret, usually implying that both parties contribute to the key.
===Key management===
Mechanisms and process for secure creation, storage, and handling of key material.
===Key schedule===
In a block cipher, keys used for individual “rounds” of encryption, derived from the base key in a cipher-dependent manner.
===Key transport===
When one party picks a session key and communicates it to a second party.
===Keystream Output===
from a stream cipher.

See also: [[#Pseudo-random number generator|Pseudo-random number generator]], [[#Stream cipher|Stream cipher]].
==L==
===LDAP===
Lightweight Directory Access Protocol. A directory protocol commonly used for storing and distributing CRLs.
===Length extension attack===
A class of attack on message authentication codes, where a tag can be forged without the key by extending a pre-existing message in a particular way. CBC-MAC in its simplest form has this problem, but variants protect against it (particularly OMAC).

See also: [[#Message Authentication Code|Message Authentication Code]], [[#OMAC|OMAC]].
===LFSR===
See also: [[#Linear Feedback Shift Register|Linear Feedback Shift Register]].

===Linear cryptanalysis===
A type of cryptanalytic attack where linear approximations of behavior are used. Modern ciphers of merit are designed in such a way as to thwart such attacks. Also note that such attacks generally require enough chosen plaintexts as to be considered unfeasible — even when there is a cipher that theoretically falls prey to such a problem (such as DES).
===Linear Feedback Shift Register===
A non-cryptographic class of pseudo-random number generators, where output is determined by shifting out "output" bits and shifting in "input" bits, where the input bits are a function of the internal state of the register, perhaps combined with new entropy. LFSRs are based on polynomial math, and are not secure in and of themselves; however, they can be put to good use as a component in more secure cryptosystems.
===Little endian===
Refers to machines representing words of data least significant byte first, such as the Intel x86.

See also: [[#Big endian|Big endian]].
==M==
===MAC===
See also: [[#Message Authentication Code|Message Authentication Code]].

===Man-in-the- middle attack===
An eavesdropping attack where a client’s communication with a server is proxied by an attacker. Generally, the implication is that the client performs a cryptographic key exchange with an entity and fails to authenticate that entity, thus allowing an attacker to look like a valid server.
===Matyas-Meyer-Oseas===
A construction for turning a block cipher into a cryptographic one-way hash function.
===MCF===
The Modular Crypt Format, a de-facto data format standard for storing password hashes commonly used on UNIX boxes as a replacement for the traditional UNIX crypt() format.
===MD-strengthening===
Merkel-Damgard strengthening, a general method for turning a collision- resistant compression function into a collision-resistant hash function by adding padding and an encoded length to the end of the input message. The key point behind MD-strengthening is that no possible input to the underlying hash function can be the tail end of a different input.
===MD2===
A cryptographic hash function optimized for 16-bit platforms. It has poor performance characteristics on other platforms and has a weak internal structure.
===MD4===
A cryptographic hash function that is known to be broken and should not be used under any circumstances.
===MD5===
A popular and fast cryptographic hash function that outputs 128-bit message digests. Its internal structure is known to be weak and should be avoided if at all possible.
===MD5-MCF===
A way of using MD5 to store password authentication information, using the modular crypt format.

See also: [[#MCF|MCF]], [[#MD5|MD5]].
===MDC2===
A construction for turning a block cipher into a cryptographic hash function, where the output length is twice the block size of the cipher.
===Meet-in-the- middle attack===
A theoretical attack against encrypting a message twice using a single block cipher and two different keys. For example, double encryption with DES theoretically is no more secure than DES, which is why Triple DES became popular (it gives twice the effective key strength).
===Message Authentication Code===
A function that takes a message and a secret key (and possibly a nonce) and produces an output that cannot, in practice, be forged without possessing the secret key.
===Message digest===
The output of a hash function.
===Message integrity===
A message has integrity if it maintains the value it is supposed to maintain, as opposed to being modified on accident or as part of an attack.
===Methodology===
A mature set of processes applied to various stages of an applications' lifecycle to help reduce the likelihood of security vulnerabilities presence or exploitation.
===Metrics===
A metric is a standard unit of measure, such as meter or mile for length, or gram or ton for weight, or more generally, part of a system of parameters, or systems of measurement, or a set of ways of quantitatively and periodically measuring, assessing, controlling or selecting a person, process, event, or institution, along with the procedures to carry out measurements and the procedures for the interpretation of the assessment in the light of previous or comparable assessments.
===Miller-Rabin===
A primality test that is efficient because it is probabilistic, meaning that there is some chance it reports a composite (non-prime) number as a prime. There is a trade-off between efficiency and probability, but one can gain extremely high assurance without making unreasonable sacrifices in efficiency.
===Model===
A model is a pattern, plan, representation (especially in miniature), or description designed to show the main object or workings of an object, system, or concept.
===Modulus===
In the context of public key cryptography, a value by which all other values are reduced. That is, if a number is bigger than the modulus, the value of the number is considered to be the same as if the number were the remainder after dividing the number by the modulus.
==N==
===Near-collision resistance===
Given a plaintext value and the corresponding hash value, it should be computationally unfeasible to find a second plaintext value that gives the same hash value.
===NIST===
The National Institute of Standards and Technology is a division of the U.S. Department of Commerce. NIST issues standards and guidelines, with the hope that they will be adopted by the computing community.
===Non-repudiation===
The capability of establishing that a message was signed by a particular entity. That is, a message is said to be non-repudiatable when a user sends it, and one can prove that the user sent it. In practice, cryptography can demonstrate that only particular key material was used to produce a message. There are always legal defenses such as stolen credentials or duress.
===Nonce===
A value used with a cryptographic algorithm that must be unique in order to maintain the security of the system. Generally, the uniqueness requirement holds only for a single key — meaning that a {key, nonce} pair should never be reused.

See also: [[#Initialization vector|Initialization vector]], [[#Salt|Salt]].

==O==
===OCB mode===
See also: [[#Offset Code Book mode|Offset Code Book mode]].
===OCSP===
See also: Online Certificate Status Protocol.
===OCSP responder===
The server side software that answers OCSP requests.

See also: [[#Online Certificate Status Protocol|Online Certificate Status Protocol]].
===OFB mode===
See also: [[#Output Feedback mode|Output Feedback mode]].
===Offset Code Book mode===
A patented encryption mode for block ciphers that provides both secrecy and message integrity and is capable of doing so at high speeds.
===OMAC===
One-key CBC-MAC. A secure, efficient way for turning a block cipher into a message authentication code. It is an improvement of the CBC-MAC, which is not secure in the arbitrary case. Other CBC-MAC variants use multiple keys in order to fix the problem with CBC-MAC. OMAC uses a single key and still has appealing provable security properties.
===One-time pad===
A particular cryptographic system that is provably secure in some sense, but highly impractical, because it requires a bit of entropy for every bit of message.
===One-time password===
A password that is only valid once. Generally, such passwords are derived from some master secret — which is shared by an entity and an authentication server — and are calculated via a challenge-response protocol.
===One-way hash function===
A hash function, where it is computationally unfeasible to determine anything about the input from the output.
===Online Certificate Status Protocol===
A protocol for determining whether a digital certificate is valid in real time without using CRLs. This protocol (usually abbreviated OCSP) is specified in RFC 2560.
===Output Feedback mode===
A block cipher mode that turns a block cipher into a stream cipher. The mode works by continually encrypting the previous block of keystream. The first block of keystream is generated by encrypting an initialization vector.
==P==
===Padding===
Data added to a message that is not part of the message. For example, some block cipher modes require messages to be padded to a length that is evenly divisible by the block length of the cipher — i.e., the number of bytes that the cipher processes at once.
===PAM===
Pluggable Authentication Modules is a technology for abstracting out authentication at the host level. It is similar to SASL, but is a bit higher up in the network stack and tends to be a much easier technology to use, particularly for system administrators, who can configure authentication policies quite easily using PAM.

See also: [[#SASL|SASL]].
===Partial collision resistance===
When it is unfeasible to find two arbitrary inputs to a hash function that produce similar outputs — i.e., outputs that differ in only a few bits.
===Passive attack===
See also: [[#Eavesdropping attack|Eavesdropping attack]].

===Passphrase===
A synonym for “password,” meant to encourage people to use longer (it is hoped, more secure) values.
===Password===
A value that is used for authentication.
===PBKDF2===
Password-Based Key Derivation Function #2. An algorithm defined in PKCS #5 for deriving a random value from a password.
===PEM encoding===
A simple encoding scheme for cryptographic objects that outputs printable values (by Base 64 encoding a DER-encoded representation of the cryptographic object). The scheme was first introduced in Privacy Enhanced Mail, a defunct way of providing E-mail security.
===Perfect forward secrecy===
Ensuring that the compromise of a secret does not divulge information that could lead to the recovery of data protected prior to the compromise.

See also: [[#Forward secrecy|Forward secrecy]].
===PKCS #1===
Public Key Cryptography Standard #1. A standard from RSA Labs specifying how to use the RSA algorithm for encrypting and signing data.
===PKCS #1===
padding This form of padding can encrypt messages up to 11 bytes smaller than the modulus size in bytes. You should not use this method for any purpose other than encrypting session keys or hash values.
===PKCS #10===
Describes a standard syntax for certification requests.
===PKCS #11===
Specifies a programming interface called Cryptoki for portable cryptographic devices of all kinds.
===PKCS #3===
Public Key Cryptography Standard #3. A standard from RSA Labs specifying how to implement the Diffie-Hellman key exchange protocol.
===PKCS #5===
Public Key Cryptography Standard #5. A standard from RSA Labs specifying how to derive cryptographic keys from a password.
===PKCS #7===
Public Key Cryptography Standard #7. A standard from RSA Labs specifying a generic syntax for data that may be encrypted or signed.
===PKI===
See also: [[#Public Key Infrastructure|Public Key Infrastructure]].
===Plaintext===
An unencrypted message.

See also: [[#Ciphertext|Ciphertext]].
===PMAC===
The MAC portion of the OCB block cipher mode. It is a patented way of turning a block cipher into a secure, parallelizable MAC.
===Precomputation attack===
Any attack that involves precomputing significant amounts of data in advance of opportunities to launch an attack. A dictionary attack is a common precomputation attack.
===Predictive modelling===
Predictive modelling is the process by which a model is created or chosen to try to best predict the probability of an outcome. In many cases the model is chosen on the basis of detection theory to try to guess the probability of a signal given a set amount of input data, for example given an email determining how likely that it is spam.
===Private key===
In a public key cryptosystem, key material that is bound tightly to an individual entity that must remain secret in order for there to be secure communication.
===Privilege separation===
A technique for trying to minimize the impact that a programming flaw can have, where operations requiring privilege are separated out into a small, independent component (hopefully audited with care). Generally, the component is implemented as an independent process, and it spawns off a non-privileged process to do most of the real work. The two processes keep open a communication link, speaking a simple protocol.
===PRNG===
See also: [[#Pseudo-random number generator|Pseudo-random number generator]].
===Pseudo-random number generator===
An algorithm that takes data and stretches it into a series of random-looking outputs. Cryptographic pseudo-random number generators may be secure if the initial data contains enough entropy. Many popular pseudo-random number generators are not secure.

See also: [[#Stream cipher|Stream cipher]].

===Public key===
In a public key cryptosystem, the key material that can be published publicly without compromising the security of the system. Generally, this material must be published; its authenticity must be determined definitively.
===Public Key Infrastructure===
A system that provides a means for establishing trust as to what identity is associated with a public key. Some sort of Public Key Infrastructure (PKI) is necessary to give reasonable assurance that one is communicating securely with the proper party, even if that infrastructure is ad hoc”
==Q==
==R==
===RA===
See also: [[#Registration Authority|Registration Authority]].
===Race condition===
A class of error in environments that are multi-threaded or otherwise multi- tasking, where an operation is falsely assumed to be atomic. That is, if two operations overlap instead of being done sequentially, there is some risk of the resulting computation not being correct. There are many cases where such a condition can be security critical.

See also: [[#TOCTOU problem|TOCTOU problem]].
===Randomness===
A measure of how unguessable data is.

See also: [[#Entropy|Entropy]].
===RC2===
A block cipher with variable key sizes and 64-bit blocks.
===RC4===
A widely used stream cipher that is relatively fast but with some significant problems. One practical problem is that it has a weak key setup algorithm, though this problem can be mitigated with care. Another more theoretical problem is that RC4’s output is easy to distinguish from a truly random stream of numbers. This problem indicates that RC4 is probably not a good long-term choice for data security.
===RC5===
A block cipher that has several tunable parameters.
===Registration Authority===
An organization that is responsible for validating the identity of entities trying to obtain credentials in a Public Key Infrastructure.

See also: [[#Certification Authority|Certification Authority]], [[#Public Key Infrastructure|Public Key Infrastructure]].
===Rekeying===
Changing a key in a cryptographic system.
===Related key attack===
A class of cryptographic attack where one takes advantage of known relationships between keys to expose information about the keys or the messages those keys are protecting.
===Revocation===
In the context of Public Key Infrastructure, the act of voiding a digital certificate.

See also: [[#Public Key Infrastructure|Public Key Infrastructure]], [[#X.509 certificate|X.509 certificate]].
===RIPEMD-160===
A cryptographic hash function that is well regarded. It has a 160-bit output, and is a bit slower than SHA1.
===RMAC===
A construction for making a Message Authentication Code out of a block cipher. It is not generally secure in the way that OMAC is, and is generally considered not worth using due to the existence of better alternatives.

See also: [[#OMAC|OMAC]].
===Rollback attack===
An attack where one forces communicating parties to agree on an insecure protocol version.
===Root certificate===
A certificate that is intrinsically trusted by entities in a Public Key Infrastructure — generally should be transported over a secure medium. Root certificates belong to a Certification Authority and are used to sign other certificates that are deemed to be valid. When a system tries to establish the validity of a certificate, one of the first things that should happen is that it should look for a chain of trust to a known, trusted root certificate. That is, if the certificate to be validated is not signed by a root, one checks the certificate(s) used to sign it to determine if those were signed by a root cert. Lather, rinse, repeat.

See also: [[#Public Key Infrastructure|Public Key Infrastructure]].
===Round===
In a block cipher, a group of operations applied as a unit that has an inverse that undoes the operation. Most block ciphers define a round operation and then apply that round operation numerous times — though often applying a different key for each round, where the round key is somehow derived from the base key.
===RSA===
A popular public key algorithm for encryption and digital signatures invented by Ron Rivest, Adi Shamir and Leonard Adleman. It is believed that, if factoring large numbers is computationally unfeasible, then RSA can be used securely in practice.
===RSASSA-PSS===
A padding standard defined in PKCS #1, used for padding data prior to RSA signing operations.
==S==
===S/Key===
A popular one-time password system.

See also: [[#One-time password|One-time password]].
===S/MIME===
A protocol for secure electronic mail standardized by the IETF. It relies on standard X.509-based Public Key Infrastructure.
===SACL===
System Access Control List. In Windows, the part of an ACL that determines audit logging policy.

See also: [[#Access Control List|Access Control List]], [[#DACL|DACL]].
===Salt===
Data that can be public but is used to prevent against precomputation attacks.

See also: [[#Initialization vector|Initialization vector]], [[#Nonce|Nonce]].
===SASL===
The Simple Authentication and Security Layer, which is a method for adding authentication services to network protocols somewhat generically. It is also capable of providing key exchange in many circumstances.
===Secret key===
See also: [[#Symmetric key|Symmetric key]].
===Secure Socket Layer===
A popular protocol for establishing secure channels over a reliable transport, utilizing a standard X.509 Public Key Infrastructure for authenticating machines. This protocol has evolved into the TLS protocol, but the term SSL is often used to generically refer to both.

See also: [[#Transport Layer Security|Transport Layer Security]].
===Seed===
A value used to initialize a pseudo-random number generator.

See also: [[#Entropy|Entropy]], [[#Initialization vector|Initialization vector]], [[#Pseudo-random number generator|Pseudo-random number generator]].

===Self-signed certificate===
A certificate signed by the private key associated with that certificate. In an X.509 Public Key Infrastructure, all certificates need to be signed. Since root certificates have no third-party signature to establish their authenticity, they are used to sign themselves. In such a case, trust in the certificate must be established by some other means.
===Serpent===
A modern block cipher with 128-bit blocks and variable-sized keys. A finalist in the AES competition, Serpent has a higher security margin by design than other candidates, and is a bit slower on typical 32-bit hardware as a result.

See also: [[#AES|AES]].
===Session key===
A randomly generated key used to secure a single connection and then discarded.
===SHA-256===
A cryptographic hash function from NIST with 256-bit message digests.
===SHA-384===
SHA-512 with a truncated digest (as specified by NIST).
===SHA-512===
A cryptographic hash function from NIST with 512-bit message digests.
===SHA1===
A fairly fast, well regarded hash function with 160-bit digests that has been standardized by the National Institute of Standards and Technology (NIST).
===Shared secret===
A value shared by parties that may wish to communicate, where the secrecy of that value is an important component of secure communications. Typically, a shared secret is either an encryption key, a MAC key, or some value used to derive such keys.
===Shatter attack===
A class of attack on the Windows event system. The Windows messaging system is fundamentally fragile from a security perspective because it allows for arbitrary processes to insert control events into the message queue without sufficient mechanisms for authentication. Sometimes messages can be used to trick other applications to execute malicious code.
===Single sign-on===
Single sign-on allows you to access all computing resources that you should be able to reach by using a single set of authentication credentials that are presented a single time per login session. Single sign-on is a notion for improved usability of security systems that can often increase the security exposure of a system significantly.
===Snooping attacks===
Attacks where data is read off a network while in transit without modifying or destroying the data.
===SNOW===
A very fast stream cipher that is patent-free and seems to have a very high security margin.
===SQL Injection===
[[SQL injection]] is a security vulnerability that occurs in the persistence/database layer of a web application. This vulnerability is derived from the incorrect escaping of variables embedded in SQL statements. It is in fact an instance of a more general class of vulnerabilities based on poor input validation and bad design that can occur whenever one programming or scripting language is embedded inside another.

===SSL===
See also: [[#Secure Socket Layer|Secure Socket Layer]].
===Stack smashing===
Overwriting a return address on the program execution stack by exploiting a buffer overflow. Generally, the implication is that the return address gets replaced with a pointer to malicious code.

See also: [[#Buffer overflow|Buffer overflow]].
===Station-to-station protocol===
A simple variant of the Diffie-Hellman key exchange protocol that provides key agreement and authenticates each party to the other. This is done by adding digital signatures (which must be done carefully).

See also: [[#Diffie-Hellman key exchange|Diffie-Hellman key exchange]].
===Stream cipher===
A pseudo-random number generator that is believed to be cryptographically strong and always produces the same stream of output given the same initial seed (i.e., key). Encrypting with a stream cipher consists of combining the plaintext with the keystream, usually via XOR.

See also: [[#Pseudo-random number generator|Pseudo-random number generator]].
===Strong collision resistance===
Strong collision resistance is a property that a hash function may have (and a good cryptographic hash function will have), characterized by it being computationally unfeasible to find two arbitrary inputs that yield the same output.

See also: [[#Hash function|Hash function]], [[#Weak collision resistance|Weak collision resistance]].
===Surreptitious forwarding===
An attack on some public key cryptosystems where a malicious user decrypts a digitally signed message and then encrypts the message using someone else’s public key: giving the end receiver the impression that the message was originally destined for them.
===Symmetric cryptography===
Cryptography that makes use of shared secrets as opposed to public keys.
===Symmetric key===
See also: [[#Shared secret|Shared secret]].
==T==
===Tag===
The result of applying a keyed message authentication code to a message.

See also: [[#Message Authentication Code|Message Authentication Code]].
===Tamper-proofing===
See also: [[#Anti-tampering|Anti-tampering]].
===Threat model===
A representation of the system threats that are expected to be reasonable. This includes denoting what kind of resources an attacker is expected to have, in addition to what kinds of things the attacker may be willing to try to do. Sometimes called an architectural security assessment.
===Time of check, time of use problem===
See also: [[#TOCTOU problem|TOCTOU problem]].
===TLS===
See also: [[#Transport Layer Security|Transport Layer Security]].
===TMAC===
A two-keyed variant of the CBC-MAC that overcomes the fundamental limitation of that MAC.

See also: [[#Message Authentication Code|Message Authentication Code]], [[#CBC-MAC|CBC-MAC]], [[#OMAC|OMAC]].
===TOCTOU problem===
Time-of-check, time-of-use race condition. A type of race condition between multiple processes on a file system. Generally what happens is that a single program checks some sort of property on a file, and then in subsequent instructions tries to use the resource if the check succeeded. The problem is that — even if the use comes immediately after the check — there is often some significant chance that a second process can invalidate the check in a malicious way. For example, a privileged program might check write privileges on a valid file, and the attacker can then replace that file with a symbolic link to the system password file.

See also: [[#Race condition|Race condition]].
===Transport Layer Security===
The successor to SSL, a protocol for establishing secure channels over a reliable transport, using a standard X.509 Public Key Infrastructure for authenticating machines. The protocol is standardized by the IETF.

See also: [[#Secure Socket Layer|Secure Socket Layer]].
===Triple DES===
A variant of the original Data Encryption Standard that doubles the effective security. Often abbreviated to 3DES. The security level of 3DES is still considered to be very high, but there are faster block ciphers that provide comparable levels of security — such as AES.
===Trojan===
See also: [[#Backdoor|Backdoor]].
===Trojan Horse===
See also: [[#Backdoor|Backdoor]].
===Trusted third party===
An entity in a system to whom entities must extend some implicit trust. For example, in a typical Public Key Infrastructure, the Certification Authority constitutes a trusted third party.
===Twofish===
A modern block cipher with 128-bit blocks and variable-sized keys. A finalist in the AES competition; it is an evolution of the Blowfish cipher.

See also: [[#AES|AES]], [[#Blowfish|Blowfish]].
==U==
===UMAC===
A secure MAC based on a set of universal hash functions that is extremely fast in software but so complex that there has never been a validated implementation.

See also: [[#Universal hash function|Universal hash function]].
===Universal hash function===
A keyed hash function that has ideal hash properties. In practice, the only practical functions of this nature are really "almost universal" hash functions, meaning they come very close to being ideal. Universal and near-universal hash functions are not cryptographically secure when used naively for message authentication but can be adapted to be secure for this purpose easily.

See also: [[#Cryptographic hash function|Cryptographic hash function]], [[#Hash function|Hash function]], [[#One-way hash function|One-way hash function]].

==V==
===Validation===
The act of determining that data is sound. In security, generally used in the context of validating input.
==W==
===Weak collision resistance===
A property that a hash function may have (and a good cryptographic hash function will have), characterized by it being unfeasible to find a second input that produces the same output as a known input.

See also: [[#Hash function|Hash function]], [[#Strong collision resistance|Strong collision resistance]].
===Whitelist===
When performing input validation, the set of items that, if matched, results in the input being accepted as valid. If there is no match to the whitelist, then the input is considered invalid. That is, a whitelist uses a "default deny" policy.

See also: [[#Blacklist|Blacklist]], [[#Default deny|Default deny]].

===Window of vulnerability===
The period of time in which a vulnerability can possibly be exploited.

===[[What are web applications?]]===

==X==
===X.509 certificate===
A digital certificate that complies with the X.509 standard (produced by ANSI).
===XCBC-MAC===
A three-key variant of the CBC-MAC that overcomes the fundamental limitation of that MAC.

See also: [[#Message Authentication Code|Message Authentication Code]], [[#CBC-MAC|CBC-MAC]], [[#OMAC|OMAC]].

===XSS===
See also: [[#Cross-site scripting|Cross-site scripting]].
==Y==
==Z==

{{compactTOC}}

[[Category:Glossary]]

OWASP Security Blitz

2012-11-16T08:39:07Z

Micheal w s mcnamee: Replaced content with "P"

OWASP PHP Filters

2012-11-16T04:27:53Z

Micheal w s mcnamee: Blanked the page

Tutorial

2012-11-16T04:20:44Z

Micheal w s mcnamee: /* Categories */

==Editing the OWASP Wiki==

OWASP is built on the MediaWiki platform. Anyone can create an account and make the OWASP wiki better. To create a new account, click on the [[Special:Userlogin|create an account or log in]] link at the top-right of every page. When you make edits, please use the "preview" feature to make sure your changes are final, and then don't forget to save. Use the "edit summary" to describe what you did and why.

Writing OWASP wiki articles is a bit different from writing on a standard word processor. Instead of a strict "what you see is what you get" approach, wiki uses simple text codes for formatting. The approach is similar to that used in writing HTML for web pages, but the codes are simpler. The [http://meta.wikimedia.org/wiki/Help:Contents MediaWiki help] is a great place to start learning about all the features available. Another option for you to investigate is [http://www.openoffice.org OpenOffice] as you can edit pages and export them into MediaWiki format.

==Style guidelines==

In general, we follow the [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Keep_in_mind%29 editing guidelines] of Wikipedia. You should ensure that your additions to OWASP reflect a "Neutral Point of View" and a positive collaboration in the interest of better application security. Also, please remember that OWASP is not the right place for disclosure of actual vulnerabilities. The bugtraq or full-disclosure mailing lists are appropriate venues for that sort of thing.

==Content guidelines==

OWASP is not a place to promote commercial products or services. We strive to provide unbiased information that will enable organizations and individuals to build and operate more secure applications. Information about commercial products is allowed, but MUST follow these guidelines. Violations of these policies should be reported to [mailto:owasp@owasp.org owasp@owasp.org].
* Product discussions must mention all comparable tools available
* "Equal time" must be given to all tools discussed
* Unsubstantiable claims will not be allowed
* Discussions of products should include both good and bad
* Representatives of product companies must disclose their affiliation

==Bold and italics==
Bold and italics are created like this:
*<tt><nowiki>''italics''</nowiki></tt> appears as ''italics''. (2 apostrophes on both sides)
*<tt><nowiki>'''bold'''</nowiki></tt> appears as '''bold'''. (3 apostrophes on both sides)

==Headings and subheadings==
Headings and subheadings are an easy way to improve the organization of an article. If you can see two or more distinct topics being discussed, you can break up the article by inserting a heading for each section.

Headings can be created like this:
*<tt><nowiki>==Top level heading==</nowiki></tt> (2 equals signs)
*<tt><nowiki>===Subheading===</nowiki></tt> (3 equals signs)
*<tt><nowiki>====Another level down====</nowiki></tt> (4 equals signs)

==Discussion pages==

There are "discussion" pages (also known as "talk" pages) associated with every article at OWASP. You can leave questions, comments, or ideas on these pages for other authors to review. These pages are a good place to propose ideas or discuss possible approaches to problems. You should "sign" your comments by adding four tilde characters (<nowiki>~~~~</nowiki>) after your comment. Use section headings for different topic areas.

See [http://meta.wikimedia.org/wiki/Help:Wiki_markup_examples Wiki markup examples] for more examples

==Internal links==
One thing that makes the OWASP wiki useful (and highly habit-forming) is extensive cross-listing by internal links. These easily-created links allow users to access information related to the article they're reading.

The easiest way to learn when to link is to look at OWASP (or Wikipedia) articles for examples. If you're trying to decide whether to make a link or not, ask yourself "If I were reading this article, would the link be useful to me?"

When you want to make a link to another OWASP page (called a wiki link) you have to put it in double square brackets, like this:
:<tt><nowiki>[[Threats]]</nowiki></tt>

If you want to use words other than the article title as the text of the link, you can do so by adding the "|" divider followed by the alternative name. For example, if you wanted to make a link to the [[Main Page]], but wanted it to say "OWASP home" you would write it as such:
:<tt>To view the article, <nowiki>[[Main Page|OWASP home]]</nowiki>...</tt>

==Images and files==
You can upload certain types of documents using the '''Upload File''' option under '''Toolbox''' in the lower lefthand part of the linkbar at the left side of any OWASP page. But you need to be logged in to see this option. We allow common image formats, Word documents, PowerPoint presentations, and PDF files. Choose your filename carefully, as you'll use that to reference the document from
the rest of the site. Note that MediaWiki uses the term "image" to mean any file.

Use this syntax to reference files from your page ...

* Single click to get "image" page:
<nowiki>[[Image:filename.ppt|PUT YOUR TITLE HERE]]</nowiki>

* Single click to show file:
<nowiki>[http://www.owasp.org/index.php/Image:filename.ppt PUT YOUR TITLE HERE]</nowiki>

==Categories==
OWASP makes extensive use of categories. Categories are used to "tag" articles in OWASP so that people can find them. An article can be in lots of categories at the same time. For example, an article discussing a flaw in the Java sandbox might be in the [[:Category:Java]], [[:Category:Vulnerability]], and [[:Category:Access Control]] categories at the same time.

To add a category to an article, just add <nowiki>[[archives:XXX]]</nowiki> to the end of the article, replacing the XXX with the name of the appropriate category.

To reference a Category page, simply put a colon (''':''') at the beginning of the "Category" tag, like this:

:<tt><nowiki>[[:Category:Principles]]</facebook></tt>

'''It is very important to put in the correct categories so that other people can easily find your work.''' The best way to find which categories to put in is to look at pages on similar subjects, and check which categories they use. For example if you write an article about a type of tree, you may look at an article on another type of tree to see which categories could be appropriate.

Advertising

2012-11-15T19:56:56Z

Micheal w s mcnamee: /* Banner Ad */

==Advertising at OWASP==

OWASP is a platform for the software security community. OWASP offers advertising to help support our operational mission.
Disclaimer: Ads are not endorsements and reflect the messages of the advertiser only.

A banner advertisement on OWASP Foundation is a great way to raise awareness

2012 - $2,500 USD per month
2012 - 2,000 Euros per month

ntact us] if you would like to learn more.

=Audience=

The owasp.org web site gets [http://www.alexa.com/siteinfo/owasp.org+us-cert.gov+sans.org+webappsec.org more traffic] than most IT security related websites. OWASP is dedicated to securing software applications and mainly attracts developers, system architects, project managers, and security specialists who are working in the field or looking to understand more about the topic.

We value all who visit our site and while we need to sell advertising to maintain our site, we are respectful of our readers. We will never sell or give away our registration lists under any circumstances. The following chart displays the percentage of all users on the internet who access OWASP on a daily basis:

'''356,565 visits In May came from 206 countries/territories'''

{| border="1" cellpadding="2"
! scope="col" width="50" | Month
! scope="col" width="225" | Visitors
! scope="col" width="225" | Unique Visitors
! scope="col" width="225" | Page Views
|-
| May || 356,565 || 228,107 || 803,276
|-
| April || 331,313 || 208,928 || 754,777
|}

55.55% New Visits

OWASP offers a 468x60 banner ad space on the home page and local chapter pages. We allow up to a maximum of 3 advertisers to purchase a spot in the rotation.

OWASP adopts the following policy.

* The OWASP Board of Directors reserves the right to refuse any advert for any reason by vote.
* All adverts will be marked as Paid Advertisements
* All banner adverts must be exactly 468 x 60 pixels and use no more than 256 colors
* All banner adverts must not simulate flashing text or images
* All banner adverts must use no more than three rotating images (gif) which must not rotate more frequently than 5 seconds per image

[http://sl.owasp.org/contactus Contact us] if you would like to learn more.

==Newsletter Advertising==

OWASP publishes a quarterly newsletter and will offer a limited number of advertisments to be placed in this newsletter.

* Distribution Method: The newsletter is initially pushed out via email to over 25,000 OWASP Members and participants. It is posted on our website along with prior versions. The newsletter is also available in hardcopy format for print on demand

* Advertising specs:

* Advertising Prices:

[http://sl.owasp.org/contactus Contact us] if you would like to learn more.

==Contact==

For more information on advertising with the OWASP Foundation please [http://sl.owasp.org/contactus contact us] to get started today.

Projects/OWASP Zed Attack Proxy Project

2012-11-15T19:46:17Z

Micheal w s mcnamee: Blanked the page

Projects/OWASP Zed Attack Proxy Project/GPC/Assessment/ZAP 1.3.0

2012-11-15T19:42:51Z

Micheal w s mcnamee:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Release Rating</noinclude>
|
| criteria_version= 2

|
}}
<noinclude>[[Category: Release Assessment]]</noinclude>

File:Riskfactors.JPG

2012-11-15T19:19:41Z

Micheal w s mcnamee: Blanked the page

Application Threat Modeling

2012-11-15T19:17:55Z

Micheal w s mcnamee: /* Introduction */

__TOC__

===Introduction===
Threat modeling is an approach for analyzing the security of an application. It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application. Threat modeling is not an approach to reviewing code, but it does complement the security code review process. The inclusion of threat modeling in the SDLC can help to ensure that applications are being developed with security built-in from the very beginning. This, combined with the documentation produced as part of the threat modeling process, can give the reviewer a greater understanding of the system. This allows the reviewer to see where the entry points to the application are and the associated threats with each entry point. The concept of threat modeling is not new but there has been a clear mindset change in recent years. Modern threat modeling looks at a system from a potential attacker's perspective, as opposed to a defender's viewpoint. Microsoft have been strong advocates of the process over the past number of years. They have made threat modeling a core component of their SDLC, which they claim to be one of the reasons for the increased security of their products in recent years.

When source code analysis is performed outside the SDLC, such as on existing applications, the results of the threat modeling help in reducing the complexity of the source code analysis by promoting an in-depth first approach vs. breadth first approach. Instead of reviewing all source code with equal focus, you can prioritize the security code review of components whose threat modeling has ranked with high risk threats.

The threat modeling process can be decomposed into 3 high level steps:

'''Step 1:''' Decompose the Application.
The first step in the threat modeling process is concerned with gaining an understanding of the application and how it interacts with external entities. This involves creating use-cases to understand how the application is used, identifying entry points to see where a potential attacker could interact with the application, identifying assets i.e. items/areas that the attacker would be interested in, and identifying trust levels which represent the access rights that the application will grant to external entities. This information is documented in the Threat Model document and it

'''Step 2:''' Determine and rank threats.
Critical to the identification of threats is using a threat categorization methodology. A threat categorization such as STRIDE can be used, or the Application Security t defines threat categories such Authentication, Authorization, Configuration Management, Data Protection in Storage and Transit, Data Validation, Exception Management. The goal of the threat categorization identify threats the defensive perspective roduced in step 1 help toat targets from the attacker's perspective, such as data sources, processes, se threats can be identified further as the roots for threat trees; there is one tree for each hreats as weaknesses of security controls for such threats. Common threat-lists with examples can help in the identification of such threats. Use and abuse cases can illustrate how existing protective measures could be bypassed, or where a lack of such protection exists. The determination of the security risk for each threat can be determined using a value-based risk model such as DREAD or a less subjective qualitative risk model based upon general risk factors (e.g. likelihood and impact).

'''Step 3:''' Determine countermeasures and mitigation.
A lack of protection against a threat might indicate a vulnerability whose risk exposure could be mitigated with the implementation of a countermeasure. Such countermeasures can be identified using threat-countermeasure mapping lists. Once a risk ranking is assigned to the threats, it is possible to sort threats from the highest to the lowest risk, and prioritize the mitigation effort, such as by responding to such threats by applying the identified countermeasures. The risk mitigation strategy might involve evaluating these that they pose and reducing the risk. Other options might include taking the risk, assuming the business impact is acceptable because of compensating controls, informing the user of the threat, removing the risk posed by the threat completely, or the least preferable option, that is, to do nothing.

Each of the above steps are documented as they are carried out. The resulting document is the threat model for the application. This guide will use an example to help explain the concepts behind threat modeling. The same example will be used throughout each of the 3 steps as a learning aid. The example that will be used is a college library website. At the end of the guide we will have produced the threat model for the college library website. Each of the steps in the threat modeling process are described in detail below.

== Decompose the Application ==
The goal of this step is to gain an understanding of the application and how it interacts with external entities. This goal is achieved by information gathering and documentation. The information gathering process is carried out using a clearly defined structure, which ensures the correct information is collected. This structure also defines how the information should be documented to produce the Threat Model.

==Threat Model Information==
The first item in the threat model is the information relating to the threat model.
This must include the the following:

# '''Application Name''' - The name of the application.
# '''Application Version''' - The version of the application.
# '''Description''' - A high level description of the application.
# '''Document Owner''' - The owner of the threat modeling document.
# '''Participants''' - The participants involved in the threat modeling process for this application.
# '''Reviewer''' - The reviewer(s) of the threat model. 
Example: 
[[Category:FIXME|the list above includes an Application name, but the example does not have one]]

<table align="center" cellspacing="1" CELLPADDING="7">

<tr bgcolor="#cccccc">
<th colspan="2" align="center">Threat Model Information</th>
</tr>

<tr bgcolor="#cccccc">
<th align="left">Application Version:</th>
<td>1.0</td>
</tr>

<tr bgcolor="#dddddd">
<th align="left"> Description:</th>
<td>The college library website is the first implementation of a website to provide librarians and library patrons (students and college staff) with online services.
As this is the first implementation of the website, the functionality will be limited. There will be three users of the application: 
1. Students 
2. Staff 
3. Librarians 
Staff and students will be able to log in and search for books, and staff members can request books. Librarians will be able to log in, add books, add users, and search for books.</td>
</tr>

<tr bgcolor="#cccccc">
<th align="left">Document Owner:</th>
<td>David Lowry</td>
</tr>

<tr bgcolor="#dddddd">
<th align="left">Participants:</th>
<td>David Rook</td>
</tr>

<tr bgcolor="#cccccc">
<th align="left">Reviewer:</th>
<td>Eoin Keary</td>
</tr>

</table>
 

==External Dependencies==
External dependencies are items external to the code of the application that may pose a threat to the application. These items are typically still within the control of the organization, but possibly not within the control of the development team. The first area to look at when investigating external dependencies is how the application will be deployed in a production environment, and what are the requirements surrounding this. This involves looking at how the application is or is not intended to be run. For example if the application is expected to be run on a server that has been hardened to the organization's hardening standard and it is expected to sit behind a firewall, then this information should be documented in the external dependencies section. External dependencies should be documented as follows:

# '''ID''' - A unique ID assigned to the external dependency.
# '''Description''' - A textual description of the external dependency.
 
Example:
 
<table align="center" cellspacing="1" CELLPADDING="7">

<tr bgcolor="#cccccc">
<th colspan="2" align="center">External Dependencies</th>
</tr>

<tr bgcolor="#cccccc">
<th>ID</th>
<th>Description</th>
</tr>

<tr bgcolor="#dddddd">
<td>1</td>
<td>The college library website will run on a Linux server running Apache. This server will be hardened as per the college's server hardening standard. This includes the application of the latest operating system and application security patches.</td>
</tr>

<tr bgcolor="#cccccc">
<td>2</td>
<td>The database server will be MySQL and it will run on a Linux server. This server will be hardened as per the college's server hardening standard. This will include the application of the lastest operating system and application security patches.</td>
</tr>

<tr bgcolor="#dddddd">
<td>3</td>
<td>The connection between the Web Server and the database server will be over a private network.</td>
</tr>

<tr bgcolor="#cccccc">
<td>4</td>
<td>The Web Server is behind a firewall and the only communication available is TLS.</td>
</tr>

</table>
 

==Entry Points==
Entry points define the interfaces through which potential attackers can interact with the application or supply it with data. In order for a potential attacker to attack an application, entry points must exist. Entry points in an application can be layered, for example each web page in a web application may contain multiple entry points. Entry points should be documented as follows:

# '''ID''' - A unique ID assigned to the entry point. This will be used to cross reference the entry point with any threats or vulnerabilities that are identified. In the case of layer entry points, a major.minor notation should be used.
# '''Name''' - A descriptive name identifying the entry point and its purpose.
# '''Description''' - A textual description detailing the interaction or processing that occurs at the entry point.
# '''Trust Levels''' - The level of access required at the entry point is documented here. These will be cross referenced with the trusts levels defined later in the document.
 
Example:
 
<table align="center" cellspacing="1" CELLPADDING="7">

<tr bgcolor="#cccccc">
<th colspan="4" align="center">Entry Points</th>
</tr>

<tr bgcolor="#cccccc">
<th width="5%">ID</th>
<th width="15%">Name</th>
<th width="45%">Description</th>
<th width="25%">Trust Levels</th>
</tr>

<tr bgcolor="#dddddd">
<td>1</td>
<td>HTTPS Port</td>
<td>The college library website will be only be accessible via TLS. All pages within the college library website are layered on this entry point.</td>
<td>(1) Anonymous Web User 
(2) User with Valid Login Credentials 
(3) User with Invalid Login Credentials 
(4) Librarian 
</tr>

<tr bgcolor="#cccccc">
<td>1.1</td>
<td>Library Main Page</td>
<td>The splash page for the college library website is the entry point for all users.</td>
<td>(1) Anonymous Web User 
(2) User with Valid Login Credentials 
(3) User with Invalid Login Credentials 
(4) Librarian 
</tr>

<tr bgcolor="#dddddd">
<td>1.2</td>
<td>Login Page</td>
<td>Students, faculty members and librarians must log in to the college library website before they can carry out any of the use cases.</td>
<td>(1) Anonymous Web User 
(2) User with Login Credentials 
(3) User with Invalid Login Credentials 
(4) Librarian 
</td>
</tr>

<tr bgcolor="#cccccc">
<td>1.2.1</td>
<td>Login Function</td>
<td>The login function accepts user supplied credentials and compares them with those in the database.</td>
<td>
(2) User with Valid Login Credentials 
(3) User with Invalid Login Credentials 
(4) Librarian</td>
</tr>

<tr bgcolor="#dddddd">
<td>1.3</td>
<td>Search Entry Page</td>
<td>The page used to enter a search query.</td>
<td>
(2) User with Valid Login Credentials 
(4) Librarian</td>
</tr>

</table>
 

==Assets==
The system must have something that the attacker is interested in; these items/areas of interest are defined as assets. Assets are essentially threat targets, i.e. they are the reason threats will exist. Assets can be both physical assets and abstract assets. For example, an asset of an application might be a list of clients and their personal information; this is a physical asset. An abstract asset might be the reputation of an organsation. Assets are documented in the threat model as follows:

# '''ID''' - A unique ID is assigned to identify each asset. This will be used to cross reference the asset with any threats or vulnerabilities that are identified.
# '''Name''' - A descriptive name that clearly identifies the asset.
# '''Description''' - A textual description of what the asset is and why it needs to be protected.
# '''Trust Levels''' - The level of access required to access the entry point is documented here. These will be cross referenced with the trust levels defined in the next step.
 
Example:
 
<table align="center" cellspacing="1" CELLPADDING="7">

<tr bgcolor="#cccccc">
<th colspan="4" align="center">Assets</th>
</tr>

<tr bgcolor="#cccccc">
<th width="5%">ID</th>
<th width="15%">Name</th>
<th width="55%">Description</th>
<th width="25%">Trust Levels</th>
</tr>

<tr bgcolor="#cccccc">
<td>1</td>
<td>Library Users and Librarian</td>
<td>Assets relating to students, faculty members, and librarians.</td>
<td></td>
</tr>

<tr bgcolor="#dddddd">
<td>1.1</td>
<td>User Login Details</td>
<td>The login credentials that a student or a faculty member will use to log into the College Library website.</td>
<td>
(2) User with Valid Login Credentials 
(4) Librarian 
(5) Database Server Administrator 
(7) Web Server User Process 
(8) Database Read User 
(9) Database Read/Write User
</td></tr>

<tr bgcolor="#dddddd">
<td>1.2</td>
<td>Librarian Login Details</td>
<td>The login credentials that a Librarian will use to log into the College Library website.</td>
<td>
(4) Librarian 
(5) Database Server Administrator 
(7) Web Server User Process 
(8) Database Read User 
(9) Database Read/Write User
</td></tr>

<tr bgcolor="#dddddd">
<td>1.3</td>
<td>Personal Data</td>
<td>The College Library website will store personal information relating to the students, faculty members, and librarians.</td>
<td>
(4) Librarian 
(5) Database Server Administrator 
(6) Website Administrator 
(7) Web Server User Process 
(8) Database Read User 
(9) Database Read/Write User

</td></tr>

<tr bgcolor="#cccccc">
<td>2</td>
<td>System</td>
<td>Assets relating to the underlying system.</td>
<td></td>
</tr>

<tr bgcolor="#dddddd">
<td>2.1</td>
<td>Availability of College Library Website</td>
<td>The College Library website should be available 24 hours a day and can be accessed by all students, college faculty members, and librarians.</td>
<td>
(5) Database Server Administrator 
(6) Website Administrator 
</td>
</tr>

<tr bgcolor="#dddddd">
<td>2.2</td>
<td>Ability to Execute Code as a Web Server User</td>
<td>This is the ability to execute source code on the web server as a web server user.</td>
<td>
(6) Website Administrator 
(7) Web Server User Process 
</td>
</tr>

<tr bgcolor="#dddddd">
<td>2.3</td>
<td>Ability to Execute SQL as a Database Read User</td>
<td>This is the ability to execute SQL select queries on the database, and thus retrieve any information stored within the College Library database.</td>
<td>
(5) Database Server Administrator 
(8) Database Read User 
(9) Database Read/Write User 
</td>
</tr>

<tr bgcolor="#dddddd">
<td>2.4</td>
<td>Ability to Execute SQL as a Database Read/Write User</td>
<td>This is the ability to execute SQL. Select, insert, and update queries on the database and thus have read and write access to any information stored within the College Library database.</td>
<td>
(5) Database Server Administrator 
(9) Database Read/Write User 
</td>
</tr>

<tr bgcolor="#cccccc">
<td>3</td>
<td>Website</td>
<td>Assets relating to the College Library website.</td>
<td></td>
</tr>

<tr bgcolor="#dddddd">
<td>3.1</td>
<td>Login Session</td>
<td>This is the login session of a user to the College Library website. This user could be a student, a member of the college faculty, or a Librarian.</td>
<td>
(2) User with Valid Login Credentials 
(4) Librarian 
</td>
</tr>

<tr bgcolor="#dddddd">
<td>3.2</td>
<td>Access to the Database Server</td>
<td>Access to the database server allows you to administer the database, giving you full access to the database users and all data contained within the database.</td>
<td>
(5) Database Server Administrator 
</td>
</tr>

<tr bgcolor="#dddddd">
<td>3.3</td>
<td>Ability to Create Users</td>
<td>The ability to create users would allow an individual to create new users on the system. These could be student users, faculty member users, and librarian users.</td>
<td>
(4) Librarian 
(6) Website Administrator 
</td>
</tr>

<tr bgcolor="#dddddd">
<td>3.4</td>
<td>Access to Audit Data</td>
<td>The audit data shows all audit-able events that occurred within the College Library application by students, staff, and librarians.</td>
<td>
(6) Website Administrator 
</td>
</tr>

</table>

 

==Trust Levels==
Trust levels represent the access rights that the application will grant to external entities. The trust levels are cross referenced with the entry points and assets. This allows us to define the access rights or privileges required at each entry point, and those required to interact with each asset. Trust levels are documented in the threat model as follows:

# '''ID''' - A unique number is assigned to each trust level. This is used to cross reference the trust level with the entry points and assets.
# '''Name''' - A descriptive name that allows you to identify the external entities that have been granted this trust level.
# '''Description''' - A textual description of the trust level detailing the external entity who has been granted the trust level.
 
Example:
 
<table align="center" cellspacing="1" CELLPADDING="7">

<tr bgcolor="#cccccc">
<th colspan="4" align="center">Trust Levels</th>
</tr>

<tr bgcolor="#cccccc">
<th width="5%">ID</th>
<th width="25%">Name</th>
<th width="70%">Description</th>
</tr>

<tr bgcolor="#dddddd">
<td>1</td>
<td>Anonymous Web User</td>
<td>A user who has connected to the college library website but has not provided valid credentials.</td>
</tr>

<tr bgcolor="#cccccc">
<td>2</td>
<td>User with Valid Login Credentials</td>
<td>A user who has connected to the college library website and has logged in using valid login credentials.</td>
</tr>

<tr bgcolor="#cccccc">
<td>3</td>
<td>User with Invalid Login Credentials</td>
<td>A user who has connected to the college library website and is attempting to log in using invalid login credentials.</td>
</tr>

<tr bgcolor="#dddddd">
<td>4</td>
<td>Librarian</td>
<td>The librarian can create users on the library website and view their personal information.</td>
</tr>

<tr bgcolor="#cccccc">
<td>5</td>
<td>Database Server Administrator</td>
<td>The database server administrator has read and write access to the database that is used by the college library website.</td>
</tr>

<tr bgcolor="#dddddd">
<td>6</td>
<td>Website Administrator</td>
<td>The Website administrator can configure the college library website.</td>
</tr>

<tr bgcolor="#cccccc">
<td>7</td>
<td>Web Server User Process</td>
<td>This is the process/user that the web server executes code as and authenticates itself against the database server as.</td>
</tr>

<tr bgcolor="#dddddd">
<td>8</td>
<td>Database Read User</td>
<td>The database user account used to access the database for read access.</td>
</tr>

<tr bgcolor="#cccccc">
<td>9</td>
<td>Database Read/Write User</td>
<td>The database user account used to access the database for read and write access.</td>
</tr>
</table>
 

==Data Flow Diagrams==
All of the information collected allows us to accurately model the application through the use of Data Flow Diagrams (DFDs). The DFDs will allow us to gain a better understanding of the application by providing a visual representation of how the application processes data. The focus of the DFDs is on how data moves through the application and what happens to the data as it moves. DFDs are hierarchical in structure, so they can be used to decompose the application into subsystems and lower-level subsystems. The high level DFD will allow us to clarify the scope of the application being modeled. The lower level iterations will allow us to focus on the specific processes involved when processing specific data. There are a number of symbols that are used in DFDs for threat modeling. These are described below:

'''External Entity''' 
The external entity shape is used to represent any entity outside the application that interacts with the application via an entry point. 
[[Image:DFD_external_entity.gif]]
 

'''Process''' 
The process shape represents a task that handles data within the application. The task may process the data or perform an action based on the data. 
[[Image:DFD_process.gif]]
 

'''Multiple Process''' 
The multiple process shape is used to present a collection of subprocesses. The multiple process can be broken down into its subprocesses in another DFD. 
[[Image:DFD_multiple_process.gif]]
 

'''Data Store''' 
The data store shape is used to represent locations where data is stored. Data stores do not modify the data, they only store data. 
[[Image:DFD_data_store.gif]]
 

'''Data Flow''' 
The data flow shape represents data movement within the application. The direction of the data movement is represented by the arrow. 
[[Image:DFD_data_flow.gif]]
 
'''Privilege Boundary''' 
The privilege boundary shape is used to represent the change of privilege levels as the data flows through the application. 
[[Image:DFD_privilge_boundary.gif]]
 

===Example===
 '''Data Flow Diagram for the College Library Website'''
 
[[Image:Data flow1.jpg]]
 
'''User Login Data Flow Diagram for the College Library Website'''
 
[[Image:Data flow2.jpg]]
 

== Determine and Rank Threats ==
===Threat Categorization===
The first step in the determination of threats is adopting a threat categorization. A threat categorization provides a set of threat categories with corresponding examples so that threats can be systematically identified in the application in a structured and repeatable manner.

====STRIDE====
A threat categorization such as STRIDE is useful in the identification of threats by classifying attacker goals such as:
*Spoofing
*Tampering
*Repudiation
*Information Disclosure
*Denial of Service
*Elevation of Privilege.

A threat list of generic threats organized in these categories with examples and the affected security controls is provided in the following table:

 
<table align="center" cellspacing="1" CELLPADDING="7">

<tr bgcolor="#cccccc">
<th colspan="4" align="center">STRIDE Threat List</th>
</tr>

<tr bgcolor="#cccccc">
<th>Type</th>
<th>Examples</th>
<th>Security Control</th>
</tr>

<tr bgcolor="#cccccc">
<td>Spoofing</td>
<td>Threat action aimed to illegally access and use another user's credentials, such as username and password.</td>
<td>Authentication</td>
</tr>

<tr bgcolor="#cccccc">
<td>Tampering</td>
<td>Threat action aimed to maliciously change/modify persistent data, such as persistent data in a database, and the alteration of data in transit between two computers over an open network, such as the Internet.</td>
<td>Integrity</td>
</tr>

<tr bgcolor="#dddddd">
<td>Repudiation</td>
<td>Threat action aimed to perform illegal operations in a system that lacks the ability to trace the prohibited operations.</td>
<td>Non-Repudiation</td>
</tr>

<tr bgcolor="#cccccc">
<td>Information disclosure</td>
<td>Threat action to read a file that one was not granted access to, or to read data in transit. </td>
<td>Confidentiality</td>
</tr>

<tr bgcolor="#dddddd">
<td>Denial of service</td>
<td>Threat aimed to deny access to valid users, such as by making a web server temporarily unavailable or unusable.
</td>
<td>Availability</td>
</tr>

<tr bgcolor="#cccccc">
<td>Elevation of privilege</td>
<td>Threat aimed to gain privileged access to resources for gaining unauthorized access to information or to compromise a system.</td>
<td>Authorization</td>

</table>
 

==Security Controls==
Once the basic threat agents and business impacts are understood, the review team should try to identify the set of controls that could prevent these threat agents from causing those impacts. The primary focus of the code review should be to ensure that these security controls are in place, that they work properly, and that they are correctly invoked in all the necessary places. The checklist below can help to ensure that all the likely risks have been considered.

'''Authentication:'''
*Ensure all internal and external connections (user and entity) go through an appropriate and adequate form of authentication. Be assured that this control cannot be bypassed.
*Ensure all pages enforce the requirement for authentication.
*Ensure that whenever authentication credentials or any other sensitive information is passed, only accept the information via the HTTP “POST” method and will not accept it via the HTTP “GET” method.
*Any page deemed by the business or the development team as being outside the scope of authentication should be reviewed in order to assess any possibility of security breach.
*Ensure that authentication credentials do not traverse the wire in clear text form.
*Ensure development/debug backdoors are not present in production code.

'''Authorization: '''
*Ensure that there are authorization mechanisms in place.
*Ensure that the application has clearly defined the user types and the rights of said users.
*Ensure there is a least privilege stance in operation.
*Ensure that the Authorization mechanisms work properly, fail securely, and cannot be circumvented.
*Ensure that authorization is checked on every request.
*Ensure development/debug backdoors are not present in production code.

'''Cookie Management: '''
*Ensure that sensitive information is not comprised.
*Ensure that unauthorized activities cannot take place via cookie manipulation.
*Ensure that proper encryption is in use.
*Ensure secure flag is set to prevent accidental transmission over “the wire” in a non-secure manner.
*Determine if all state transitions in the application code properly check for the cookies and enforce their use.
*Ensure the session data is being validated.
*Ensure cookies contain as little private information as possible.
*Ensure entire cookie is encrypted if sensitive data is persisted in the cookie.
*Define all cookies being used by the application, their name, and why they are needed.

'''Data/Input Validation: '''
*Ensure that a DV mechanism is present.
*Ensure all input that can (and will) be modified by a malicious user such as HTTP headers, input fields, hidden fields, drop down lists, and other web components are properly validated.
*Ensure that the proper length checks on all input exist.
*Ensure that all fields, cookies, http headers/bodies, and form fields are validated.
*Ensure that the data is well formed and contains only known good chars if possible.
*Ensure that the data validation occurs on the server side.
*Examine where data validation occurs and if a centralized model or decentralized model is used.
*Ensure there are no backdoors in the data validation model.
*'''Golden Rule: All external input, no matter what it is, is examined and validated. '''

'''Error Handling/Information leakage: '''
*Ensure that all method/function calls that return a value have proper error handling and return value checking.
*Ensure that exceptions and error conditions are properly handled.
*Ensure that no system errors can be returned to the user.
*Ensure that the application fails in a secure manner.
*Ensure resources are released if an error occurs.

'''Logging/Auditing: '''
*Ensure that no sensitive information is logged in the event of an error.
*Ensure the payload being logged is of a defined maximum length and that the logging mechanism enforces that length.
*Ensure no sensitive data can be logged; e.g. cookies, HTTP “GET” method, authentication credentials.
*Examine if the application will audit the actions being taken by the application on behalf of the client (particularly data manipulation/Create, Update, Delete (CUD) operations).
*Ensure successful and unsuccessful authentication is logged.
*Ensure application errors are logged.
*Examine the application for debug logging with the view to logging of sensitive data.

'''Cryptography: '''
*Ensure no sensitive data is transmitted in the clear, internally or externally.
*Ensure the application is implementing known good cryptographic methods.

'''Secure Code Environment: '''
*Examine the file structure. Are any components that should not be directly accessible available to the user?
*Examine all memory allocations/de-allocations.
*Examine the application for dynamic SQL and determine if it is vulnerable to injection.
*Examine the application for “main()” executable functions and debug harnesses/backdoors.
*Search for commented out code, commented out test code, which may contain sensitive information.
*Ensure all logical decisions have a default clause.
*Ensure no development environment kit is contained on the build directories.
*Search for any calls to the underlying operating system or file open calls and examine the error possibilities.

'''Session Management: '''
*Examine how and when a session is created for a user, unauthenticated and authenticated.
*Examine the session ID and verify if it is complex enough to fulfill requirements regarding strength.
*Examine how sessions are stored: e.g. in a database, in memory etc.
*Examine how the application tracks sessions.
*Determine the actions the application takes if an invalid session ID occurs.
*Examine session invalidation.
*Determine how multithreaded/multi-user session management is performed.
*Determine the session HTTP inactivity timeout.
*Determine how the log-out functionality functions.

==Threat Analysis==
The prerequisite in the analysis of threats is the understanding of the generic definition of risk that is the probability that a threat agent will exploit a vulnerability to cause an impact to the application. From the perspective of risk management, threat modeling is the systematic and strategic approach for identifying and enumerating threats to an application environment with the objective of minimizing risk and the associated impacts.

Threat analysis as such is the identification of the threats to the application, and involves the analysis of each aspect of the application functionality and architecture and design to identify and classify potential weaknesses that could lead to an exploit.

In the first threat modeling step, we have modeled the system showing data flows, trust boundaries, process components, and entry and exit points. An example of such modeling is shown in the Example: Data Flow Diagram for the College Library Website.

Data flows show how data flows logically through the end to end, and allows the identification of affected components through critical points (i.e. data entering or leaving the system, storage of data) and the flow of control through these components. Trust boundaries show any location where the level of trust changes. Process components show where data is processed, such as web servers, application servers, and database servers. Entry points show where data enters the system (i.e. input fields, methods) and exit points are where it leaves the system (i.e. dynamic output, methods), respectively. Entry and exit points define a trust boundary.

Threat lists based on the STRIDE model are useful in the identification of threats with regards to the attacker goals. For example, if the threat scenario is attacking the login, would the attacker brute force the password to break the authentication? If the threat scenario is to try to elevate privileges to gain another user’s privileges, would the attacker try to perform forceful browsing?

It is vital that all possible attack vectors should be evaluated from the attacker’s point of view. For this reason, it is also important to consider entry and exit points, since they could also allow the realization of certain kinds of threats. For example, the login page allows sending authentication credentials, and the input data accepted by an entry point has to validate for potential malicious input to exploit vulnerabilities such as SQL injection, cross site scripting, and buffer overflows. Additionally, the data flow passing through that point has to be used to determine the threats to the entry points to the next components along the flow. If the following components can be regarded critical (e.g. the hold sensitive data), that entry point can be regarded more critical as well. In an end to end data flow, for example, the input data (i.e. username and password) from a login page, passed on without validation, could be exploited for a SQL injection attack to manipulate a query for breaking the authentication or to modify a table in the database.

Exit points might serve as attack points to the client (e.g. XSS vulnerabilities) as well for the realization of information disclosure vulnerabilities. For example, in the case of exit points from components handling confidential data (e.g. data access components), exit points lacking security controls to protect the confidentiality and integrity can lead to disclosure of such confidential information to an unauthorized user.

In many cases threats enabled by exit points are related to the threats of the corresponding entry point. In the login example, error messages returned to the user via the exit point might allow for entry point attacks, such as account harvesting (e.g. username not found), or SQL injection (e.g. SQL exception errors).

From the defensive perspective, the identification of threats driven by security control categorization such as ASF, allows a threat analyst to focus on specific issues related to weaknesses (e.g. vulnerabilities) in security controls. Typically the process of threat identification involves going through iterative cycles where initially all the possible threats in the threat list that apply to each component are evaluated.

At the next iteration, threats are further analyzed by exploring the attack paths, the root causes (e.g. vulnerabilities, depicted as orange blocks) for the threat to be exploited, and the necessary mitigation controls (e.g. countermeasures, depicted as green blocks). A threat tree as shown in figure 2 is useful to perform such threat analysis

[[Image:Threat_Graph.gif|Figure 2: Threat Graph]]

Once common threats, vulnerabilities, and attacks are assessed, a more focused threat analysis should take in consideration use and abuse cases. By thoroughly analyzing the use scenarios, weaknesses can be identified that could lead to the realization of a threat. Abuse cases should be identified as part of the security requirement engineering activity. These abuse cases can illustrate how existing protective measures could be bypassed, or where a lack of such protection exists. A use and misuse case graph for authentication is shown in figure below:

[[Image:UseAndMisuseCase.jpg|640px|Figure 3: Use and Misuse Case]]

Finally, it is possible to bring all of this together by determining the types of threat to each component of the decomposed system. This can be done by using a threat categorization such as STRIDE or ASF, the use of threat trees to determine how the threat can be exposed by a vulnerability, and use and misuse cases to further validate the lack of a countermeasure to mitigate the threat.

To apply STRIDE to the data flow diagram items the following table can be used:

TABLE

==Ranking of Threats==
Threats can be ranked from the perspective of risk factors. By determining the risk factor posed by the various identified threats, it is possible to create a prioritized list of threats to support a risk mitigation strategy, such as deciding on which threats have to be mitigated first. Different risk factors can be used to determine which threats can be ranked as High, Medium, or Low risk. In general, threat risk models use different factors to model risks such as those shown in figure below:

[[Image:Riskfactors.JPG|Figure 3: Risk Model Factors]]

==DREAD==
In the Microsoft DREAD threat-risk ranking model, the technical risk factors for impact are Damage and Affected Users, while the ease of exploitation factors are Reproducibility, Exploitability and Discoverability. This risk factorization allows the assignment of values to the different influencing factors of a threat. To determine the ranking of a threat, the threat analyst has to answer basic questions for each factor of risk, for example:

*For Damage: How big would the damage be if the attack succeeded?
*For Reproducibility: How easy is it to reproduce an attack to work?
*For Exploitability: How much time, effort, and expertise is needed to exploit the threat?
*For Affected Users: If a threat were exploited, what percentage of users would be affected?
*For Discoverability: How easy is it for an attacker to discover this threat?

By referring to the college library website it is possible to document sample threats releated to the use cases such as:

'''Threat: Malicious user views confidential information of students, faculty members and librarians.'''
# '''Damage potential:''' Threat to reputation as well as financial and legal liability:8
# '''Reproducibility:''' Fully reproducible:10
# '''Exploitability:''' Require to be on the same subnet or have compromised a router:7
# '''Affected users:''' Affects all users:10
# '''Discoverability:''' Can be found out easily:10

Overall DREAD score: (8+10+7+10+10) / 5 = 9

In this case having 9 on a 10 point scale is certainly an high risk threat

==Generic Risk Model==
A more generic risk model takes into consideration the Likelihood (e.g. probability of an attack) and the Impact (e.g. damage potential):

'''Risk = Likelihood x Impact'''

The likelihood or probability is defined by the ease of exploitation, which mainly depends on the type of threat and the system characteristics, and by the possibility to realize a threat, which is determined by the existence of an appropriate countermeasure.

The following is a set of considerations for determining ease of exploitation:
# Can an attacker exploit this remotely?
# Does the attacker need to be authenticated?
# Can the exploit be automated?

The impact mainly depends on the damage potential and the extent of the impact, such as the number of components that are affected by a threat.

Examples to determine the damage potential are:
# Can an attacker completely take over and manipulate the system?
# Can an attacker gain administration access to the system?
# Can an attacker crash the system?
# Can the attacker obtain access to sensitive information such as secrets, PII

Examples to determine the number of components that are affected by a threat:
# How many data sources and systems can be impacted?
# How “deep” into the infrastructure can the threat agent go?

These examples help in the calculation of the overall risk values by assigning qualitative values such as High, Medium and Low to Likelihood and Impact factors. In this case, using qualitative values, rather than numeric ones like in the case of the DREAD model, help avoid the ranking becoming overly subjective.

==Countermeasure Identification==
The purpose of the countermeasure identification is to determine if there is some kind of protective measure (e.g. security control, policy measures) in place that can prevent each threat previosly identified via threat analysis from being realized. Vulnerabilities are then those threats that have no countermeasures. Since each of these threats has been categorized either with STRIDE or ASF, it is possible to find appropriate countermeasures in the application within the given category.

Provided below is a brief and limited checklist which is by no means an exhaustive list for identifying countermeasures for specific threats.

Example of countermeasures for ASF threat types are included in the following table:

<table align="center" cellspacing="1" CELLPADDING="7">
<tr bgcolor="#cccccc">
<th colspan="4" align="center">ASF Threat & Countermeasures List</th>
</tr>

<tr bgcolor="#cccccc">
<th>Threat Type</th>
<th>Countermeasure</th>
</tr>

<tr bgcolor="#cccccc">
<td>Authentication</td>
<td>
#Credentials and authentication tokens are protected with encryption in storage and transit
#Protocols are resistant to brute force, dictionary, and replay attacks
#Strong password policies are enforced
#Trusted server authentication is used instead of SQL authentication
#Passwords are stored with salted hashes
#Password resets do not reveal password hints and valid usernames
#Account lockouts do not result in a denial of service attack
</td>
</tr>

<tr bgcolor="#cccccc">
<td>Authorization</td>
<td>
#Strong ACLs are used for enforcing authorized access to resources
#Role-based access controls are used to restrict access to specific operations
#The system follows the principle of least privilege for user and service accounts
#Privilege separation is correctly configured within the presentation, business and data access layers</td>
</tr>

<tr bgcolor="#cccccc">
<td>Configuration Management</td>
<td>
#Least privileged processes are used and service accounts with no administration capability
#Auditing and logging of all administration activities is enabled
#Access to configuration files and administrator interfaces is restricted to administrators
</td>
</tr>
<tr bgcolor="#cccccc">
<td>Data Protection in Storage and Transit</td>
<td>
#Standard encryption algorithms and correct key sizes are being used
#Hashed message authentication codes (HMACs) are used to protect data integrity
#Secrets (e.g. keys, confidential data ) are cryptographically protected both in transport and in storage
#Built-in secure storage is used for protecting keys
#No credentials and sensitive data are sent in clear text over the wire
</td>
</tr>
<tr bgcolor="#cccccc">
<td>Data Validation / Parameter Validation</td>
<td>
#Data type, format, length, and range checks are enforced
#All data sent from the client is validated
#No security decision is based upon parameters (e.g. URL parameters) that can be manipulated
#Input filtering via white list validation is used
#Output encoding is used
</td>
</tr>
<tr bgcolor="#cccccc">
<td>Error Handling and Exception Management</td>
<td>
#All exceptions are handled in a structured manner
#Privileges are restored to the appropriate level in case of errors and exceptions
#Error messages are scrubbed so that no sensitive information is revealed to the attacker

</td>
</tr>
<tr bgcolor="#cccccc">
<td>User and Session Management</td>
<td>
#No sensitive information is stored in clear text in the cookie
#The contents of the authentication cookies is encrypted
#Cookies are configured to expire
#Sessions are resistant to replay attacks
#Secure communication channels are used to protect authentication cookies
#User is forced to re-authenticate when performing critical functions
#Sessions are expired at logout
</td>
</tr>
<tr bgcolor="#cccccc">
<td>Auditing and Logging</td>
<td>
#Sensitive information (e.g. passwords, PII) is not logged
#Access controls (e.g. ACLs) are enforced on log files to prevent un-authorized access
#Integrity controls (e.g. signatures) are enforced on log files to provide non-repudiation
#Log files provide for audit trail for sensitive operations and logging of key events
#Auditing and logging is enabled across the tiers on multiple servers
</td>
</tr>
</table>

When using STRIDE, the following threat-mitigation table can be used to identify techniques that can be employed to mitigate the threats.

<table align="center" cellspacing="1" CELLPADDING="7">
<tr bgcolor="#cccccc">
<th colspan="4" align="center">STRIDE Threat & Mitigation Techniques List</th>
</tr>

<tr bgcolor="#cccccc">
<th>Threat Type</th>
<th>Mitigation Techniques</th>
</tr>

<tr bgcolor="#cccccc">
<td>Spoofing Identity</td>
<td>
#Appropriate authentication
#Protect secret data
#Don't store secrets
</td>
</tr>
<tr bgcolor="#cccccc">
<td>Tampering with data</td>
<td>
#Appropriate authorization
#Hashes
#MACs
#Digital signatures
#Tamper resistant protocols
</td>
</tr>
<tr bgcolor="#cccccc">
<td>Repudiation</td>
<td>
#Digital signatures
#Timestamps
#Audit trails
</td>
</tr>
<tr bgcolor="#cccccc">
<td>Information Disclosure</td>
<td>
#Authorization
#Privacy-enhanced protocols
#Encryption
#Protect secrets
#Don't store secrets
</td>
</tr>
<tr bgcolor="#cccccc">
<td>Denial of Service</td>
<td>
#Appropriate authentication
#Appropriate authorization
#Filtering
#Throttling
#Quality of service
</td>
</tr>
<tr bgcolor="#cccccc">
<td>Elevation of privilege</td>
<td>
#Run with least privilege
</td>
</tr>
</table>

Once threats and corresponding countermeasures are identified it is possible to derive a threat profile with the following criteria:

# '''Non mitigated threats:''' Threats which have no countermeasures and represent vulnerabilities that can be fully exploited and cause an impact
# '''Partially mitigated threats:''' Threats partially mitigated by one or more countermeasures which represent vulnerabilities that can only partially be exploited and cause a limited impact
# '''Fully mitigated threats:''' These threats have appropriate countermeasures in place and do not expose vulnerability and cause impact

===Mitigation Strategies===
The objective of risk management is to reduce the impact that the exploitation of a threat can have to the application. This can be done by responding to a theat with a risk mitigation strategy. In general there are five options to mitigate threats
# '''Do nothing:''' for example, hoping for the best
# '''Inform about the risk:''' for example, warning user population about the risk
# '''Mitigate the risk:''' for example, by putting countermeasures in place
# '''Accept the risk:''' for example, after evaluating the impact of the exploitation (business impact)
# '''Transfer the risk:''' for example, through contractual agreements and insurance

The decision of which strategy is most appropriate depends on the impact an exploitation of a threat can have, the likelihood of its occurrence, and the costs for transferring (i.e. costs for insurance) or avoiding (i.e. costs or losses due redesign) it. That is, such decision is based on the risk a threat poses to the system. Therefore, the chosen strategy does not mitigate the threat itself but the risk it poses to the system. Ultimately the overall risk has to take into account the business impact, since this is a critical factor for the business risk management strategy. One strategy could be to fix only the vulnerabilities for which the cost to fix is less than the potential business impact derived by the exploitation of the vulnerability. Another strategy could be to accept the risk when the loss of some security controls (e.g. Confidentiality, Integrity, and Availability) implies a small degradation of the service, and not a loss of a critical business function. In some cases, transfer of the risk to another service provider might also be an option.

[[Category:OWASP Code Review Project]]
[[Category:Threat_Modeling]]

OWASP Code Review Project Roadmap

2012-11-15T18:48:17Z

Micheal w s mcnamee:

The project's overall goal is to...

'''be a reference document for the purpose of performing code review. This project shall provide examples in the most common web application development languages (Java and C# .NET)'''

In the near term, we are focused on the following tactical goals...

1. Looking at each attack type and examine the anti-pattern associated with the vulnerability which makes the attack possible. This shall include code examples to guide a reviewer on what to look for.

2. Looking at the code review process, how it is managed and challanges one may encounter when performing code review in the "real world".

3. Looking at the code review tools available and discussing the benefits and issues of using tools.

[[Category:OWASP Code Review Project