https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=Pawel+KrawczykOWASP - User contributions [en]2026-05-06T15:17:14ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=Talk:SameSite&diff=240433Talk:SameSite2018-05-05T15:42:12Z<p>Pawel Krawczyk: re</p>
<hr />
<div>I know browsers have implemented the SameSite attribute, but the only IETF document that defines it is draft-ietf-httpbis-rfc6265bis-02, which is expired. RFC6265 does not include the SameSite attribute. Do browsers choose to implement draft specs on their own?<br />
* It's been always the case - such minor security controls are frequently proposed and then implemented based on industry consensus, and after they're verified in the field, a RFC is created to standardize them retroactively. [[User:Pawel Krawczyk|Pawel Krawczyk]] ([[User talk:Pawel Krawczyk|talk]]) 10:42, 5 May 2018 (CDT)</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Input_Validation_Cheat_Sheet&diff=230677Input Validation Cheat Sheet2017-06-15T11:24:33Z<p>Pawel Krawczyk: /* Whitelisting vs blacklisting */ Validating free-form Unicode text=</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
This article is focused on providing clear, simple, actionable guidance for providing Input Validation security functionality in your applications. <br />
<br />
== Goals of Input Validation ==<br />
Input validation is performed to ensure only properly formed data is entering the workflow in an information system, preventing malformed data from persisting in the database and triggering malfunction of various downstream components. Input validation should happen as early as possible in the data flow, preferably as soon as the data is received from the external party. <br />
<br />
Data from all potentially untrusted sources should be subject to input validation, including not only Internet-facing web clients but also backend feeds over extranets, from suppliers, partners, vendors or regulators[https://badcyber.com/several-polish-banks-hacked-information-stolen-by-unknown-attackers/], each of which may be compromised on their own and start sending malformed data.<br />
<br />
Input Validation should not be used as the ''primary'' method of preventing [[XSS (Cross Site Scripting) Prevention Cheat Sheet|XSS]], [[SQL Injection Prevention Cheat Sheet|SQL Injection]] and other attacks which are covered in respective [[OWASP Cheat Sheet Series|cheat sheets]] but can significantly contribute to reducing their impact if implemented properly.<br />
<br />
== Input validation strategies==<br />
Input validation should be applied on both '''syntactical''' and '''semantic''' level. Syntactic validation should enforce correct syntax of structured fields (e.g. SSN, date, currency symbol) while semantic validation should enforce correctness of their ''values'' in the specific business context (e.g. start date is before end date, price is within expected range).<br />
<br />
It is always recommended to prevent attacks as early as possible in the processing of the user’s (attacker's) request. Input validation can be used to detect unauthorized input before it is processed by the application. <br />
<br />
== Implementing input validation==<br />
Input validation can be implemented using any programming technique that allows effective enforcement of syntactic and semantic correctness, for example:<br />
<br />
* Data type validators available natively in web application frameworks (such as [https://docs.djangoproject.com/en/1.11/ref/validators/ Django Validators], [https://commons.apache.org/proper/commons-validator/apidocs/org/apache/commons/validator/package-summary.html#doc.Usage.validator Apache Commons Validators] etc)<br />
* Validation against [http://json-schema.org/ JSON Schema] and [https://www.w3.org/standards/techs/xmlschema#w3c_all XML Schema (XSD)] for input in these formats<br />
* Type conversion (e.g. <code>Integer.parseInt()</code> in Java, <code>int()</code> in Python) with strict exception handling<br />
* Minimum and maximum value range check for numerical parameters and dates, minimum and maximum length check for strings<br />
* Array of allowed values for small sets of string parameters (e.g. days of week)<br />
* Regular expressions for any other structured data covering the whole input string (^...$) and '''not''' using "any character" wildcard (such as "." or "\S")<br />
<br />
=== Whitelisting vs blacklisting ===<br />
It is a common mistake black list validation in order to try to detect possibly dangerous characters and patterns like the apostrophe <code>'</code> character, the string <code>1=1</code>, or the <code>&lt;script&gt;</code> tag, but this is a massively flawed approach as it is trivial for an attacker to avoid getting caught by such filters. Plus, such filters frequently prevent authorized input, like <code>O'Brian</code>, where the ' character is fully legitimate. For more information on XSS filter evasion please see the [[XSS Filter Evasion Cheat Sheet]].<br />
<br />
White list validation is appropriate for all input fields provided by the user. White list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized. If it's well structured data, like dates, social security numbers, zip codes, e-mail addresses, etc. then the developer should be able to define a very strong validation pattern, usually based on regular expressions, for validating such input. If the input field comes from a fixed set of options, like a drop down list or radio buttons, then the input needs to match exactly one of the values offered to the user in the first place. <br />
<br />
===Validating free-form Unicode text===<br />
Free-form text, especially with Unicode characters, is perceived as difficult to validate due to a relatively large space of characters that need to be whitelisted. It's also free-form text input that highlights the importance of proper context-aware output encoding and quite clearly demonstrates that input validation is '''not''' the primary safeguards against Cross-Site Scripting — if your users want to type apostrophe (') or less-than sign (&lt;) in their comment field, they might have perfectly legitimate reason for that and the application's job is to properly handle it throughout the whole life cycle of the data.<br />
<br />
The primary means of input validation for free-form text input should be:<br />
<br />
* normalization — ensure canonical encoding is used across all the text and no invalid characters are present <br />
* character category whitelisting — Unicode allows whitelisting categories such as "decimal digits" or "letters" which not only covers the Latin alphabet but also various other scripts used globally (e.g. Arabic, Cyryllic, CJK ideographs etc)<br />
* individual character whitelisting — if you allow letters and ideographs in names and also want to allow apostrophe (') for Irish names, but don't want to allow the whole punctuation category<br />
<br />
References: [https://ipsec.pl/python/2017/input-validation-free-form-unicode-text-python.html Input validation of free-form Unicode text in Python]<br />
<br />
===Regular expressions===<br />
Developing regular expressions can be complicated, and is well beyond the scope of this cheat sheet. There are lots of resources on the internet about how to write regular expressions, including: http://www.regular-expressions.info/ and the [[OWASP Validation Regex Repository]]. <br />
<br />
In summary, input validation should:<br />
* Be applied to all input data, at minimum<br />
* Define the allowed set of characters to be accepted<br />
* Defines a minimum and maximum length for the data (e.g. {1,25} )<br />
<br />
== White List Regular Expression Examples ==<br />
<br />
Validating an U.S. Zip Code (5 digits plus optional -4) <br />
^\d{5}(-\d{4})?$<br />
<br />
Validating U.S. State Selection From a Drop-Down Menu<br />
^(AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU|<br />
HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|MO|MT|NE| <br />
NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN|<br />
TX|UT|VT|VI|VA|WA|WV|WI|WY)$<br />
<br />
'''Java Regex Usage Example'''<br />
<br />
Example validating the parameter “zip” using a regular expression.<br />
<br />
private static final Pattern zipPattern = Pattern.compile("^\d{5}(-\d{4})?$");<br />
public void doPost( HttpServletRequest request, HttpServletResponse response) {<br />
try {<br />
String zipCode = request.getParameter( "zip" );<br />
if ( !zipPattern.matcher( zipCode ).matches() {<br />
throw new YourValidationException( "Improper zipcode format." );<br />
}<br />
.. do what you want here, after its been validated ..<br />
} catch(YourValidationException e ) {<br />
response.sendError( response.SC_BAD_REQUEST, e.getMessage() );<br />
}<br />
}<br />
<br />
Some white list validators have also been predefined in various open source packages that you can leverage. For example:<br />
* [http://jakarta.apache.org/commons/validator Apache Commons Validator]<br />
<br />
== Client Side vs Server Side Validation ==<br />
Be aware that any JavaScript input validation performed on the client can be bypassed by an attacker that disables JavaScript or uses a Web Proxy. Ensure that any input validation performed on the client is also performed on the server.<br />
<br />
== Validating Rich User Content ==<br />
It is very difficult to validate rich content submitted by a user. For more information, please see the cheatsheet on [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Sanitize_HTML_Markup_with_a_Library_Designed_for_the_Job Sanitizing HTML Markup with a Library Designed for the Job].<br />
<br />
== Preventing XSS and Content Security Policy ==<br />
* All user data controlled must be encoded when returned in the html page to prevent the execution of malicious data (e.g. XSS). For example &lt;script&gt; would be returned as &amp;lt;script&amp;gt;<br />
* The type of encoding is specific to the context of the page where the user controlled data is inserted. For example, HTML entity encoding is appropriate for data placed into the HTML body. However, user data placed into a script would need JavaScript specific output encoding. <br />
<br />
Detailed information on XSS prevention here: [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet OWASP XSS Prevention Cheat Sheet]<br />
<br />
= File Upload Validation = <br />
<br />
Many websites allow users to upload files, such as a profile picture or more. This section helps provide that feature securely.<br />
<br />
==Upload Verification==<br />
<br />
* Use input validation to ensure the uploaded filename uses an expected extension type <br />
* Ensure the uploaded file is not larger than a defined maximum file size<br />
* If the website supports ZIP file upload, do validation check before unzip the file. The check includes the target path, level of compress, estimated unzip size. <br />
<br />
==Upload Storage==<br />
<br />
* Use a new filename to store the file on the OS. Do not use any user controlled text for this filename or for the temporary filename. <br />
* When the file is uploaded to web, it's suggested to rename the file on storage. For example, the uploaded filename is test.JPG, rename it to JAI1287uaisdjhf.JPG with a random file name. The purpose of doing it to prevent the risks of direct file access and ambigious filename to evalide the filter, such as test.jpg;.asp or /../../../../../test.jpg.<br />
* Uploaded files should be analyzed for malicious content (anti-malware, static analysis, etc)<br />
* The file path should not be able to specify by client side. It's decided by server side.<br />
<br />
==Public Serving of Uploaded Content==<br />
*Ensure uploaded images are served with the correct content-type (e.g. image/jpeg, application/x-xpinstall)<br />
<br />
==Beware of "special" files==<br />
* The upload feature should be using a whitelist approach to only allow specific file types and extensions. However, it is important to be aware of the following file types that, if allowed, could result in security vulnerabilities.<br />
*"crossdomain.xml" allows cross-domain data loading in Flash, Java and Silverlight. If permitted on sites with authentication this can permit cross-domain data theft and CSRF attacks. Note this can get pretty complicated depending on the specific plugin version in question, so its best to just prohibit files named "crossdomain.xml" or "clientaccesspolicy.xml".<br />
*".htaccess" and ".htpasswd" provides server configuration options on a per-directory basis, and should not be permitted. See http://en.wikipedia.org/wiki/Htaccess<br />
*Web executable script files are suggested not to be allowed such as aspx, css, swf, xhtml, rhtml, shtml, jsp, js, pl, php, cgi.<br />
<br />
==Upload Verification==<br />
*Use image rewriting libraries to verify the image is valid and to strip away extraneous content. <br />
*Set the extension of the stored image to be a valid image extension based on the detected content type of the image from image processing (e.g. do not just trust the header from the upload). <br />
*Ensure the detected content type of the image is within a list of defined image types (jpg, png, etc)<br />
<br />
= Email Address Validation =<br />
<br />
== Email Validation Basics ==<br />
<br />
Many web applications do not treat email addresses correctly due to common misconceptions about what constitutes a valid address. Specifically, it is completely valid to have an mailbox address which:<br />
* Is case sensitive in the local portion of the address (left of the rightmost @ character)<br />
* Has non-alphanumeric characters in the local-part (including + and @)<br />
* Has zero or more labels<br />
<br />
At the time of writing, RFC 5321 is the current standard defining SMTP and what constitutes a valid mailbox address. Please note, email addresses should be considered to be public data.<br />
<br />
Many web applications contain computationally expensive and inaccurate regular expressions that attempt to validate email addresses. Recent changes to the landscape mean that the number of false-negatives will increase, particularly due to:<br />
* Increased popularity of sub-addressing by providers such as Gmail (commonly using + as a token in the local-part to affect delivery)<br />
* New gTLDs with long names (many regular expressions check the number and length of each label in the domain)<br />
<br />
Following RFC 5321, best practice for validating an email address would be to:<br />
* Check for presence of at least one @ symbol in the address<br />
* Ensure the local-part is no longer than 64 octets<br />
* Ensure the domain is no longer than 255 octets<br />
* Ensure the address is deliverable<br />
<br />
To ensure an address is deliverable, the only way to check this is to send the user an email and have the user take action to confirm receipt. Beyond confirming that the email address is valid and deliverable, this also provides a positive acknowledgement that the user has access to the mailbox and is likely to be authorized to use it. This does not mean that other users cannot access this mailbox, for example when the user makes use of a service that generates a throw away email address.<br />
* Email verification links should only satisfy the requirement of verify email address ownership and should not provide the user with an authenticated session (e.g. the user must still authenticate as normal to access the application).<br />
* Email verification codes must expire after the first use or expire after 8 hours if not used.<br />
<br />
== Address Normalization ==<br />
<br />
As the local-part of email addresses are, in fact - case sensitive, it is important to store and compare email addresses correctly. To normalise an email address input, you would convert the domain part ONLY to lowercase.<br />
<br />
Unfortunately this does and will make input harder to normalise and correctly match to a users intent. It is reasonable to only accept one unique capitalisation of an otherwise identical address, however in this case it is critical to:<br />
* Store the user-part as provided and verified by user verification<br />
* Perform comparisons by lowercase(provided)==lowercase(persisted)<br />
<br />
= Authors and Primary Editors =<br />
<br />
Dave Wichers - dave.wichers [at] aspectsecurity.com<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Talk:Cryptographic_Storage_Cheat_Sheet&diff=229756Talk:Cryptographic Storage Cheat Sheet2017-05-17T12:25:17Z<p>Pawel Krawczyk: 3DES</p>
<hr />
<div>I take issue with these two rules:<br />
<br />
Rule - Build support for changing keys periodically<br />
Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).<br />
<br />
<br />
It is definitely a good thing for a system to have a built-in method for key rotation, when needed. What I take issue with is framing this as a "periodic" necessity. Changing out well-chosen encryption keys used for data storage on a periodic basis is almost certainly a waste of time and effort. Yes, if a key is compromised for whatever reason then we need to change it quickly when we find out about that, but blindly doing it on a monthly, quarterly, or whatever basis still exposes the data to attack 50% of the time. See more below.<br />
<br />
Rule - Rekey data at least every one to three years[edit]<br />
Rekeying refers to the process of decrypting data and then re-encrypting it with a new key. Periodically rekeying data helps protect it from undetected compromises of older keys. The appropriate rekeying <br />
period depends on the security of the keys. Data protected by keys secured in dedicated hardware security modules might only need rekeying every three years. Data protected by keys that are split and stored on two application servers might need rekeying every year.<br />
<br />
<br />
Suppose a breach happens on the 10th of the month, but you normally rotate keys on the 25th. If you didn't find out about the breach until the 30th, then that is 15 days for the attacker to export the whole encrypted database and begin cracking it offline. What's more, after you automatically rotate the encryption keys for data at rest, the attacker *still has the data encrypted with the old key*. So they can just continue cracking offline. What did periodic key rotation buy you? The more you analyze this problem with a real threat model, the more you realize it buys you nothing.<br />
<br />
Yes, sysadmins do need a way to rotate keys quickly after they discover they were compromised. But blindly rotating on a periodic basis just to make you feel better is a waste of time, when it comes to encryption of data at rest. (Encryption in transit can be a different story.) "But it doesn't hurt, right?" Well, actually it does. People could spend that effort on useful things, rather than on building and testing periodic key rotation systems.<br />
<br />
==3DES==<br />
Should we still even mention 3DES? [[User:Pawel Krawczyk|Pawel Krawczyk]] ([[User talk:Pawel Krawczyk|talk]]) 07:25, 17 May 2017 (CDT)</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Cryptographic_Storage_Cheat_Sheet&diff=229753Cryptographic Storage Cheat Sheet2017-05-17T10:44:34Z<p>Pawel Krawczyk: /* Rule - Use strong random numbers */ what to use instead for C and Java</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
This article provides a simple model to follow when implementing solutions to protect data at rest.<br> <br />
<br />
== Architectural Decision ==<br />
<br />
An architectural decision must be made to determine the appropriate method to protect data at rest. There are such wide varieties of products, methods and mechanisms for cryptographic storage. This cheat sheet will only focus on low-level guidelines for developers and architects who are implementing cryptographic solutions. We will not address specific vendor solutions, nor will we address the design of cryptographic algorithms.<br />
<br />
The general practices and required minimum key length depending on the scenario listed below.<br />
<br />
* Key exchange: Diffie–Hellman key exchange with minimum 2048 bits<br />
* Message Integrity: HMAC-SHA2<br />
* Message Hash: SHA2 256 bits<br />
* Assymetric encryption: RSA 2048 bits<br />
* Symmetric-key algorithm: AES 128 bits<br />
* Password Hashing: PBKDF2, Scrypt, Bcrypt.<br />
<br />
= Providing Cryptographic Functionality =<br />
<br />
== Secure Cryptographic Storage Design ==<br />
<br />
* All protocols and algorithms for authentication and secure communication should be well vetted by the cryptographic community.<br />
<br />
* Ensure certificates are properly validated against the hostnames/users ie whom they are meant for.<br />
<br />
* Avoid using wildcard certificates unless there is a business need for it <br />
<br />
* Maintain a cryptographic standard to ensure that the developer community knows about the approved ciphersuits for network security protocols, algorithms, permitted use, cryptoperiods and Key Management<br />
<br />
<br />
=== Rule - Only store sensitive data that you need ===<br />
<br />
Many eCommerce businesses utilize third party payment providers to store credit card information for recurring billing. This offloads the burden of keeping credit card numbers safe.<br />
<br />
=== Rule - Use strong approved Authenticated Encryption ===<br />
E.g. [http://en.wikipedia.org/wiki/CCM_mode CCM] or [http://en.wikipedia.org/wiki/GCM_mode GCM] are approved [http://en.wikipedia.org/wiki/Authenticated_encryption Authenticated Encryption] modes based on [http://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES] algorithm.<br />
<br />
==== Rule - Use strong approved cryptographic algorithms ====<br />
Do not implement an existing cryptographic algorithm on your own, no matter how easy it appears. Instead, use widely accepted algorithms and widely accepted implementations. <br />
<br />
Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 or SHA1. Avoid hashing for password storage, instead use PBKDF2, bcrypt or scrypt. Note that the classification of a "strong" cryptographic algorithm can change over time. See [http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf NIST approved algorithms] or ISO TR 14742 “Recommendations on Cryptographic Algorithms and their use” or [http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-size-and-parameters-report-2014/at_download/fullReport Algorithms, key size and parameters report – 2014] from European Union Agency for Network and Information Security. <br />
E.g. [http://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES] 128, [http://en.wikipedia.org/wiki/RSA_(cryptosystem) RSA] 3072, [http://en.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] 256. <br />
<br />
Ensure that the implementation has (at minimum) had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified. <br />
<br />
See [http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf NIST approved algorithms] Table 2 “Comparable strengths” for the strength (“security bits”) of different algorithms and key lengths, and how they compare to each other. <br />
<br />
* In general, where different algorithms are used, they should have comparable strengths e.g. if an AES-128 key is to be encrypted, an AES-128 key or greater, or RSA-3072 or greater could be used to encrypt it. <br />
* In general, hash lengths are twice as long as the security bits offered by the symmetric/asymmetric algorithm&nbsp; e.g. SHA-224 for 3TDEA (112 security bits) (due to the [http://en.wikipedia.org/wiki/Birthday_attack Birthday Attack])<br />
<br />
If a password is being used to protect keys then the [http://en.wikipedia.org/wiki/Password_strength password strength]should be sufficient for the strength of the keys it is protecting.<br />
<br />
When 3DES is used, ensure K1 != K2 != K3, and the minimum key length must be 192 bit.<br />
<br />
==== Rule - Use approved cryptographic modes ====<br />
In general, you should not use AES, DES or other symmetric cipher primitives directly. [http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html NIST approved modes] should be used instead. <br />
<br />
NOTE: Do not use [http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 ECB mode] for encrypting lots of data (the other modes are better because they chain the blocks of data together to improve the data security).<br />
<br />
==== Rule - Use strong random numbers ====<br />
Ensure that all random numbers, especially those used for cryptographic parameters (keys, IV’s, MAC tags), random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion. <br />
<br />
Ensure that random algorithms are seeded with sufficient entropy.<br />
<br />
Tools like [http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html NIST RNG Test tool] (as used in PCI PTS Derived Test Requirements) can be used to comprehensively assess the quality of a Random Number Generator by reading e.g. 128MB of data from the RNG source and then assessing its randomness properties with the tool.<br />
<br />
The following libraries are considered '''weak''' random numbers generators and should not be used.<br />
<br />
* C library: <code>random()</code>, <code>rand()</code> — use [http://man7.org/linux/man-pages/man2/getrandom.2.html getrandom(2)] instead<br />
* Java library: <code>java.util.Random()</code> — use <code>java.security.SecureRandom</code> instead<br />
<br />
For secure random number generation, refer to NIST SP 800-90A. CTR-DRBG、HASH-DRBG、HMAC-DRBG are recommended.<br />
Refer to NIST SP800-22 A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications, and the testing toolkit.<br />
<br />
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-22r1a.pdf<br />
http://csrc.nist.gov/groups/ST/toolkit/rng/documents/sts-2.1.2.zip<br />
<br />
==== Rule - Use Authenticated Encryption of data ====<br />
Use ([http://en.wikipedia.org/wiki/Authenticated_encryption AE]) modes under a uniform API. Recommended modes include [http://en.wikipedia.org/wiki/CCM_mode CCM], and [http://en.wikipedia.org/wiki/Galois/Counter_Mode GCM] as these, and only these as of November 2014, are specified in [http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html NIST approved modes], ISO IEC 19772 (2009) "Information technology — Security techniques — Authenticated encryption", and [http://en.wikipedia.org/wiki/IEEE_P1619 IEEE P1619 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices] <br />
<br />
* [http://en.wikipedia.org/wiki/Authenticated_encryption Authenticated Encryption] gives [http://en.wikipedia.org/wiki/Confidentiality confidentiality],&nbsp;[http://en.wikipedia.org/wiki/Data_integrity integrity], and&nbsp;[http://en.wikipedia.org/wiki/Authentication authenticity] (CIA); encryption alone just gives confidentiality. Encryption must always be combined with message integrity and authenticity protection. Otherwise the ciphertext may be vulnerable to manipulation causing changes to the underlying plaintext data, especially if it's being passed over untrusted channels (e.g. in an URL or cookie). <br />
* These modes require only one key. In general, the tag sizes and the IV sizes should be set to maximum values.<br />
<br />
If these recommended [http://en.wikipedia.org/wiki/Authenticated_encryption AE] modes are not available<br />
<br />
* combine encryption in [http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_chaining_.28CBC.29 cipher-block chaining (CBC) mode] with post-encryption message authentication code, such as [http://en.wikipedia.org/wiki/HMAC HMAC] or [http://en.wikipedia.org/wiki/CMAC CMAC] i.e. Encrypt-then-MAC. <br />
** Note that Integrity and Authenticity are preferable to Integrity alone i.e. a MAC such as HMAC-SHA256 or HMAC-SHA512 is a better choice than SHA-256 or SHA-512.<br />
* Use 2 independent keys for these 2 independent operations. <br />
* Do not use ECB mode. CDC is preferred.<br />
* Do not use [http://en.wikipedia.org/wiki/CBC-MAC#Security_with_fixed_and_variable-length_messages CBC MAC for variable length data] <br />
* The [http://csrc.nist.gov/groups/STM/cavp/index.html CAVP program] is a good default place to go for validation of cryptographic algorithms when one does not have AES or one of the authenticated encryption modes that provide confidentiality and authenticity (i.e., data origin authentication) such as CCM, EAX, CMAC, etc. For Java, if you are using SunJCE that will be the case. The cipher modes supported in JDK 1.5 and later are CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC. None of these cipher modes are authenticated encryption modes. (That's why it is added explicitly.) If you are using an alternate JCE provider such as Bouncy Castle, RSA JSafe, IAIK, etc., then these authenticated encryption modes should be used.<br />
<br />
Note: [http://en.wikipedia.org/wiki/Disk_encryption_theory Disk encryption]&nbsp;is a special case of&nbsp;[http://en.wikipedia.org/wiki/Data_at_Rest data at rest]&nbsp;e.g. Encrypted File System on a Hard Disk Drive. [http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf XTS-AES mode] is optimized for Disk encryption and is one of the [http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html NIST approved modes]<nowiki>; it provides confidentiality and some protection against data manipulation (but not as strong as the </nowiki>[http://en.wikipedia.org/wiki/Authenticated_encryption AE] [http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html NIST approved modes]). It is also specified in [http://en.wikipedia.org/wiki/IEEE_P1619 IEEE P1619 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices]<br />
<br />
=== Rule - Store a one-way and salted value of passwords ===<br />
<br />
Use PBKDF2, bcrypt or scrypt for password storage. For more information on password storage, please see the [[Password Storage Cheat Sheet]].<br />
<br />
=== Rule - Ensure that the cryptographic protection remains secure even if access controls fail ===<br />
<br />
This rule supports the principle of defense in depth. Access controls (usernames, passwords, privileges, etc.) are one layer of protection. Storage encryption should add an additional layer of protection that will continue protecting the data even if an attacker subverts the database access control layer.<br />
<br />
=== Rule - Ensure that any secret key is protected from unauthorized access ===<br />
<br />
==== Rule - Define a key lifecycle ====<br />
<br />
The key lifecycle details the various states that a key will move through during its life. The lifecycle will specify when a key should no longer be used for encryption, when a key should no longer be used for decryption (these are not necessarily coincident), whether data must be rekeyed when a new key is introduced, and when a key should be removed from use all together.<br />
<br />
==== Rule - Store unencrypted keys away from the encrypted data ====<br />
<br />
If the keys are stored with the data then any compromise of the data will easily compromise the keys as well. Unencrypted keys should never reside on the same machine or cluster as the data.<br />
<br />
==== Rule - Use independent keys when multiple keys are required ====<br />
<br />
Ensure that key material is independent. That is, do not choose a second key which is easily related to the first (or any preceeding) keys.<br />
<br />
==== Rule - Protect keys in a key vault ====<br />
<br />
Keys should remain in a protected key vault at all times. In particular, ensure that there is a gap between the threat vectors that have direct access to the data and the threat vectors that have direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).<br />
<br />
==== Rule - Document concrete procedures for managing keys through the lifecycle ====<br />
<br />
These procedures must be written down and the key custodians must be adequately trained.<br />
<br />
==== Rule - Build support for changing algorithms and keys when needed ====<br />
<br />
If keys are compromised or an external authority expires them, key changes will be needed. Application polices or emergency needs will force application administrators to rotate keys and potentially rekey data at some point. It's best to be prepared to rapidly handle this need when necessary. Including a key version and encryption algorithm version with the encrypted data is a useful, proactive feature. For instance, including a simple prefix string, such as "<code>{1,1}...</code>", prior to the encrypted data could indicate algorithm version 1, key version 1. This allows for an "online" change to the encryption algorithm and key without re-encrypting all existing data all at once.<br />
<br />
==== Rule - Document concrete procedures to handle a key compromise ====<br />
<br />
Ensure operations staff have the information they need, readily available, when rotation of encryption keys must be performed. Rotating keys should not require changes to source code or other risky deployment measures, since doing this in the middle of an incident will already place a great deal of stress on these staff.<br />
<br />
==== Rule - Limit quantity of data encrypted with one key ====<br />
<br />
If the amount of data encrypted grows beyond a '''certain threshold''', a new key should be used. This '''certain threshold''' varies depending on the encryption algorithm used, but is typically 2<sup>35</sup> bytes (~34 gigabytes) for 64 bit block ciphers (DES, 3DES, Blowfish, RC5, ...) and 2<sup>68</sup> bytes (~ 295,147,905 terabytes) for 128 bit block ciphers (AES, TwoFish, Serpent). If encrypting with a modern cipher, this threshold is unlikely to be reached, but it should be considered when evaluating algorithms and rotation procedures.<br />
<br />
=== Rule - Follow applicable regulations on use of cryptography ===<br />
<br />
==== Rule - Under PCI DSS requirement 3, you must protect cardholder data ====<br />
<br />
The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The standard was introduced in 2005 and replaced individual compliance standards from Visa, Mastercard, Amex, JCB and Diners. The current version of the standard is 3.1 and was published in April, 2015. <br />
<br />
PCI DSS requirement 3 covers secure storage of credit card data. This requirement covers several aspects of secure storage including the data you must never store but we are covering Cryptographic Storage which is covered in requirements 3.4, 3.5 and 3.6 as you can see below: <br />
<br />
'''3.4 Render PAN (Primary Account Number), at minimum, unreadable anywhere it is stored''' <br />
<br />
Compliance with requirement 3.4 can be met by implementing any of the four types of secure storage described in the standard which includes encrypting and hashing data. These two approaches will often be the most popular choices from the list of options. The standard doesn't refer to any specific algorithms but it mandates the use of '''Strong Cryptography'''. The glossary document from the PCI council defines '''Strong Cryptography''' as: <br />
<br />
''Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).'' <br />
<br />
If you have implemented the second rule in this cheat sheet you will have implemented a strong cryptographic algorithm which is compliant with or stronger than the requirements of PCI DSS requirement 3.4. You need to ensure that you identify all locations that card data could be stored including logs and apply the appropriate level of protection. This could range from encrypting the data to replacing the card number in logs. <br />
<br />
This requirement can also be met by implementing disk encryption rather than file or column level encryption. The requirements for '''Strong Cryptography''' are the same for disk encryption and backup media. The card data should never be stored in the clear and by following the guidance in this cheat sheet you will be able to securely store your data in a manner which is compliant with PCI DSS requirement 3.4 <br />
<br />
'''3.5 Protect any keys used to secure cardholder data against disclosure and misuse''' <br />
<br />
As the requirement name above indicates, we are required to securely store the encryption keys themselves. This will mean implementing strong access control, auditing and logging for your keys. The keys must be stored in a location which is both secure and "away" from the encrypted data. This means key data shouldn't be stored on web servers, database servers etc <br />
<br />
Access to the keys must be restricted to the smallest amount of users possible. This group of users will ideally be users who are highly trusted and trained to perform Key Custodian duties. There will obviously be a requirement for system/service accounts to access the key data to perform encryption/decryption of data. <br />
<br />
The keys themselves shouldn't be stored in the clear but encrypted with a KEK (Key Encrypting Key). The KEK must not be stored in the same location as the encryption keys it is encrypting. <br />
<br />
'''3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data''' <br />
<br />
Requirement 3.6 mandates that key management processes within a PCI compliant company cover 8 specific key lifecycle steps: <br />
<br />
'''3.6.1 Generation of strong cryptographic keys''' <br />
<br />
As we have previously described in this cheat sheet we need to use algorithms which offer high levels of data security. We must also generate strong keys so that the security of the data isn't undermined by weak cryptographic keys. A strong key is generated by using a key length which is sufficient for your data security requirements and compliant with the PCI DSS. The key size alone isn't a measure of the strength of a key. The data used to generate the key must be sufficiently random ("sufficient" often being determined by your data security requirements) and the entropy of the key data itself must be high.<br> <br />
<br />
'''3.6.2 Secure cryptographic key distribution''' <br />
<br />
The method used to distribute keys must be secure to prevent the theft of keys in transit. The use of a protocol such as Diffie Hellman can help secure the distribution of keys, the use of secure transport such as TLS and SSHv2 can also secure the keys in transit. Older protocols like SSLv3 should not be used.<br> <br />
<br />
'''3.6.3 Secure cryptographic key storage'''<br />
<br />
The secure storage of encryption keys including KEK's has been touched on in our description of requirement 3.5 (see above).<br />
<br />
'''3.6.4 Periodic cryptographic key changes'''<br />
<br />
The PCI DSS standard mandates that keys used for encryption must be rotated at least annually. The key rotation process must remove an old key from the encryption/decryption process and replace it with a new key. All new data entering the system must encrypted with the new key. While it is recommended that existing data be rekeyed with the new key, as per the Rekey data at least every one to three years rule above, it is not clear that the PCI DSS requires this.<br />
<br />
'''3.6.5 Retirement or replacement of keys as deemed necessary when the integrity of the key has been weakened or keys are suspected of being compromised'''<br />
<br />
The key management processes must cater for archived, retired or compromised keys. The process of securely storing and replacing these keys will more than likely be covered by your processes for requirements 3.6.2, 3.6.3 and 3.6.4<br />
<br />
'''3.6.6 Split knowledge and establishment of dual control of cryptographic keys'''<br />
<br />
The requirement for split knowledge and/or dual control for key management prevents an individual user performing key management tasks such as key rotation or deletion. The system should require two individual users to perform an action (i.e. entering a value from their own OTP) which creates to separate values which are concatenated to create the final key data.<br />
<br />
'''3.6.7 Prevention of unauthorized substitution of cryptographic keys'''<br />
<br />
The system put in place to comply with requirement 3.6.6 can go a long way to preventing unauthorised substitution of key data. In addition to the dual control process you should implement strong access control, auditing and logging for key data so that unauthorised access attempts are prevented and logged.<br />
<br />
'''3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities '''<br />
<br />
To perform the strong key management functions we have seen in requirement 3.6 we must have highly trusted and trained key custodians who understand how to perform key management duties. The key custodians must also sign a form stating they understand the responsibilities that come with this role.<br />
<br />
= Related Articles =<br />
<br />
OWASP - [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]] <br />
<br />
OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]<br />
ssllabs Wiki - https://github.com/ssllabs/research/wiki<br />
<br />
OWASP - https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet<br />
<br />
= Authors and Primary Editors =<br />
<br />
Kevin Kenan - kevin[at]k2dd.com<br/><br />
David Rook - david.a.rook[at]gmail.com<br/><br />
Kevin Wall - kevin.w.wall[at]gmail.com<br/><br />
Jim Manico - jim[at]owasp.org<br/><br />
Fred Donovan - fred.donovan(at)owasp.org <br/><br />
Tony Hsu - hsiang_chih[at]yahoo.com<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=SAML_Security_Cheat_Sheet&diff=229751SAML Security Cheat Sheet2017-05-17T09:51:02Z<p>Pawel Krawczyk: /* Input Validation */ strong encryption</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The <i>Security Assertion Markup Language</i> (SAML) is an open standard for exchanging authorization and authentication information. The <i>Web Browser SAML/SSO Profile with Redirect/POST bindings</i> is one of the most common SSO implementation. This cheatsheet will focus primarily on that profile.<br />
<br />
<br />
= Validate Message Confidentiality and Integrity =<br />
<br />
* [[Transport Layer Protection Cheat Sheet|TLS 1.2]] is the most common solution to guarantee message confidentiality and integrity. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security (section 4)] for additional information. This step will help counter the following attacks:<br />
** Eavesdropping 7.1.1.1<br />
** Theft of User Authentication Information 7.1.1.2<br />
** Theft of the Bearer Token 7.1.1.3<br />
** Message Deletion 7.1.1.6<br />
** Message Modification 7.1.1.7<br />
** Man-in-the-middle 7.1.1.8<br />
*A digitally signed message with a certified key is the most common solution to guarantee message integrity and authentication. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security (section 4)] for additional information. This step will help counter the following attacks:<br />
**Man-in-the-middle 6.4.2<br />
**Forged Assertion 6.4.3<br />
<br />
<br />
=Validate Protocol Usage=<br />
<br />
This is a common area for security gaps - see [http://www.ai-lab.it/armando/pub/fmse9-armando.pdf Google SSO vulnerability] (AVANTSSAR 2008) for a real life example. Their SSO profile was vulnerable to a Man-in-the-middle attack from a malicious SP (Service Provider). The SSO Web Browser Profile is most susceptible to attacks from trusted partners. This particular security flaw was exposed because the SAML Response did not contain all of the required data elements necessary for a secure message exchange. Following the [http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profile] usage requirements for AuthnRequest (4.1.4.1) and Response (4.1.4.2) will help counter this attack. The AVANTSSAR team suggested the following data elements should be required:<br />
<br />
* '''AuthnRequest(ID, SP);''' An AuthnRequest must contain and ID and SP. Where ID is a string uniquely identifying the request and an SP identifies the Service Provider that initiated the request. Furthermore, the request ID attribute must be returned in the response (InResponseTo="<requestId>"). InResponseTo helps guarantee authenticity of the response from the trusted IdP. This was one of the missing attributes that left Google's SSO vulnerable.<br />
* '''Response(ID, SP, IdP, {AA} K -1/IdP);''' A Response must contain all these elements. Where ID is a string uniquely identifying the response. SP identifies the recipient of the response. IdP identifies the identity provider authorizing the response. {AA} K -1/IdP is the assertion digitally signed with the private key of the IdP.<br />
* '''AuthAssert(ID, C, IdP, SP);''' An authentication assertion must exist within the Response. It must contain an ID, a client (C), an identity provider (IdP), and a service provider (SP) identifier.<br />
<br />
Further vulnerabilities in SAML implementations were described in 2012 ([https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91-8-23-12.pdf On Breaking SAML: Be Whoever You Want to Be]). The following recommendations were proposed in response ([http://arxiv.org/pdf/1401.7483v1.pdf Secure SAML validation to prevent XML signature wrapping attacks]):<br />
<br />
* Always perform schema validation on the XML document prior to using it for any security-related purposes.<br />
** Always use local, trusted copies of schemas for validation.<br />
** Never allow automatic download of schemas from third party locations.<br />
** If possible, inspect schemas and perform schema hardening, to disable possible wildcard type or relaxed processing statements.<br />
* Securely validate the digital signature.<br />
** If you expect only one signing key, use StaticKeySelector. Obtain the key directly from the identity provider, store it in local file and ignore any KeyInfo elements in the document.<br />
** If you expect more than one signing key, use X509KeySelector (the JKS variant). Obtain these keys directly form the identity providers, store them in local JKS and ignore any KeyInfo elements in the document.<br />
** If you expect a heterogenous signed documents (many certificates from many identity providers, multilevel validation paths), implement full trust establishment model based on PKIX and trusted root certificates.<br />
* Avoid signature-wrapping attacks.<br />
** Never use getElementsByTagName to select security related elements in an XML document without prior validation.<br />
**Always use absolute XPath expressions to select elements, unless a hardened schema is used for validation.<br />
<br />
<br />
=Validate Protocol Processing Rules=<br />
<br />
This is another common area for security gaps simply because of the vast number of steps to assert. Processing a SAML response is an expensive operation but all steps must be validated.<br />
*Validate AuthnRequest processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf SAML Core] (3.4.1.4) for all AuthnRequest processing rules. This step will help counter the following attacks:<br />
** Man-in-the-middle (6.4.2)<br />
* Validate Response processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profiles] (4.1.4.3) for all Response processing rules. This step will help counter the following attacks:<br />
** Stolen Assertion (6.4.1)<br />
** Man-in-the-middle (6.4.2)<br />
** Forged Assertion (6.4.3)<br />
** Browser State Exposure (6.4.4)<br />
<br />
<br />
=Validate Binding Implementation=<br />
<br />
*For an HTTP Redirect Binding refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf SAML Binding] (3.4). To view an encoding example, you may want to reference RequestUtil.java found within [https://developers.google.com/google-apps/sso/saml_reference_implementation_web Google's reference implementation].<br />
* For an HTTP POST Binding refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf SAML Binding] (3.5). The caching considerations are also very important. If a SAML protocol message gets cached, it can subsequently be used as a Stolen Assertion (6.4.1) or Replay (6.4.5) attack.<br />
<br />
<br />
=Validate Security Countermeasures=<br />
<br />
Revisit each security threat that exists within the [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security] document and assert you have applied the appropriate countermeasures for threats that may exist for your particular implementation. Additional countermeasures considererd should include:<br />
*Prefer IP Filtering when appropriate. For example, this countermeasure could have prevented Google's initial security flaw if Google provided each trusted partner with a separate endpoint and setup an IP filter for each endpoint. This step will help counter the following attacks:<br />
**Stolen Assertion (6.4.1)<br />
**Man-in-the-middle (6.4.2)<br />
*Prefer short lifetimes on the SAML Response. This step will help counter the following attacks:<br />
**Stolen Assertion (6.4.1)<br />
**Browser State Exposure (6.4.4)<br />
*Prefer OneTimeUse on the SAML Response. This step will help counter the following attacks:<br />
**Browser State Exposure (6.4.4)<br />
**Replay (6.4.5)<br />
<br />
Need an architectural diagram? The [http://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf SAML technical overview] contains the most complete diagrams. For the Web Browser SSO Profile with Redirect/POST bindings refer to the section 4.1.3. In fact, of all the SAML documentation, the technical overview is the most valuable from a high-level perspective.<br />
<br />
<br />
= First and Last Mile Considerations = <br />
<br />
The SAML protocol is rarely the vector of choice, though it's important to have cheatsheets to make sure that this is robust. The various endpoints are more targeted, so how the SAML token is generated and how it is consumed are both important in practice. <br />
<br />
== First Mile Considerations ==<br />
* Validate X.509 Certificate for algorithm compatibility, strength of encryption, export restrictions<br />
* Validate Strong Authentication options for generating the SAML token<br />
* IDP validation (which IDP mints the token)<br />
* Use/Trust Root CAs whenever possible<br />
* Synchronize to a common Internet timesource<br />
* Define levels of assurance for identity verification<br />
* Prefer asymmetric identifiers for identity assertions over personally identifiable information (e.g. SSNs, etc)<br />
* Sign assertions whenever possible<br />
<br />
== Last Mile Considerations ==<br />
* Validating session state for user<br />
* Level of granularity in setting authZ context when consuming SAML token (do you use groups, roles, attributes)<br />
* Validate authorized IDP<br />
* Validate IDP certificates for expiry against CRL/OCSP<br />
* Validate NotBefore and NotOnorAfter<br />
* Define criteria for SAML logout<br />
* Exchange assertions only over secure transports<br />
* Define criteria for session management<br />
* Validate signature whenever possible<br />
* Verify user identities obtained from SAML ticket assertions whenever possible.<br />
<br />
= Input Validation =<br />
<br />
Just because SAML is a security protocol does not mean that input validation goes away. <br />
<br />
* Ensure that all SAML providers/consumers do proper [[Input_Validation_Cheat_Sheet | input validation]].<br />
<br />
= Cryptography =<br />
Solutions relying cryptographic algorithms need to follow the latest developments in cryptoanalysis.<br />
<br />
* Ensure all SAML elements in the chain use [[Cryptographic_Storage_Cheat_Sheet#Rule_-_Use_strong_approved_Authenticated_Encryption|strong encryption]]<br />
<br />
= Authors and Primary Editors =<br />
<br />
* [http://bradbroulik.blogspot.dk/2010/01/bulletproof-sso-with-saml-20.html Brad Broulik]<br />
* [https://ipsec.pl/ Paweł Krawczyk]<br />
* Gunnar Peterson<br />
* James McGovern<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Input_Validation_Cheat_Sheet&diff=229696Input Validation Cheat Sheet2017-05-16T12:35:09Z<p>Pawel Krawczyk: restructure a bit</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
This article is focused on providing clear, simple, actionable guidance for providing Input Validation security functionality in your applications. <br />
<br />
== Goals of Input Validation ==<br />
Input validation is performed to ensure only properly formed data is entering the workflow in an information system, preventing malformed data from persisting in the database and triggering malfunction of various downstream components. Input validation should happen as early as possible in the data flow, preferably as soon as the data is received from the external party. <br />
<br />
Data from all potentially untrusted sources should be subject to input validation, including not only Internet-facing web clients but also backend feeds over extranets, from suppliers, partners, vendors or regulators[https://badcyber.com/several-polish-banks-hacked-information-stolen-by-unknown-attackers/], each of which may be compromised on their own and start sending malformed data.<br />
<br />
Input Validation should not be used as the ''primary'' method of preventing [[XSS (Cross Site Scripting) Prevention Cheat Sheet|XSS]], [[SQL Injection Prevention Cheat Sheet|SQL Injection]] and other attacks which are covered in respective [[OWASP Cheat Sheet Series|cheat sheets]] but can significantly contribute to reducing their impact if implemented properly.<br />
<br />
== Input validation strategies==<br />
Input validation should be applied on both '''syntactical''' and '''semantic''' level. Syntactic validation should enforce correct syntax of structured fields (e.g. SSN, date, currency symbol) while semantic validation should enforce correctness of their ''values'' in the specific business context (e.g. start date is before end date, price is within expected range).<br />
<br />
It is always recommended to prevent attacks as early as possible in the processing of the user’s (attacker's) request. Input validation can be used to detect unauthorized input before it is processed by the application. <br />
<br />
== Implementing input validation==<br />
Input validation can be implemented using any programming technique that allows effective enforcement of syntactic and semantic correctness, for example:<br />
<br />
* Data type validators available natively in web application frameworks (such as [https://docs.djangoproject.com/en/1.11/ref/validators/ Django Validators], [https://commons.apache.org/proper/commons-validator/apidocs/org/apache/commons/validator/package-summary.html#doc.Usage.validator Apache Commons Validators] etc)<br />
* Validation against [http://json-schema.org/ JSON Schema] and [https://www.w3.org/standards/techs/xmlschema#w3c_all XML Schema (XSD)] for input in these formats<br />
* Type conversion (e.g. <code>Integer.parseInt()</code> in Java, <code>int()</code> in Python) with strict exception handling<br />
* Minimum and maximum value range check for numerical parameters and dates, minimum and maximum length check for strings<br />
* Array of allowed values for small sets of string parameters (e.g. days of week)<br />
* Regular expressions for any other structured data covering the whole input string (^...$) and '''not''' using "any character" wildcard (such as "." or "\S")<br />
<br />
=== Whitelisting vs blacklisting ===<br />
It is a common mistake black list validation in order to try to detect possibly dangerous characters and patterns like the apostrophe <code>'</code> character, the string <code>1=1</code>, or the <code>&lt;script&gt;</code> tag, but this is a massively flawed approach as it is trivial for an attacker to avoid getting caught by such filters. Plus, such filters frequently prevent authorized input, like <code>O'Brian</code>, where the ' character is fully legitimate. For more information on XSS filter evasion please see the [[XSS Filter Evasion Cheat Sheet]].<br />
<br />
White list validation is appropriate for all input fields provided by the user. White list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized. If it's well structured data, like dates, social security numbers, zip codes, e-mail addresses, etc. then the developer should be able to define a very strong validation pattern, usually based on regular expressions, for validating such input. If the input field comes from a fixed set of options, like a drop down list or radio buttons, then the input needs to match exactly one of the values offered to the user in the first place. <br />
<br />
The most difficult fields to validate are so called 'free text' fields, like blog entries. However, even those types of fields can be validated to some degree. For example, you can at least exclude all non-printable characters (except acceptable white space, e.g., CR, LF, tab, space), and define a maximum length for the input field.<br />
<br />
===Regular expressions===<br />
Developing regular expressions can be complicated, and is well beyond the scope of this cheat sheet. There are lots of resources on the internet about how to write regular expressions, including: http://www.regular-expressions.info/ and the [[OWASP Validation Regex Repository]]. <br />
<br />
In summary, input validation should:<br />
* Be applied to all input data, at minimum<br />
* Define the allowed set of characters to be accepted<br />
* Defines a minimum and maximum length for the data (e.g. {1,25} )<br />
<br />
== White List Regular Expression Examples ==<br />
<br />
Validating an U.S. Zip Code (5 digits plus optional -4) <br />
^\d{5}(-\d{4})?$<br />
<br />
Validating U.S. State Selection From a Drop-Down Menu<br />
^(AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU|<br />
HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|MO|MT|NE| <br />
NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN|<br />
TX|UT|VT|VI|VA|WA|WV|WI|WY)$<br />
<br />
'''Java Regex Usage Example'''<br />
<br />
Example validating the parameter “zip” using a regular expression.<br />
<br />
private static final Pattern zipPattern = Pattern.compile("^\d{5}(-\d{4})?$");<br />
public void doPost( HttpServletRequest request, HttpServletResponse response) {<br />
try {<br />
String zipCode = request.getParameter( "zip" );<br />
if ( !zipPattern.matcher( zipCode ).matches() {<br />
throw new YourValidationException( "Improper zipcode format." );<br />
}<br />
.. do what you want here, after its been validated ..<br />
} catch(YourValidationException e ) {<br />
response.sendError( response.SC_BAD_REQUEST, e.getMessage() );<br />
}<br />
}<br />
<br />
Some white list validators have also been predefined in various open source packages that you can leverage. For example:<br />
* [http://jakarta.apache.org/commons/validator Apache Commons Validator]<br />
<br />
== Client Side vs Server Side Validation ==<br />
Be aware that any JavaScript input validation performed on the client can be bypassed by an attacker that disables JavaScript or uses a Web Proxy. Ensure that any input validation performed on the client is also performed on the server.<br />
<br />
== Validating Rich User Content ==<br />
It is very difficult to validate rich content submitted by a user. For more information, please see the cheatsheet on [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Sanitize_HTML_Markup_with_a_Library_Designed_for_the_Job Sanitizing HTML Markup with a Library Designed for the Job].<br />
<br />
== Preventing XSS and Content Security Policy ==<br />
* All user data controlled must be encoded when returned in the html page to prevent the execution of malicious data (e.g. XSS). For example &lt;script&gt; would be returned as &amp;lt;script&amp;gt;<br />
* The type of encoding is specific to the context of the page where the user controlled data is inserted. For example, HTML entity encoding is appropriate for data placed into the HTML body. However, user data placed into a script would need JavaScript specific output encoding. <br />
<br />
Detailed information on XSS prevention here: [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet OWASP XSS Prevention Cheat Sheet]<br />
<br />
= File Upload Validation = <br />
<br />
Many websites allow users to upload files, such as a profile picture or more. This section helps provide that feature securely.<br />
<br />
==Upload Verification==<br />
<br />
* Use input validation to ensure the uploaded filename uses an expected extension type <br />
* Ensure the uploaded file is not larger than a defined maximum file size<br />
* If the website supports ZIP file upload, do validation check before unzip the file. The check includes the target path, level of compress, estimated unzip size. <br />
<br />
==Upload Storage==<br />
<br />
* Use a new filename to store the file on the OS. Do not use any user controlled text for this filename or for the temporary filename. <br />
* When the file is uploaded to web, it's suggested to rename the file on storage. For example, the uploaded filename is test.JPG, rename it to JAI1287uaisdjhf.JPG with a random file name. The purpose of doing it to prevent the risks of direct file access and ambigious filename to evalide the filter, such as test.jpg;.asp or /../../../../../test.jpg.<br />
* Uploaded files should be analyzed for malicious content (anti-malware, static analysis, etc)<br />
* The file path should not be able to specify by client side. It's decided by server side.<br />
<br />
==Public Serving of Uploaded Content==<br />
*Ensure uploaded images are served with the correct content-type (e.g. image/jpeg, application/x-xpinstall)<br />
<br />
==Beware of "special" files==<br />
* The upload feature should be using a whitelist approach to only allow specific file types and extensions. However, it is important to be aware of the following file types that, if allowed, could result in security vulnerabilities.<br />
*"crossdomain.xml" allows cross-domain data loading in Flash, Java and Silverlight. If permitted on sites with authentication this can permit cross-domain data theft and CSRF attacks. Note this can get pretty complicated depending on the specific plugin version in question, so its best to just prohibit files named "crossdomain.xml" or "clientaccesspolicy.xml".<br />
*".htaccess" and ".htpasswd" provides server configuration options on a per-directory basis, and should not be permitted. See http://en.wikipedia.org/wiki/Htaccess<br />
*Web executable script files are suggested not to be allowed such as aspx, css, swf, xhtml, rhtml, shtml, jsp, js, pl, php, cgi.<br />
<br />
==Upload Verification==<br />
*Use image rewriting libraries to verify the image is valid and to strip away extraneous content. <br />
*Set the extension of the stored image to be a valid image extension based on the detected content type of the image from image processing (e.g. do not just trust the header from the upload). <br />
*Ensure the detected content type of the image is within a list of defined image types (jpg, png, etc)<br />
<br />
= Email Address Validation =<br />
<br />
== Email Validation Basics ==<br />
<br />
Many web applications do not treat email addresses correctly due to common misconceptions about what constitutes a valid address. Specifically, it is completely valid to have an mailbox address which:<br />
* Is case sensitive in the local portion of the address (left of the rightmost @ character)<br />
* Has non-alphanumeric characters in the local-part (including + and @)<br />
* Has zero or more labels<br />
<br />
At the time of writing, RFC 5321 is the current standard defining SMTP and what constitutes a valid mailbox address. Please note, email addresses should be considered to be public data.<br />
<br />
Many web applications contain computationally expensive and inaccurate regular expressions that attempt to validate email addresses. Recent changes to the landscape mean that the number of false-negatives will increase, particularly due to:<br />
* Increased popularity of sub-addressing by providers such as Gmail (commonly using + as a token in the local-part to affect delivery)<br />
* New gTLDs with long names (many regular expressions check the number and length of each label in the domain)<br />
<br />
Following RFC 5321, best practice for validating an email address would be to:<br />
* Check for presence of at least one @ symbol in the address<br />
* Ensure the local-part is no longer than 64 octets<br />
* Ensure the domain is no longer than 255 octets<br />
* Ensure the address is deliverable<br />
<br />
To ensure an address is deliverable, the only way to check this is to send the user an email and have the user take action to confirm receipt. Beyond confirming that the email address is valid and deliverable, this also provides a positive acknowledgement that the user has access to the mailbox and is likely to be authorized to use it. This does not mean that other users cannot access this mailbox, for example when the user makes use of a service that generates a throw away email address.<br />
* Email verification links should only satisfy the requirement of verify email address ownership and should not provide the user with an authenticated session (e.g. the user must still authenticate as normal to access the application).<br />
* Email verification codes must expire after the first use or expire after 8 hours if not used.<br />
<br />
== Address Normalization ==<br />
<br />
As the local-part of email addresses are, in fact - case sensitive, it is important to store and compare email addresses correctly. To normalise an email address input, you would convert the domain part ONLY to lowercase.<br />
<br />
Unfortunately this does and will make input harder to normalise and correctly match to a users intent. It is reasonable to only accept one unique capitalisation of an otherwise identical address, however in this case it is critical to:<br />
* Store the user-part as provided and verified by user verification<br />
* Perform comparisons by lowercase(provided)==lowercase(persisted)<br />
<br />
= Authors and Primary Editors =<br />
<br />
Dave Wichers - dave.wichers [at] aspectsecurity.com<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Input_Validation_Cheat_Sheet&diff=229692Input Validation Cheat Sheet2017-05-16T10:19:47Z<p>Pawel Krawczyk: Implementing input validation</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
This article is focused on providing clear, simple, actionable guidance for providing Input Validation security functionality in your applications. <br />
<br />
== Goals of Input Validation ==<br />
Input validation is performed to ensure only properly formed data is entering the workflow in an information system, preventing malformed data from persisting in the database and triggering malfunction of various downstream components.<br />
<br />
Input Validation is not the ''primary'' method of preventing [[XSS (Cross Site Scripting) Prevention Cheat Sheet|XSS]], [[SQL Injection Prevention Cheat Sheet|SQL Injection]] and other attacks which are covered in respective [[OWASP Cheat Sheet Series|cheat sheets]] but can significantly contribute to reducing their impact if implemented properly.<br />
<br />
== Input validation strategies==<br />
Input validation should be applied on both '''syntactical''' and '''semantic''' level. Syntactic validation should enforce correct syntax of structured fields (e.g. SSN, date, currency symbol) while semantic validation should enforce correctness of their ''values'' in the specific business context (e.g. start date is before end date, price is within expected range).<br />
<br />
== Implementing input validation==<br />
Input validation can be implemented using any programming technique that allows effective enforcement of syntactic and semantic correctness, for example:<br />
<br />
* Data type validators available natively in web application frameworks (such as [https://docs.djangoproject.com/en/1.11/ref/validators/ Django Validators], [https://commons.apache.org/proper/commons-validator/apidocs/org/apache/commons/validator/package-summary.html#doc.Usage.validator Apache Commons Validators] etc)<br />
* Validation against [http://json-schema.org/ JSON Schema] and [https://www.w3.org/standards/techs/xmlschema#w3c_all XML Schema (XSD)] for input in these formats<br />
* Type conversion (e.g. <code>Integer.parseInt()</code> in Java, <code>int()</code> in Python) with strict exception handling<br />
* Minimum and maximum value range check for numerical parameters and dates, minimum and maximum length check for strings<br />
* Array of allowed values for small sets of string parameters (e.g. days of week)<br />
* Regular expressions for any other structured data covering the whole input string (^...$) and '''not''' using "any character" wildcard (such as "." or "\S")<br />
<br />
== White List Input Validation ==<br />
<br />
It is always recommended to prevent attacks as early as possible in the processing of the user’s (attacker's) request. Input validation can be used to detect unauthorized input before it is processed by the application. Developers frequently perform black list validation in order to try to detect attack characters and patterns like the ' character, the string 1=1, or the &lt;script&gt; tag, but this is a massively flawed approach as it is typically trivial for an attacker to avoid getting caught by such filters. Plus, such filters frequently prevent authorized input, like O'Brian, when the ' character is being filtered out. For more information on XSS filter evasion please see the [[XSS Filter Evasion Cheat Sheet]].<br />
<br />
White list validation is appropriate for all input fields provided by the user. White list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized. If it's well structured data, like dates, social security numbers, zip codes, e-mail addresses, etc. then the developer should be able to define a very strong validation pattern, usually based on regular expressions, for validating such input. If the input field comes from a fixed set of options, like a drop down list or radio buttons, then the input needs to match exactly one of the values offered to the user in the first place. The most difficult fields to validate are so called 'free text' fields, like blog entries. However, even those types of fields can be validated to some degree. For example, you can at least exclude all non-printable characters (except acceptable white space, e.g., CR, LF, tab, space), and define a maximum length for the input field.<br />
<br />
Developing regular expressions can be complicated, and is well beyond the scope of this cheat sheet. There are lots of resources on the internet about how to write regular expressions, including: http://www.regular-expressions.info/ and the [[OWASP Validation Regex Repository]]. <br />
<br />
In summary, input validation should:<br />
* Be applied to all input data, at minimum<br />
* Define the allowed set of characters to be accepted<br />
* Defines a minimum and maximum length for the data (e.g. {1,25} )<br />
<br />
== White List Regular Expression Examples ==<br />
<br />
Validating an U.S. Zip Code (5 digits plus optional -4) <br />
^\d{5}(-\d{4})?$<br />
<br />
Validating U.S. State Selection From a Drop-Down Menu<br />
^(AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU|<br />
HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|MO|MT|NE| <br />
NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN|<br />
TX|UT|VT|VI|VA|WA|WV|WI|WY)$<br />
<br />
'''Java Regex Usage Example'''<br />
<br />
Example validating the parameter “zip” using a regular expression.<br />
<br />
private static final Pattern zipPattern = Pattern.compile("^\d{5}(-\d{4})?$");<br />
public void doPost( HttpServletRequest request, HttpServletResponse response) {<br />
try {<br />
String zipCode = request.getParameter( "zip" );<br />
if ( !zipPattern.matcher( zipCode ).matches() {<br />
throw new YourValidationException( "Improper zipcode format." );<br />
}<br />
.. do what you want here, after its been validated ..<br />
} catch(YourValidationException e ) {<br />
response.sendError( response.SC_BAD_REQUEST, e.getMessage() );<br />
}<br />
}<br />
<br />
Some white list validators have also been predefined in various open source packages that you can leverage. For example:<br />
* [http://jakarta.apache.org/commons/validator Apache Commons Validator]<br />
<br />
== Client Side vs Server Side Validation ==<br />
Be aware that any JavaScript input validation performed on the client can be bypassed by an attacker that disables JavaScript or uses a Web Proxy. Ensure that any input validation performed on the client is also performed on the server.<br />
<br />
== Validating Rich User Content ==<br />
It is very difficult to validate rich content submitted by a user. For more information, please see the cheatsheet on [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Sanitize_HTML_Markup_with_a_Library_Designed_for_the_Job Sanitizing HTML Markup with a Library Designed for the Job].<br />
<br />
== Preventing XSS and Content Security Policy ==<br />
* All user data controlled must be encoded when returned in the html page to prevent the execution of malicious data (e.g. XSS). For example &lt;script&gt; would be returned as &amp;lt;script&amp;gt;<br />
* The type of encoding is specific to the context of the page where the user controlled data is inserted. For example, HTML entity encoding is appropriate for data placed into the HTML body. However, user data placed into a script would need JavaScript specific output encoding. <br />
<br />
Detailed information on XSS prevention here: [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet OWASP XSS Prevention Cheat Sheet]<br />
<br />
= File Upload Validation = <br />
<br />
Many websites allow users to upload files, such as a profile picture or more. This section helps provide that feature securely.<br />
<br />
==Upload Verification==<br />
<br />
* Use input validation to ensure the uploaded filename uses an expected extension type <br />
* Ensure the uploaded file is not larger than a defined maximum file size<br />
* If the website supports ZIP file upload, do validation check before unzip the file. The check includes the target path, level of compress, estimated unzip size. <br />
<br />
==Upload Storage==<br />
<br />
* Use a new filename to store the file on the OS. Do not use any user controlled text for this filename or for the temporary filename. <br />
* When the file is uploaded to web, it's suggested to rename the file on storage. For example, the uploaded filename is test.JPG, rename it to JAI1287uaisdjhf.JPG with a random file name. The purpose of doing it to prevent the risks of direct file access and ambigious filename to evalide the filter, such as test.jpg;.asp or /../../../../../test.jpg.<br />
* Uploaded files should be analyzed for malicious content (anti-malware, static analysis, etc)<br />
* The file path should not be able to specify by client side. It's decided by server side.<br />
<br />
==Public Serving of Uploaded Content==<br />
*Ensure uploaded images are served with the correct content-type (e.g. image/jpeg, application/x-xpinstall)<br />
<br />
==Beware of "special" files==<br />
* The upload feature should be using a whitelist approach to only allow specific file types and extensions. However, it is important to be aware of the following file types that, if allowed, could result in security vulnerabilities.<br />
*"crossdomain.xml" allows cross-domain data loading in Flash, Java and Silverlight. If permitted on sites with authentication this can permit cross-domain data theft and CSRF attacks. Note this can get pretty complicated depending on the specific plugin version in question, so its best to just prohibit files named "crossdomain.xml" or "clientaccesspolicy.xml".<br />
*".htaccess" and ".htpasswd" provides server configuration options on a per-directory basis, and should not be permitted. See http://en.wikipedia.org/wiki/Htaccess<br />
*Web executable script files are suggested not to be allowed such as aspx, css, swf, xhtml, rhtml, shtml, jsp, js, pl, php, cgi.<br />
<br />
==Upload Verification==<br />
*Use image rewriting libraries to verify the image is valid and to strip away extraneous content. <br />
*Set the extension of the stored image to be a valid image extension based on the detected content type of the image from image processing (e.g. do not just trust the header from the upload). <br />
*Ensure the detected content type of the image is within a list of defined image types (jpg, png, etc)<br />
<br />
= Email Address Validation =<br />
<br />
== Email Validation Basics ==<br />
<br />
Many web applications do not treat email addresses correctly due to common misconceptions about what constitutes a valid address. Specifically, it is completely valid to have an mailbox address which:<br />
* Is case sensitive in the local portion of the address (left of the rightmost @ character)<br />
* Has non-alphanumeric characters in the local-part (including + and @)<br />
* Has zero or more labels<br />
<br />
At the time of writing, RFC 5321 is the current standard defining SMTP and what constitutes a valid mailbox address. Please note, email addresses should be considered to be public data.<br />
<br />
Many web applications contain computationally expensive and inaccurate regular expressions that attempt to validate email addresses. Recent changes to the landscape mean that the number of false-negatives will increase, particularly due to:<br />
* Increased popularity of sub-addressing by providers such as Gmail (commonly using + as a token in the local-part to affect delivery)<br />
* New gTLDs with long names (many regular expressions check the number and length of each label in the domain)<br />
<br />
Following RFC 5321, best practice for validating an email address would be to:<br />
* Check for presence of at least one @ symbol in the address<br />
* Ensure the local-part is no longer than 64 octets<br />
* Ensure the domain is no longer than 255 octets<br />
* Ensure the address is deliverable<br />
<br />
To ensure an address is deliverable, the only way to check this is to send the user an email and have the user take action to confirm receipt. Beyond confirming that the email address is valid and deliverable, this also provides a positive acknowledgement that the user has access to the mailbox and is likely to be authorized to use it. This does not mean that other users cannot access this mailbox, for example when the user makes use of a service that generates a throw away email address.<br />
* Email verification links should only satisfy the requirement of verify email address ownership and should not provide the user with an authenticated session (e.g. the user must still authenticate as normal to access the application).<br />
* Email verification codes must expire after the first use or expire after 8 hours if not used.<br />
<br />
== Address Normalization ==<br />
<br />
As the local-part of email addresses are, in fact - case sensitive, it is important to store and compare email addresses correctly. To normalise an email address input, you would convert the domain part ONLY to lowercase.<br />
<br />
Unfortunately this does and will make input harder to normalise and correctly match to a users intent. It is reasonable to only accept one unique capitalisation of an otherwise identical address, however in this case it is critical to:<br />
* Store the user-part as provided and verified by user verification<br />
* Perform comparisons by lowercase(provided)==lowercase(persisted)<br />
<br />
= Authors and Primary Editors =<br />
<br />
Dave Wichers - dave.wichers [at] aspectsecurity.com<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Input_Validation_Cheat_Sheet&diff=229628Input Validation Cheat Sheet2017-05-15T13:17:02Z<p>Pawel Krawczyk: /* Goal of Input Validation */</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
This article is focused on providing clear, simple, actionable guidance for providing Input Validation security functionality in your applications. <br />
<br />
== Goal of Input Validation ==<br />
Input validation is performed to ensure only properly formed data is entering the workflow in an information system, preventing malformed data from persisting in the database and triggering malfunction of various downstream components.<br />
<br />
Input Validation is not the ''primary'' method of preventing [[XSS (Cross Site Scripting) Prevention Cheat Sheet|XSS]], [[SQL Injection Prevention Cheat Sheet|SQL Injection]] and other attacks which are covered in respective [[OWASP Cheat Sheet Series|cheat sheets]] but can significantly contribute to reducing their impact if implemented properly.<br />
<br />
== White List Input Validation ==<br />
<br />
It is always recommended to prevent attacks as early as possible in the processing of the user’s (attacker's) request. Input validation can be used to detect unauthorized input before it is processed by the application. Developers frequently perform black list validation in order to try to detect attack characters and patterns like the ' character, the string 1=1, or the &lt;script&gt; tag, but this is a massively flawed approach as it is typically trivial for an attacker to avoid getting caught by such filters. Plus, such filters frequently prevent authorized input, like O'Brian, when the ' character is being filtered out. For more information on XSS filter evasion please see the [[XSS Filter Evasion Cheat Sheet]].<br />
<br />
White list validation is appropriate for all input fields provided by the user. White list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized. If it's well structured data, like dates, social security numbers, zip codes, e-mail addresses, etc. then the developer should be able to define a very strong validation pattern, usually based on regular expressions, for validating such input. If the input field comes from a fixed set of options, like a drop down list or radio buttons, then the input needs to match exactly one of the values offered to the user in the first place. The most difficult fields to validate are so called 'free text' fields, like blog entries. However, even those types of fields can be validated to some degree. For example, you can at least exclude all non-printable characters (except acceptable white space, e.g., CR, LF, tab, space), and define a maximum length for the input field.<br />
<br />
Developing regular expressions can be complicated, and is well beyond the scope of this cheat sheet. There are lots of resources on the internet about how to write regular expressions, including: http://www.regular-expressions.info/ and the [[OWASP Validation Regex Repository]]. <br />
<br />
In summary, input validation should:<br />
* Be applied to all input data, at minimum<br />
* Define the allowed set of characters to be accepted<br />
* Defines a minimum and maximum length for the data (e.g. {1,25} )<br />
<br />
== White List Regular Expression Examples ==<br />
<br />
Validating an U.S. Zip Code (5 digits plus optional -4) <br />
^\d{5}(-\d{4})?$<br />
<br />
Validating U.S. State Selection From a Drop-Down Menu<br />
^(AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU|<br />
HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|MO|MT|NE| <br />
NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN|<br />
TX|UT|VT|VI|VA|WA|WV|WI|WY)$<br />
<br />
'''Java Regex Usage Example'''<br />
<br />
Example validating the parameter “zip” using a regular expression.<br />
<br />
private static final Pattern zipPattern = Pattern.compile("^\d{5}(-\d{4})?$");<br />
public void doPost( HttpServletRequest request, HttpServletResponse response) {<br />
try {<br />
String zipCode = request.getParameter( "zip" );<br />
if ( !zipPattern.matcher( zipCode ).matches() {<br />
throw new YourValidationException( "Improper zipcode format." );<br />
}<br />
.. do what you want here, after its been validated ..<br />
} catch(YourValidationException e ) {<br />
response.sendError( response.SC_BAD_REQUEST, e.getMessage() );<br />
}<br />
}<br />
<br />
Some white list validators have also been predefined in various open source packages that you can leverage. For example:<br />
* [http://jakarta.apache.org/commons/validator Apache Commons Validator]<br />
<br />
== Client Side vs Server Side Validation ==<br />
Be aware that any JavaScript input validation performed on the client can be bypassed by an attacker that disables JavaScript or uses a Web Proxy. Ensure that any input validation performed on the client is also performed on the server.<br />
<br />
== Validating Rich User Content ==<br />
It is very difficult to validate rich content submitted by a user. For more information, please see the cheatsheet on [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Sanitize_HTML_Markup_with_a_Library_Designed_for_the_Job Sanitizing HTML Markup with a Library Designed for the Job].<br />
<br />
== Preventing XSS and Content Security Policy ==<br />
* All user data controlled must be encoded when returned in the html page to prevent the execution of malicious data (e.g. XSS). For example &lt;script&gt; would be returned as &amp;lt;script&amp;gt;<br />
* The type of encoding is specific to the context of the page where the user controlled data is inserted. For example, HTML entity encoding is appropriate for data placed into the HTML body. However, user data placed into a script would need JavaScript specific output encoding. <br />
<br />
Detailed information on XSS prevention here: [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet OWASP XSS Prevention Cheat Sheet]<br />
<br />
= File Upload Validation = <br />
<br />
Many websites allow users to upload files, such as a profile picture or more. This section helps provide that feature securely.<br />
<br />
==Upload Verification==<br />
<br />
* Use input validation to ensure the uploaded filename uses an expected extension type <br />
* Ensure the uploaded file is not larger than a defined maximum file size<br />
* If the website supports ZIP file upload, do validation check before unzip the file. The check includes the target path, level of compress, estimated unzip size. <br />
<br />
==Upload Storage==<br />
<br />
* Use a new filename to store the file on the OS. Do not use any user controlled text for this filename or for the temporary filename. <br />
* When the file is uploaded to web, it's suggested to rename the file on storage. For example, the uploaded filename is test.JPG, rename it to JAI1287uaisdjhf.JPG with a random file name. The purpose of doing it to prevent the risks of direct file access and ambigious filename to evalide the filter, such as test.jpg;.asp or /../../../../../test.jpg.<br />
* Uploaded files should be analyzed for malicious content (anti-malware, static analysis, etc)<br />
* The file path should not be able to specify by client side. It's decided by server side.<br />
<br />
==Public Serving of Uploaded Content==<br />
*Ensure uploaded images are served with the correct content-type (e.g. image/jpeg, application/x-xpinstall)<br />
<br />
==Beware of "special" files==<br />
* The upload feature should be using a whitelist approach to only allow specific file types and extensions. However, it is important to be aware of the following file types that, if allowed, could result in security vulnerabilities.<br />
*"crossdomain.xml" allows cross-domain data loading in Flash, Java and Silverlight. If permitted on sites with authentication this can permit cross-domain data theft and CSRF attacks. Note this can get pretty complicated depending on the specific plugin version in question, so its best to just prohibit files named "crossdomain.xml" or "clientaccesspolicy.xml".<br />
*".htaccess" and ".htpasswd" provides server configuration options on a per-directory basis, and should not be permitted. See http://en.wikipedia.org/wiki/Htaccess<br />
*Web executable script files are suggested not to be allowed such as aspx, css, swf, xhtml, rhtml, shtml, jsp, js, pl, php, cgi.<br />
<br />
==Upload Verification==<br />
*Use image rewriting libraries to verify the image is valid and to strip away extraneous content. <br />
*Set the extension of the stored image to be a valid image extension based on the detected content type of the image from image processing (e.g. do not just trust the header from the upload). <br />
*Ensure the detected content type of the image is within a list of defined image types (jpg, png, etc)<br />
<br />
= Email Address Validation =<br />
<br />
== Email Validation Basics ==<br />
<br />
Many web applications do not treat email addresses correctly due to common misconceptions about what constitutes a valid address. Specifically, it is completely valid to have an mailbox address which:<br />
* Is case sensitive in the local portion of the address (left of the rightmost @ character)<br />
* Has non-alphanumeric characters in the local-part (including + and @)<br />
* Has zero or more labels<br />
<br />
At the time of writing, RFC 5321 is the current standard defining SMTP and what constitutes a valid mailbox address. Please note, email addresses should be considered to be public data.<br />
<br />
Many web applications contain computationally expensive and inaccurate regular expressions that attempt to validate email addresses. Recent changes to the landscape mean that the number of false-negatives will increase, particularly due to:<br />
* Increased popularity of sub-addressing by providers such as Gmail (commonly using + as a token in the local-part to affect delivery)<br />
* New gTLDs with long names (many regular expressions check the number and length of each label in the domain)<br />
<br />
Following RFC 5321, best practice for validating an email address would be to:<br />
* Check for presence of at least one @ symbol in the address<br />
* Ensure the local-part is no longer than 64 octets<br />
* Ensure the domain is no longer than 255 octets<br />
* Ensure the address is deliverable<br />
<br />
To ensure an address is deliverable, the only way to check this is to send the user an email and have the user take action to confirm receipt. Beyond confirming that the email address is valid and deliverable, this also provides a positive acknowledgement that the user has access to the mailbox and is likely to be authorized to use it. This does not mean that other users cannot access this mailbox, for example when the user makes use of a service that generates a throw away email address.<br />
* Email verification links should only satisfy the requirement of verify email address ownership and should not provide the user with an authenticated session (e.g. the user must still authenticate as normal to access the application).<br />
* Email verification codes must expire after the first use or expire after 8 hours if not used.<br />
<br />
== Address Normalization ==<br />
<br />
As the local-part of email addresses are, in fact - case sensitive, it is important to store and compare email addresses correctly. To normalise an email address input, you would convert the domain part ONLY to lowercase.<br />
<br />
Unfortunately this does and will make input harder to normalise and correctly match to a users intent. It is reasonable to only accept one unique capitalisation of an otherwise identical address, however in this case it is critical to:<br />
* Store the user-part as provided and verified by user verification<br />
* Perform comparisons by lowercase(provided)==lowercase(persisted)<br />
<br />
= Authors and Primary Editors =<br />
<br />
Dave Wichers - dave.wichers [at] aspectsecurity.com<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Input_Validation_Cheat_Sheet&diff=229627Input Validation Cheat Sheet2017-05-15T13:13:49Z<p>Pawel Krawczyk: /* Goal of Input Validation */ update, internal links</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
This article is focused on providing clear, simple, actionable guidance for providing Input Validation security functionality in your applications. <br />
<br />
== Goal of Input Validation ==<br />
Input validation is performed to ensure only properly formed data is entering the workflow in an information system, preventing malformed data from persisting in the database and triggering malfunction of various downstream components.<br />
<br />
Input Validation is not the *primary* method of preventing [[XSS (Cross Site Scripting) Prevention Cheat Sheet|XSS]], [[SQL Injection Prevention Cheat Sheet|SQL Injection]] and other attacks which are covered in respective [[OWASP Cheat Sheet Series|cheat sheets]] but can significantly contribute to reducing their impact if implemented properly.<br />
<br />
== White List Input Validation ==<br />
<br />
It is always recommended to prevent attacks as early as possible in the processing of the user’s (attacker's) request. Input validation can be used to detect unauthorized input before it is processed by the application. Developers frequently perform black list validation in order to try to detect attack characters and patterns like the ' character, the string 1=1, or the &lt;script&gt; tag, but this is a massively flawed approach as it is typically trivial for an attacker to avoid getting caught by such filters. Plus, such filters frequently prevent authorized input, like O'Brian, when the ' character is being filtered out. For more information on XSS filter evasion please see the [[XSS Filter Evasion Cheat Sheet]].<br />
<br />
White list validation is appropriate for all input fields provided by the user. White list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized. If it's well structured data, like dates, social security numbers, zip codes, e-mail addresses, etc. then the developer should be able to define a very strong validation pattern, usually based on regular expressions, for validating such input. If the input field comes from a fixed set of options, like a drop down list or radio buttons, then the input needs to match exactly one of the values offered to the user in the first place. The most difficult fields to validate are so called 'free text' fields, like blog entries. However, even those types of fields can be validated to some degree. For example, you can at least exclude all non-printable characters (except acceptable white space, e.g., CR, LF, tab, space), and define a maximum length for the input field.<br />
<br />
Developing regular expressions can be complicated, and is well beyond the scope of this cheat sheet. There are lots of resources on the internet about how to write regular expressions, including: http://www.regular-expressions.info/ and the [[OWASP Validation Regex Repository]]. <br />
<br />
In summary, input validation should:<br />
* Be applied to all input data, at minimum<br />
* Define the allowed set of characters to be accepted<br />
* Defines a minimum and maximum length for the data (e.g. {1,25} )<br />
<br />
== White List Regular Expression Examples ==<br />
<br />
Validating an U.S. Zip Code (5 digits plus optional -4) <br />
^\d{5}(-\d{4})?$<br />
<br />
Validating U.S. State Selection From a Drop-Down Menu<br />
^(AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU|<br />
HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|MO|MT|NE| <br />
NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN|<br />
TX|UT|VT|VI|VA|WA|WV|WI|WY)$<br />
<br />
'''Java Regex Usage Example'''<br />
<br />
Example validating the parameter “zip” using a regular expression.<br />
<br />
private static final Pattern zipPattern = Pattern.compile("^\d{5}(-\d{4})?$");<br />
public void doPost( HttpServletRequest request, HttpServletResponse response) {<br />
try {<br />
String zipCode = request.getParameter( "zip" );<br />
if ( !zipPattern.matcher( zipCode ).matches() {<br />
throw new YourValidationException( "Improper zipcode format." );<br />
}<br />
.. do what you want here, after its been validated ..<br />
} catch(YourValidationException e ) {<br />
response.sendError( response.SC_BAD_REQUEST, e.getMessage() );<br />
}<br />
}<br />
<br />
Some white list validators have also been predefined in various open source packages that you can leverage. For example:<br />
* [http://jakarta.apache.org/commons/validator Apache Commons Validator]<br />
<br />
== Client Side vs Server Side Validation ==<br />
Be aware that any JavaScript input validation performed on the client can be bypassed by an attacker that disables JavaScript or uses a Web Proxy. Ensure that any input validation performed on the client is also performed on the server.<br />
<br />
== Validating Rich User Content ==<br />
It is very difficult to validate rich content submitted by a user. For more information, please see the cheatsheet on [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Sanitize_HTML_Markup_with_a_Library_Designed_for_the_Job Sanitizing HTML Markup with a Library Designed for the Job].<br />
<br />
== Preventing XSS and Content Security Policy ==<br />
* All user data controlled must be encoded when returned in the html page to prevent the execution of malicious data (e.g. XSS). For example &lt;script&gt; would be returned as &amp;lt;script&amp;gt;<br />
* The type of encoding is specific to the context of the page where the user controlled data is inserted. For example, HTML entity encoding is appropriate for data placed into the HTML body. However, user data placed into a script would need JavaScript specific output encoding. <br />
<br />
Detailed information on XSS prevention here: [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet OWASP XSS Prevention Cheat Sheet]<br />
<br />
= File Upload Validation = <br />
<br />
Many websites allow users to upload files, such as a profile picture or more. This section helps provide that feature securely.<br />
<br />
==Upload Verification==<br />
<br />
* Use input validation to ensure the uploaded filename uses an expected extension type <br />
* Ensure the uploaded file is not larger than a defined maximum file size<br />
* If the website supports ZIP file upload, do validation check before unzip the file. The check includes the target path, level of compress, estimated unzip size. <br />
<br />
==Upload Storage==<br />
<br />
* Use a new filename to store the file on the OS. Do not use any user controlled text for this filename or for the temporary filename. <br />
* When the file is uploaded to web, it's suggested to rename the file on storage. For example, the uploaded filename is test.JPG, rename it to JAI1287uaisdjhf.JPG with a random file name. The purpose of doing it to prevent the risks of direct file access and ambigious filename to evalide the filter, such as test.jpg;.asp or /../../../../../test.jpg.<br />
* Uploaded files should be analyzed for malicious content (anti-malware, static analysis, etc)<br />
* The file path should not be able to specify by client side. It's decided by server side.<br />
<br />
==Public Serving of Uploaded Content==<br />
*Ensure uploaded images are served with the correct content-type (e.g. image/jpeg, application/x-xpinstall)<br />
<br />
==Beware of "special" files==<br />
* The upload feature should be using a whitelist approach to only allow specific file types and extensions. However, it is important to be aware of the following file types that, if allowed, could result in security vulnerabilities.<br />
*"crossdomain.xml" allows cross-domain data loading in Flash, Java and Silverlight. If permitted on sites with authentication this can permit cross-domain data theft and CSRF attacks. Note this can get pretty complicated depending on the specific plugin version in question, so its best to just prohibit files named "crossdomain.xml" or "clientaccesspolicy.xml".<br />
*".htaccess" and ".htpasswd" provides server configuration options on a per-directory basis, and should not be permitted. See http://en.wikipedia.org/wiki/Htaccess<br />
*Web executable script files are suggested not to be allowed such as aspx, css, swf, xhtml, rhtml, shtml, jsp, js, pl, php, cgi.<br />
<br />
==Upload Verification==<br />
*Use image rewriting libraries to verify the image is valid and to strip away extraneous content. <br />
*Set the extension of the stored image to be a valid image extension based on the detected content type of the image from image processing (e.g. do not just trust the header from the upload). <br />
*Ensure the detected content type of the image is within a list of defined image types (jpg, png, etc)<br />
<br />
= Email Address Validation =<br />
<br />
== Email Validation Basics ==<br />
<br />
Many web applications do not treat email addresses correctly due to common misconceptions about what constitutes a valid address. Specifically, it is completely valid to have an mailbox address which:<br />
* Is case sensitive in the local portion of the address (left of the rightmost @ character)<br />
* Has non-alphanumeric characters in the local-part (including + and @)<br />
* Has zero or more labels<br />
<br />
At the time of writing, RFC 5321 is the current standard defining SMTP and what constitutes a valid mailbox address. Please note, email addresses should be considered to be public data.<br />
<br />
Many web applications contain computationally expensive and inaccurate regular expressions that attempt to validate email addresses. Recent changes to the landscape mean that the number of false-negatives will increase, particularly due to:<br />
* Increased popularity of sub-addressing by providers such as Gmail (commonly using + as a token in the local-part to affect delivery)<br />
* New gTLDs with long names (many regular expressions check the number and length of each label in the domain)<br />
<br />
Following RFC 5321, best practice for validating an email address would be to:<br />
* Check for presence of at least one @ symbol in the address<br />
* Ensure the local-part is no longer than 64 octets<br />
* Ensure the domain is no longer than 255 octets<br />
* Ensure the address is deliverable<br />
<br />
To ensure an address is deliverable, the only way to check this is to send the user an email and have the user take action to confirm receipt. Beyond confirming that the email address is valid and deliverable, this also provides a positive acknowledgement that the user has access to the mailbox and is likely to be authorized to use it. This does not mean that other users cannot access this mailbox, for example when the user makes use of a service that generates a throw away email address.<br />
* Email verification links should only satisfy the requirement of verify email address ownership and should not provide the user with an authenticated session (e.g. the user must still authenticate as normal to access the application).<br />
* Email verification codes must expire after the first use or expire after 8 hours if not used.<br />
<br />
== Address Normalization ==<br />
<br />
As the local-part of email addresses are, in fact - case sensitive, it is important to store and compare email addresses correctly. To normalise an email address input, you would convert the domain part ONLY to lowercase.<br />
<br />
Unfortunately this does and will make input harder to normalise and correctly match to a users intent. It is reasonable to only accept one unique capitalisation of an otherwise identical address, however in this case it is critical to:<br />
* Store the user-part as provided and verified by user verification<br />
* Perform comparisons by lowercase(provided)==lowercase(persisted)<br />
<br />
= Authors and Primary Editors =<br />
<br />
Dave Wichers - dave.wichers [at] aspectsecurity.com<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Input_Validation_Cheat_Sheet&diff=229626Input Validation Cheat Sheet2017-05-15T12:54:09Z<p>Pawel Krawczyk: /* White List Regular Expression Examples */ US zip code</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
This article is focused on providing clear, simple, actionable guidance for providing Input Validation security functionality in your applications. <br />
<br />
== Goal of Input Validation ==<br />
Input validation is performed to minimize malformed data from entering the system. Input Validation is NOT the primary method of preventing XSS, SQL Injection. These are covered in output encoding and related cheat sheets.<br />
<br />
== White List Input Validation ==<br />
<br />
It is always recommended to prevent attacks as early as possible in the processing of the user’s (attacker's) request. Input validation can be used to detect unauthorized input before it is processed by the application. Developers frequently perform black list validation in order to try to detect attack characters and patterns like the ' character, the string 1=1, or the &lt;script&gt; tag, but this is a massively flawed approach as it is typically trivial for an attacker to avoid getting caught by such filters. Plus, such filters frequently prevent authorized input, like O'Brian, when the ' character is being filtered out. For more information on XSS filter evasion please see the [[XSS Filter Evasion Cheat Sheet]].<br />
<br />
White list validation is appropriate for all input fields provided by the user. White list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized. If it's well structured data, like dates, social security numbers, zip codes, e-mail addresses, etc. then the developer should be able to define a very strong validation pattern, usually based on regular expressions, for validating such input. If the input field comes from a fixed set of options, like a drop down list or radio buttons, then the input needs to match exactly one of the values offered to the user in the first place. The most difficult fields to validate are so called 'free text' fields, like blog entries. However, even those types of fields can be validated to some degree. For example, you can at least exclude all non-printable characters (except acceptable white space, e.g., CR, LF, tab, space), and define a maximum length for the input field.<br />
<br />
Developing regular expressions can be complicated, and is well beyond the scope of this cheat sheet. There are lots of resources on the internet about how to write regular expressions, including: http://www.regular-expressions.info/ and the [[OWASP Validation Regex Repository]]. <br />
<br />
In summary, input validation should:<br />
* Be applied to all input data, at minimum<br />
* Define the allowed set of characters to be accepted<br />
* Defines a minimum and maximum length for the data (e.g. {1,25} )<br />
<br />
== White List Regular Expression Examples ==<br />
<br />
Validating an U.S. Zip Code (5 digits plus optional -4) <br />
^\d{5}(-\d{4})?$<br />
<br />
Validating U.S. State Selection From a Drop-Down Menu<br />
^(AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU|<br />
HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|MO|MT|NE| <br />
NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN|<br />
TX|UT|VT|VI|VA|WA|WV|WI|WY)$<br />
<br />
'''Java Regex Usage Example'''<br />
<br />
Example validating the parameter “zip” using a regular expression.<br />
<br />
private static final Pattern zipPattern = Pattern.compile("^\d{5}(-\d{4})?$");<br />
public void doPost( HttpServletRequest request, HttpServletResponse response) {<br />
try {<br />
String zipCode = request.getParameter( "zip" );<br />
if ( !zipPattern.matcher( zipCode ).matches() {<br />
throw new YourValidationException( "Improper zipcode format." );<br />
}<br />
.. do what you want here, after its been validated ..<br />
} catch(YourValidationException e ) {<br />
response.sendError( response.SC_BAD_REQUEST, e.getMessage() );<br />
}<br />
}<br />
<br />
Some white list validators have also been predefined in various open source packages that you can leverage. For example:<br />
* [http://jakarta.apache.org/commons/validator Apache Commons Validator]<br />
<br />
== Client Side vs Server Side Validation ==<br />
Be aware that any JavaScript input validation performed on the client can be bypassed by an attacker that disables JavaScript or uses a Web Proxy. Ensure that any input validation performed on the client is also performed on the server.<br />
<br />
== Validating Rich User Content ==<br />
It is very difficult to validate rich content submitted by a user. For more information, please see the cheatsheet on [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Sanitize_HTML_Markup_with_a_Library_Designed_for_the_Job Sanitizing HTML Markup with a Library Designed for the Job].<br />
<br />
== Preventing XSS and Content Security Policy ==<br />
* All user data controlled must be encoded when returned in the html page to prevent the execution of malicious data (e.g. XSS). For example &lt;script&gt; would be returned as &amp;lt;script&amp;gt;<br />
* The type of encoding is specific to the context of the page where the user controlled data is inserted. For example, HTML entity encoding is appropriate for data placed into the HTML body. However, user data placed into a script would need JavaScript specific output encoding. <br />
<br />
Detailed information on XSS prevention here: [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet OWASP XSS Prevention Cheat Sheet]<br />
<br />
= File Upload Validation = <br />
<br />
Many websites allow users to upload files, such as a profile picture or more. This section helps provide that feature securely.<br />
<br />
==Upload Verification==<br />
<br />
* Use input validation to ensure the uploaded filename uses an expected extension type <br />
* Ensure the uploaded file is not larger than a defined maximum file size<br />
* If the website supports ZIP file upload, do validation check before unzip the file. The check includes the target path, level of compress, estimated unzip size. <br />
<br />
==Upload Storage==<br />
<br />
* Use a new filename to store the file on the OS. Do not use any user controlled text for this filename or for the temporary filename. <br />
* When the file is uploaded to web, it's suggested to rename the file on storage. For example, the uploaded filename is test.JPG, rename it to JAI1287uaisdjhf.JPG with a random file name. The purpose of doing it to prevent the risks of direct file access and ambigious filename to evalide the filter, such as test.jpg;.asp or /../../../../../test.jpg.<br />
* Uploaded files should be analyzed for malicious content (anti-malware, static analysis, etc)<br />
* The file path should not be able to specify by client side. It's decided by server side.<br />
<br />
==Public Serving of Uploaded Content==<br />
*Ensure uploaded images are served with the correct content-type (e.g. image/jpeg, application/x-xpinstall)<br />
<br />
==Beware of "special" files==<br />
* The upload feature should be using a whitelist approach to only allow specific file types and extensions. However, it is important to be aware of the following file types that, if allowed, could result in security vulnerabilities.<br />
*"crossdomain.xml" allows cross-domain data loading in Flash, Java and Silverlight. If permitted on sites with authentication this can permit cross-domain data theft and CSRF attacks. Note this can get pretty complicated depending on the specific plugin version in question, so its best to just prohibit files named "crossdomain.xml" or "clientaccesspolicy.xml".<br />
*".htaccess" and ".htpasswd" provides server configuration options on a per-directory basis, and should not be permitted. See http://en.wikipedia.org/wiki/Htaccess<br />
*Web executable script files are suggested not to be allowed such as aspx, css, swf, xhtml, rhtml, shtml, jsp, js, pl, php, cgi.<br />
<br />
==Upload Verification==<br />
*Use image rewriting libraries to verify the image is valid and to strip away extraneous content. <br />
*Set the extension of the stored image to be a valid image extension based on the detected content type of the image from image processing (e.g. do not just trust the header from the upload). <br />
*Ensure the detected content type of the image is within a list of defined image types (jpg, png, etc)<br />
<br />
= Email Address Validation =<br />
<br />
== Email Validation Basics ==<br />
<br />
Many web applications do not treat email addresses correctly due to common misconceptions about what constitutes a valid address. Specifically, it is completely valid to have an mailbox address which:<br />
* Is case sensitive in the local portion of the address (left of the rightmost @ character)<br />
* Has non-alphanumeric characters in the local-part (including + and @)<br />
* Has zero or more labels<br />
<br />
At the time of writing, RFC 5321 is the current standard defining SMTP and what constitutes a valid mailbox address. Please note, email addresses should be considered to be public data.<br />
<br />
Many web applications contain computationally expensive and inaccurate regular expressions that attempt to validate email addresses. Recent changes to the landscape mean that the number of false-negatives will increase, particularly due to:<br />
* Increased popularity of sub-addressing by providers such as Gmail (commonly using + as a token in the local-part to affect delivery)<br />
* New gTLDs with long names (many regular expressions check the number and length of each label in the domain)<br />
<br />
Following RFC 5321, best practice for validating an email address would be to:<br />
* Check for presence of at least one @ symbol in the address<br />
* Ensure the local-part is no longer than 64 octets<br />
* Ensure the domain is no longer than 255 octets<br />
* Ensure the address is deliverable<br />
<br />
To ensure an address is deliverable, the only way to check this is to send the user an email and have the user take action to confirm receipt. Beyond confirming that the email address is valid and deliverable, this also provides a positive acknowledgement that the user has access to the mailbox and is likely to be authorized to use it. This does not mean that other users cannot access this mailbox, for example when the user makes use of a service that generates a throw away email address.<br />
* Email verification links should only satisfy the requirement of verify email address ownership and should not provide the user with an authenticated session (e.g. the user must still authenticate as normal to access the application).<br />
* Email verification codes must expire after the first use or expire after 8 hours if not used.<br />
<br />
== Address Normalization ==<br />
<br />
As the local-part of email addresses are, in fact - case sensitive, it is important to store and compare email addresses correctly. To normalise an email address input, you would convert the domain part ONLY to lowercase.<br />
<br />
Unfortunately this does and will make input harder to normalise and correctly match to a users intent. It is reasonable to only accept one unique capitalisation of an otherwise identical address, however in this case it is critical to:<br />
* Store the user-part as provided and verified by user verification<br />
* Perform comparisons by lowercase(provided)==lowercase(persisted)<br />
<br />
= Authors and Primary Editors =<br />
<br />
Dave Wichers - dave.wichers [at] aspectsecurity.com<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Source_Code_Analysis_Tools&diff=229375Source Code Analysis Tools2017-05-03T16:33:31Z<p>Pawel Krawczyk: /* Open Source or Free Tools Of This Type */ Bandit</p>
<hr />
<div>Source code analysis tools, also referred to as Static Application Security Testing (SAST) Tools, are designed to analyze source code and/or compiled versions of code to help find security flaws. Ideally, such tools would automatically find security flaws with such a high degree of confidence that what's found is indeed a flaw. However, this is beyond the state of the art for many types of application security flaws. Thus, such tools frequently serve as aids for an analyst to help them zero in on security relevant portions of code so they can find flaws more efficiently, rather than a tool that just automatically finds flaws. If you are interested in the effectiveness of SAST tools, check out the OWASP [[Benchmark]] project, which is scientifically measuring the effectiveness of all types of vulnerability detection tools, including SAST.<br />
<br />
Some tools are starting to move into the IDE. For the types of problems that can be detected during the software development phase itself, this is a powerful phase within the development life cycle to employ such tools, as it provides immediate feedback to the developer on issues they might be introducing into the code during code development itself. This immediate feedback is very useful, especially when compared to finding vulnerabilities much later in the development cycle.<br />
<br />
== Strengths and Weaknesses ==<br />
<br />
=== Strengths ===<br />
<br />
* Scales well -- can be run on lots of software, and can be run repeatedly (as with nightly builds or continuous integration)<br />
* Useful for things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, and so forth<br />
* Output is good for developers -- highlights the precise source files, line numbers, and even subsections of lines that are affected<br />
<br />
=== Weaknesses ===<br />
<br />
* Many types of security vulnerabilities are very difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. The current state of the art only allows such tools to automatically find a relatively small percentage of application security flaws. However, tools of this type are getting better.<br />
* High numbers of false positives.<br />
* Frequently can't find configuration issues, since they are not represented in the code.<br />
* Difficult to 'prove' that an identified security issue is an actual vulnerability.<br />
* Many of these tools have difficulty analyzing code that can't be compiled. Analysts frequently can't compile code because they don't have the right libraries, all the compilation instructions, all the code, etc.<br />
<br />
==Important Selection Criteria==<br />
<br />
* Requirement: Must support your programming language, but not usually a key factor once it does.<br />
* Types of vulnerabilities it can detect (out of the [[OWASP Top Ten]]?) (plus more?)<br />
* How accurate is it? False Positive/False Negative rates?<br />
** Does the tool have an OWASP [[Benchmark]] score?<br />
* Does it understand the libraries/frameworks you use?<br />
* Does it require a fully buildable set of source?<br />
* Can it run against binaries instead of source?<br />
* Can it be integrated into the developer's IDE?<br />
* How hard is it to setup/use?<br />
* Can it be run continuously and automatically?<br />
* License cost for the tool. (Some are sold per user, per org, per app, per line of code analyzed. Consulting licenses are frequently different than end user licenses.)<br />
<br />
==OWASP Tools Of This Type==<br />
<br />
* [http://www.owasp.org/index.php/Category:OWASP_Orizon_Project OWASP Orizon Project]<br />
* [[OWASP_LAPSE_Project | OWASP LAPSE Project]]<br />
* [[OWASP O2 Platform]]<br />
* [[OWASP WAP-Web Application Protection]]<br />
<br />
==Disclaimer==<br />
<br />
Disclaimer: <b>The tools listed in the tables below are presented in alphabetical order. <i>OWASP does not endorse any of the vendors or tools by listing them in the table below.</i> We have made every effort to provide this information as accurately as possible. If you are the vendor of a tool below and think that this information is incomplete or incorrect, please send an e-mail to our mailing list and we will make every effort to correct this information.</b><br />
<br />
==Open Source or Free Tools Of This Type==<br />
<br />
* [https://wiki.openstack.org/wiki/Security/Projects/Bandit Bandit] - bandit is a comprehensive source vulnerability scanner for Python<br />
* [http://brakemanscanner.org/ Brakeman] - Brakeman is an open source vulnerability scanner specifically designed for Ruby on Rails applications<br />
* [http://rubygems.org/gems/codesake-dawn Codesake Dawn] - Codesake Dawn is an open source security source code analyzer designed for Sinatra, Padrino for Ruby on Rails applications. It also works on non-web applications written in Ruby<br />
* [http://findbugs.sourceforge.net/ FindBugs] - Find Bugs (including a few security flaws) in Java programs<br />
* [https://find-sec-bugs.github.io/ FindSecBugs] - A security specific plugin for FingBugs that significantly improves FindBug's ability to find security vulnerabilities in Java programs<br />
* [http://www.dwheeler.com/flawfinder/ Flawfinder] Flawfinder - Scans C and C++<br />
* [https://www.bishopfox.com/resources/tools/google-hacking-diggity/attack-tools/ Google CodeSearchDiggity] - Uses Google Code Search to identifies vulnerabilities in open source code projects hosted by Google Code, MS CodePlex, SourceForge, Github, and more. The tool comes with over 130 default searches that identify SQL injection, cross-site scripting (XSS), insecure remote and local file includes, hard-coded passwords, and much more. ''Essentially, Google CodeSearchDiggity provides a source code security analysis of nearly every single open source code project in existence – simultaneously.'' <br />
* [http://pmd.sourceforge.net/ PMD] - PMD scans Java source code and looks for potential code problems (this is a code quality tool that does not focus on security issues)<br />
* [http://msdn.microsoft.com/en-us/library/ms933794.aspx PreFast] (Microsoft) - PREfast is a static analysis tool that identifies defects in C/C++ programs. Last update 2006.<br />
* [http://sourceforge.net/projects/rips-scanner/ RIPS] - RIPS is a static source code analyzer for vulnerabilities in PHP web applications. Please see notes on the sourceforge.net site.<br />
* [http://www.sonarqube.org/ SonarQube] - Scans source code for more than 20 languages for Bugs, Vulnerabilities, and Code Smells. SonarQube IDE plugins for Eclipse, Visual Studio, and IntelliJ provided by [http://www.sonarlint.org/ SonarLint].<br />
* [http://sourceforge.net/projects/visualcodegrepp/ VisualCodeGrepper (VCG)] - Scans C/C++, C#, VB, PHP, Java, and PL/SQL for security issues and for comments which may indicate defective code. The config files can be used to carry out additional checks for banned functions or functions which commonly cause security issues.<br />
* [http://www.xanitizer.net Xanitizer] - Scans Java for security vulnerabilities, mainly via taint analysis. The tool comes with a number of predefined vulnerability detectors which can additionally be extended by the user.<br />
<br />
==Commercial Tools Of This Type==<br />
<br />
* [http://www-01.ibm.com/software/rational/products/appscan/source/ AppScan Source] (IBM)<br />
* [http://www.blueclosure.com BlueClosure BC Detect] (BlueClosure)<br />
* [https://buguroo.com/products/bugblast-next-gen-appsec-platform/bugscout-sca bugScout] (Buguroo Offensive Security) Latest generation source code analysis tool bugScout detects source code vulnerabilities and makes possible an accurate management of the life cycles due to its easy use.<br />
* [https://www.codacy.com/ Codacy] is free for open source projects, and integrates with tools such as Brakeman, Bandit, FindBugs, and a number of others. It offers security patterns for languages such as Python, Ruby, Scala, Java, Javascript and more.<br />
* [http://www.contrastsecurity.com/ Contrast from Contrast Security] Contrast performs code security without actually doing static analysis. Contrast does Interactive Application Security Testing (IAST), correlating runtime code & data analysis. It provides code level results without actually relying on static analysis.<br />
* [http://www.coverity.com/products/code-advisor/ Coverity Code Advisor] (Synopsys)<br />
* [https://www.checkmarx.com/technology/static-code-analysis-sca/ CxSAST] (Checkmarx)<br />
* [http://www8.hp.com/us/en/software-solutions/static-code-analysis-sast/ Fortify] (HP)<br />
* [http://www.juliasoft.com/solutions Julia] - SaaS Java static analysis (JuliaSoft)<br />
* [http://www.klocwork.com/capabilities/static-code-analysis KlocWork] (KlocWork)<br />
* [https://www.kiuwan.com/code-analysis/ Kiuwan] - SaaS Software Quality & Security Analysis (an [http://www.optimyth.com Optimyth] company)<br />
* [http://www.parasoft.com/jsp/capabilities/static_analysis.jsp?itemId=547 Parasoft Test] (Parasoft)<br />
* [http://www.viva64.com/en/ PVS-Studio] (PVS-Studio) For C/C++, C#<br />
* [https://www.whitehatsec.com/products/static-application-security-testing/ Sentinel Source] (Whitehat)<br />
* [https://www.synopsys.com/software-integrity/products/interactive-application-security-testing.html Seeker] (Synopsys) Seeker performs code security without actually doing static analysis. Seeker does Interactive Application Security Testing (IAST), correlating runtime code & data analysis with simulated attacks. It provides code level results without actually relying on static analysis.<br />
* [http://www.sourcepatrol.co.uk/ Source Patrol] (Pentest)<br />
* [http://www.veracode.com/products/binary-static-analysis-sast Veracode Static Analysis] (Veracode)<br />
<br />
==More info==<br />
<br />
* [[Appendix_A:_Testing_Tools | Appendix A: Testing Tools]]<br />
* [http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html NIST's list of Source Code Security Analysis Tools]<br />
* [[:Category:Vulnerability_Scanning_Tools | DAST Tools]] - Similar info on Dynamic Application Security Testing (DAST) Tools<br />
<br />
[[Category:OWASP .NET Project]]<br />
[[Category:SAMM-CR-2]]<br />
__NOTOC__</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Category:Vulnerability_Scanning_Tools&diff=229369Category:Vulnerability Scanning Tools2017-05-03T16:14:33Z<p>Pawel Krawczyk: update the Beyond Security URL</p>
<hr />
<div>== Description ==<br />
<br />
Web Application Vulnerability Scanners are automated tools that scan web applications, normally from the outside, to look for security vulnerabilities such as [[Cross-site scripting]], [[SQL Injection]], [[Command Injection]], [[Path Traversal]] and insecure server configuration. This category of tools is frequently referred to as [https://www.techopedia.com/definition/30958/dynamic-application-security-testing-dast Dynamic Application Security Testing] (DAST) Tools. A large number of both commercial and open source tools of this type are available and all of these tools have their own strengths and weaknesses. If you are interested in the effectiveness of DAST tools, check out the OWASP [[Benchmark]] project, which is scientifically measuring the effectiveness of all types of vulnerability detection tools, including DAST.<br />
<br />
Here we provide a list of vulnerability scanning tools currently available in the market.<br />
<br />
<br> '''Disclaimer:''' The tools listing in the table below are presented in an alphabetical order. <b>OWASP does not endorse any of the Vendors or Scanning Tools by listing them in the table below. We have made every effort to provide this information as accurately as possible. If you are the vendor of a tool below and think this information is incomplete or incorrect, please send an e-mail to our [mailto:owasp_ha_vulnerability_scanner_project@lists.owasp.org mailing list] and we will make every effort to correct this information.</b><br />
<br />
== Tools Listing ==<br />
<br />
{{:Template:OWASP Tool Headings}}<br />
{{OWASP Tool Info || tool_name = [http://www.acunetix.com/ Acunetix WVS] || tool_owner = Acunetix || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www-03.ibm.com/software/products/en/appscan-standard AppScan] || tool_owner = IBM || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [https://www.trustwave.com/Products/Application-Security/App-Scanner-Family/App-Scanner-Enterprise/ App Scanner] || tool_owner = Trustwave || tool_licence = Commercial || tool_platforms = Windows }}<br />
{{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/appspider/ AppSpider] || tool_owner = Rapid7 || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [https://www.scanmyserver.com/ AVDS] || tool_owner = Beyond Security || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = SaaS }}<br />
{{OWASP Tool Info || tool_name = [https://www.blueclosure.com BlueClosure BC Detect] || tool_owner = BlueClosure || tool_licence = Commercial, 2 weeks trial || tool_platforms = Most platforms supported}}<br />
{{OWASP Tool Info || tool_name = [http://www.portswigger.net/ Burp Suite] || tool_owner = PortSwiger || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Most platforms supported }}<br />
{{OWASP Tool Info || tool_name = [https://contrastsecurity.com Contrast] || tool_owner = Contrast Security || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises }}<br />
{{OWASP Tool Info || tool_name = [https://detectify.com/ Detectify] || tool_owner = Detectify || tool_licence = Commercial || tool_platforms = SaaS }}<br />
{{OWASP Tool Info || tool_name = [http://www.gamasec.com/Gamascan.aspx GamaScan] || tool_owner = GamaSec || tool_licence = Commercial || tool_platforms = Windows }}<br />
{{OWASP Tool Info || tool_name = [http://rgaucher.info/beta/grabber/ Grabber] || tool_owner = Romain Gaucher || tool_licence = Open Source || tool_platforms = Python 2.4, BeautifulSoup and PyXML}}<br />
{{OWASP Tool Info || tool_name = [http://sourceforge.net/p/grendel/code/ci/c59780bfd41bdf34cc13b27bc3ce694fd3cb7456/tree/ Grendel-Scan] || tool_owner = David Byrne || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.golismero.com GoLismero] || tool_owner = GoLismero Team || tool_licence = GPLv2.0 || tool_platforms = Windows, Linux and Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.ikare-monitoring.com/ IKare] || tool_owner = ITrust || tool_licence = Commercial || tool_platforms = N/A }}<br />
{{OWASP Tool Info || tool_name = [https://www.indusface.com/index.php/products/web-application-scanning Indusface Web Application Scanning] || tool_owner = Indusface || tool_licence = Commercial || tool_platforms = SaaS}}<br />
{{OWASP Tool Info || tool_name = [http://www.nstalker.com/ N-Stealth] || tool_owner = N-Stalker || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.mavitunasecurity.com/ Netsparker] || tool_owner = MavitunaSecurity || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/nexpose-community-edition.jsp Nexpose] || tool_owner = Rapid7 || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Windows/Linux}}<br />
{{OWASP Tool Info || tool_name = [http://www.cirt.net/nikto2 Nikto] || tool_owner = CIRT || tool_licence = Open Source|| tool_platforms = Unix/Linux}}<br />
{{OWASP Tool Info || tool_name = [http://www.milescan.com/ ParosPro] || tool_owner = MileSCAN || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/proxy.html Proxy.app] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.qualys.com/products/qg_suite/was/ QualysGuard] || tool_owner = Qualys || tool_licence = Commercial || tool_platforms = N/A}}<br />
{{OWASP Tool Info || tool_name = [http://www.beyondtrust.com/Products/RetinaNetworkSecurityScanner/ Retina] || tool_owner = BeyondTrust || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.orvant.com Securus] || tool_owner = Orvant, Inc || tool_licence = Commercial || tool_platforms = N/A}}<br />
{{OWASP Tool Info || tool_name = [http://www.whitehatsec.com/home/services/services.html Sentinel] || tool_owner = WhiteHat Security || tool_licence = Commercial || tool_platforms = N/A}}<br />
{{OWASP Tool Info || tool_name = [http://www.parasoft.com/products/article.jsp?articleId=3169&redname=webtesting&referred=webtesting SOATest] || tool_owner = Parasoft || tool_licence = Commercial || tool_platforms = Windows / Linux / Solaris}}<br />
{{OWASP Tool Info || tool_name = [https://www.tinfoilsecurity.com Tinfoil Security] || tool_owner = Tinfoil Security, Inc. || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises}}<br />
{{OWASP Tool Info || tool_name = [https://www.trustwave.com/external-vulnerability-scanning.php Trustkeeper Scanner] || tool_owner = Trustwave SpiderLabs || tool_licence = Commercial || tool_platforms = SaaS}}<br />
{{OWASP Tool Info || tool_name = [https://subgraph.com/vega/ Vega] || tool_owner = Subgraph || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://wapiti.sourceforge.net/ Wapiti] || tool_owner = Informática Gesfor || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.tripwire.com/it-security-software/enterprise-vulnerability-management/web-application-vulnerability-scanning/ WebApp360] || tool_owner = TripWire || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [https://webcookies.org WebCookies] || tool_owner = WebCookies || tool_licence = Free|| tool_platforms = SaaS}}<br />
{{OWASP Tool Info || tool_name = [http://www8.hp.com/us/en/software-solutions/software.html?compURI=1341991#.Uuf0KBAo4iw WebInspect] || tool_owner = HP || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/webreaver.html WebReaver] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.german-websecurity.com/en/products/webscanservice/product-details/overview/ WebScanService] || tool_owner = German Web Security || tool_licence = Commercial || tool_platforms = N/A}}<br />
{{OWASP Tool Info || tool_name = [https://suite.websecurify.com/ Websecurify Suite] || tool_owner = Websecurify || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows, Linux, Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.sensepost.com/research/wikto/ Wikto] || tool_owner = Sensepost || tool_licence = Open Source || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.w3af.org/ w3af] || tool_owner = w3af.org || tool_licence = GPLv2.0 || tool_platforms = Linux and Mac}}<br />
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework Xenotix XSS Exploit Framework] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Zed Attack Proxy] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}<br />
|}<br />
<br />
== References ==<br />
<br />
*[[Source_Code_Analysis_Tools | SAST Tools]] - Similar Information on Static Application Security Testing (SAST) Tools<br />
*http://projects.webappsec.org/Web-Application-Security-Scanner-Evaluation-Criteria<br />
*http://www.slideshare.net/lbsuto/accuracy-and-timecostsofwebappscanners<br />
*http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners.html<br />
*http://www.tssci-security.com/archives/2007/11/24/2007-security-testing-tools-in-review/<br />
*http://www.softwareqatest.com/qatweb1.html#SECURITY<br />
<br />
[[Category:OWASP_Tools_Project]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Category:Vulnerability_Scanning_Tools&diff=229368Category:Vulnerability Scanning Tools2017-05-03T16:08:51Z<p>Pawel Krawczyk: +Detectify</p>
<hr />
<div>== Description ==<br />
<br />
Web Application Vulnerability Scanners are automated tools that scan web applications, normally from the outside, to look for security vulnerabilities such as [[Cross-site scripting]], [[SQL Injection]], [[Command Injection]], [[Path Traversal]] and insecure server configuration. This category of tools is frequently referred to as [https://www.techopedia.com/definition/30958/dynamic-application-security-testing-dast Dynamic Application Security Testing] (DAST) Tools. A large number of both commercial and open source tools of this type are available and all of these tools have their own strengths and weaknesses. If you are interested in the effectiveness of DAST tools, check out the OWASP [[Benchmark]] project, which is scientifically measuring the effectiveness of all types of vulnerability detection tools, including DAST.<br />
<br />
Here we provide a list of vulnerability scanning tools currently available in the market.<br />
<br />
<br> '''Disclaimer:''' The tools listing in the table below are presented in an alphabetical order. <b>OWASP does not endorse any of the Vendors or Scanning Tools by listing them in the table below. We have made every effort to provide this information as accurately as possible. If you are the vendor of a tool below and think this information is incomplete or incorrect, please send an e-mail to our [mailto:owasp_ha_vulnerability_scanner_project@lists.owasp.org mailing list] and we will make every effort to correct this information.</b><br />
<br />
== Tools Listing ==<br />
<br />
{{:Template:OWASP Tool Headings}}<br />
{{OWASP Tool Info || tool_name = [http://www.acunetix.com/ Acunetix WVS] || tool_owner = Acunetix || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www-03.ibm.com/software/products/en/appscan-standard AppScan] || tool_owner = IBM || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [https://www.trustwave.com/Products/Application-Security/App-Scanner-Family/App-Scanner-Enterprise/ App Scanner] || tool_owner = Trustwave || tool_licence = Commercial || tool_platforms = Windows }}<br />
{{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/appspider/ AppSpider] || tool_owner = Rapid7 || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.beyondsecurity.com/avds AVDS] || tool_owner = Beyond Security || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = N/A }}<br />
{{OWASP Tool Info || tool_name = [https://www.blueclosure.com BlueClosure BC Detect] || tool_owner = BlueClosure || tool_licence = Commercial, 2 weeks trial || tool_platforms = Most platforms supported}}<br />
{{OWASP Tool Info || tool_name = [http://www.portswigger.net/ Burp Suite] || tool_owner = PortSwiger || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Most platforms supported }}<br />
{{OWASP Tool Info || tool_name = [https://contrastsecurity.com Contrast] || tool_owner = Contrast Security || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises }}<br />
{{OWASP Tool Info || tool_name = [https://detectify.com/ Detectify] || tool_owner = Detectify || tool_licence = Commercial || tool_platforms = SaaS }}<br />
{{OWASP Tool Info || tool_name = [http://www.gamasec.com/Gamascan.aspx GamaScan] || tool_owner = GamaSec || tool_licence = Commercial || tool_platforms = Windows }}<br />
{{OWASP Tool Info || tool_name = [http://rgaucher.info/beta/grabber/ Grabber] || tool_owner = Romain Gaucher || tool_licence = Open Source || tool_platforms = Python 2.4, BeautifulSoup and PyXML}}<br />
{{OWASP Tool Info || tool_name = [http://sourceforge.net/p/grendel/code/ci/c59780bfd41bdf34cc13b27bc3ce694fd3cb7456/tree/ Grendel-Scan] || tool_owner = David Byrne || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.golismero.com GoLismero] || tool_owner = GoLismero Team || tool_licence = GPLv2.0 || tool_platforms = Windows, Linux and Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.ikare-monitoring.com/ IKare] || tool_owner = ITrust || tool_licence = Commercial || tool_platforms = N/A }}<br />
{{OWASP Tool Info || tool_name = [https://www.indusface.com/index.php/products/web-application-scanning Indusface Web Application Scanning] || tool_owner = Indusface || tool_licence = Commercial || tool_platforms = SaaS}}<br />
{{OWASP Tool Info || tool_name = [http://www.nstalker.com/ N-Stealth] || tool_owner = N-Stalker || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.mavitunasecurity.com/ Netsparker] || tool_owner = MavitunaSecurity || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/nexpose-community-edition.jsp Nexpose] || tool_owner = Rapid7 || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Windows/Linux}}<br />
{{OWASP Tool Info || tool_name = [http://www.cirt.net/nikto2 Nikto] || tool_owner = CIRT || tool_licence = Open Source|| tool_platforms = Unix/Linux}}<br />
{{OWASP Tool Info || tool_name = [http://www.milescan.com/ ParosPro] || tool_owner = MileSCAN || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/proxy.html Proxy.app] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.qualys.com/products/qg_suite/was/ QualysGuard] || tool_owner = Qualys || tool_licence = Commercial || tool_platforms = N/A}}<br />
{{OWASP Tool Info || tool_name = [http://www.beyondtrust.com/Products/RetinaNetworkSecurityScanner/ Retina] || tool_owner = BeyondTrust || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.orvant.com Securus] || tool_owner = Orvant, Inc || tool_licence = Commercial || tool_platforms = N/A}}<br />
{{OWASP Tool Info || tool_name = [http://www.whitehatsec.com/home/services/services.html Sentinel] || tool_owner = WhiteHat Security || tool_licence = Commercial || tool_platforms = N/A}}<br />
{{OWASP Tool Info || tool_name = [http://www.parasoft.com/products/article.jsp?articleId=3169&redname=webtesting&referred=webtesting SOATest] || tool_owner = Parasoft || tool_licence = Commercial || tool_platforms = Windows / Linux / Solaris}}<br />
{{OWASP Tool Info || tool_name = [https://www.tinfoilsecurity.com Tinfoil Security] || tool_owner = Tinfoil Security, Inc. || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises}}<br />
{{OWASP Tool Info || tool_name = [https://www.trustwave.com/external-vulnerability-scanning.php Trustkeeper Scanner] || tool_owner = Trustwave SpiderLabs || tool_licence = Commercial || tool_platforms = SaaS}}<br />
{{OWASP Tool Info || tool_name = [https://subgraph.com/vega/ Vega] || tool_owner = Subgraph || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://wapiti.sourceforge.net/ Wapiti] || tool_owner = Informática Gesfor || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.tripwire.com/it-security-software/enterprise-vulnerability-management/web-application-vulnerability-scanning/ WebApp360] || tool_owner = TripWire || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [https://webcookies.org WebCookies] || tool_owner = WebCookies || tool_licence = Free|| tool_platforms = SaaS}}<br />
{{OWASP Tool Info || tool_name = [http://www8.hp.com/us/en/software-solutions/software.html?compURI=1341991#.Uuf0KBAo4iw WebInspect] || tool_owner = HP || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/webreaver.html WebReaver] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.german-websecurity.com/en/products/webscanservice/product-details/overview/ WebScanService] || tool_owner = German Web Security || tool_licence = Commercial || tool_platforms = N/A}}<br />
{{OWASP Tool Info || tool_name = [https://suite.websecurify.com/ Websecurify Suite] || tool_owner = Websecurify || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows, Linux, Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.sensepost.com/research/wikto/ Wikto] || tool_owner = Sensepost || tool_licence = Open Source || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.w3af.org/ w3af] || tool_owner = w3af.org || tool_licence = GPLv2.0 || tool_platforms = Linux and Mac}}<br />
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework Xenotix XSS Exploit Framework] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Zed Attack Proxy] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}<br />
|}<br />
<br />
== References ==<br />
<br />
*[[Source_Code_Analysis_Tools | SAST Tools]] - Similar Information on Static Application Security Testing (SAST) Tools<br />
*http://projects.webappsec.org/Web-Application-Security-Scanner-Evaluation-Criteria<br />
*http://www.slideshare.net/lbsuto/accuracy-and-timecostsofwebappscanners<br />
*http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners.html<br />
*http://www.tssci-security.com/archives/2007/11/24/2007-security-testing-tools-in-review/<br />
*http://www.softwareqatest.com/qatweb1.html#SECURITY<br />
<br />
[[Category:OWASP_Tools_Project]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Category:Vulnerability_Scanning_Tools&diff=229367Category:Vulnerability Scanning Tools2017-05-03T16:06:02Z<p>Pawel Krawczyk: +WebCookies</p>
<hr />
<div>== Description ==<br />
<br />
Web Application Vulnerability Scanners are automated tools that scan web applications, normally from the outside, to look for security vulnerabilities such as [[Cross-site scripting]], [[SQL Injection]], [[Command Injection]], [[Path Traversal]] and insecure server configuration. This category of tools is frequently referred to as [https://www.techopedia.com/definition/30958/dynamic-application-security-testing-dast Dynamic Application Security Testing] (DAST) Tools. A large number of both commercial and open source tools of this type are available and all of these tools have their own strengths and weaknesses. If you are interested in the effectiveness of DAST tools, check out the OWASP [[Benchmark]] project, which is scientifically measuring the effectiveness of all types of vulnerability detection tools, including DAST.<br />
<br />
Here we provide a list of vulnerability scanning tools currently available in the market.<br />
<br />
<br> '''Disclaimer:''' The tools listing in the table below are presented in an alphabetical order. <b>OWASP does not endorse any of the Vendors or Scanning Tools by listing them in the table below. We have made every effort to provide this information as accurately as possible. If you are the vendor of a tool below and think this information is incomplete or incorrect, please send an e-mail to our [mailto:owasp_ha_vulnerability_scanner_project@lists.owasp.org mailing list] and we will make every effort to correct this information.</b><br />
<br />
== Tools Listing ==<br />
<br />
{{:Template:OWASP Tool Headings}}<br />
{{OWASP Tool Info || tool_name = [http://www.acunetix.com/ Acunetix WVS] || tool_owner = Acunetix || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www-03.ibm.com/software/products/en/appscan-standard AppScan] || tool_owner = IBM || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [https://www.trustwave.com/Products/Application-Security/App-Scanner-Family/App-Scanner-Enterprise/ App Scanner] || tool_owner = Trustwave || tool_licence = Commercial || tool_platforms = Windows }}<br />
{{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/appspider/ AppSpider] || tool_owner = Rapid7 || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.beyondsecurity.com/avds AVDS] || tool_owner = Beyond Security || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = N/A }}<br />
{{OWASP Tool Info || tool_name = [https://www.blueclosure.com BlueClosure BC Detect] || tool_owner = BlueClosure || tool_licence = Commercial, 2 weeks trial || tool_platforms = Most platforms supported}}<br />
{{OWASP Tool Info || tool_name = [http://www.portswigger.net/ Burp Suite] || tool_owner = PortSwiger || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Most platforms supported }}<br />
{{OWASP Tool Info || tool_name = [https://contrastsecurity.com Contrast] || tool_owner = Contrast Security || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises }}<br />
{{OWASP Tool Info || tool_name = [http://www.gamasec.com/Gamascan.aspx GamaScan] || tool_owner = GamaSec || tool_licence = Commercial || tool_platforms = Windows }}<br />
{{OWASP Tool Info || tool_name = [http://rgaucher.info/beta/grabber/ Grabber] || tool_owner = Romain Gaucher || tool_licence = Open Source || tool_platforms = Python 2.4, BeautifulSoup and PyXML}}<br />
{{OWASP Tool Info || tool_name = [http://sourceforge.net/p/grendel/code/ci/c59780bfd41bdf34cc13b27bc3ce694fd3cb7456/tree/ Grendel-Scan] || tool_owner = David Byrne || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.golismero.com GoLismero] || tool_owner = GoLismero Team || tool_licence = GPLv2.0 || tool_platforms = Windows, Linux and Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.ikare-monitoring.com/ IKare] || tool_owner = ITrust || tool_licence = Commercial || tool_platforms = N/A }}<br />
{{OWASP Tool Info || tool_name = [https://www.indusface.com/index.php/products/web-application-scanning Indusface Web Application Scanning] || tool_owner = Indusface || tool_licence = Commercial || tool_platforms = SaaS}}<br />
{{OWASP Tool Info || tool_name = [http://www.nstalker.com/ N-Stealth] || tool_owner = N-Stalker || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.mavitunasecurity.com/ Netsparker] || tool_owner = MavitunaSecurity || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/nexpose-community-edition.jsp Nexpose] || tool_owner = Rapid7 || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Windows/Linux}}<br />
{{OWASP Tool Info || tool_name = [http://www.cirt.net/nikto2 Nikto] || tool_owner = CIRT || tool_licence = Open Source|| tool_platforms = Unix/Linux}}<br />
{{OWASP Tool Info || tool_name = [http://www.milescan.com/ ParosPro] || tool_owner = MileSCAN || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/proxy.html Proxy.app] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.qualys.com/products/qg_suite/was/ QualysGuard] || tool_owner = Qualys || tool_licence = Commercial || tool_platforms = N/A}}<br />
{{OWASP Tool Info || tool_name = [http://www.beyondtrust.com/Products/RetinaNetworkSecurityScanner/ Retina] || tool_owner = BeyondTrust || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.orvant.com Securus] || tool_owner = Orvant, Inc || tool_licence = Commercial || tool_platforms = N/A}}<br />
{{OWASP Tool Info || tool_name = [http://www.whitehatsec.com/home/services/services.html Sentinel] || tool_owner = WhiteHat Security || tool_licence = Commercial || tool_platforms = N/A}}<br />
{{OWASP Tool Info || tool_name = [http://www.parasoft.com/products/article.jsp?articleId=3169&redname=webtesting&referred=webtesting SOATest] || tool_owner = Parasoft || tool_licence = Commercial || tool_platforms = Windows / Linux / Solaris}}<br />
{{OWASP Tool Info || tool_name = [https://www.tinfoilsecurity.com Tinfoil Security] || tool_owner = Tinfoil Security, Inc. || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises}}<br />
{{OWASP Tool Info || tool_name = [https://www.trustwave.com/external-vulnerability-scanning.php Trustkeeper Scanner] || tool_owner = Trustwave SpiderLabs || tool_licence = Commercial || tool_platforms = SaaS}}<br />
{{OWASP Tool Info || tool_name = [https://subgraph.com/vega/ Vega] || tool_owner = Subgraph || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://wapiti.sourceforge.net/ Wapiti] || tool_owner = Informática Gesfor || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.tripwire.com/it-security-software/enterprise-vulnerability-management/web-application-vulnerability-scanning/ WebApp360] || tool_owner = TripWire || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [https://webcookies.org WebCookies] || tool_owner = WebCookies || tool_licence = Free|| tool_platforms = SaaS}}<br />
{{OWASP Tool Info || tool_name = [http://www8.hp.com/us/en/software-solutions/software.html?compURI=1341991#.Uuf0KBAo4iw WebInspect] || tool_owner = HP || tool_licence = Commercial || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/webreaver.html WebReaver] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.german-websecurity.com/en/products/webscanservice/product-details/overview/ WebScanService] || tool_owner = German Web Security || tool_licence = Commercial || tool_platforms = N/A}}<br />
{{OWASP Tool Info || tool_name = [https://suite.websecurify.com/ Websecurify Suite] || tool_owner = Websecurify || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows, Linux, Macintosh}}<br />
{{OWASP Tool Info || tool_name = [http://www.sensepost.com/research/wikto/ Wikto] || tool_owner = Sensepost || tool_licence = Open Source || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [http://www.w3af.org/ w3af] || tool_owner = w3af.org || tool_licence = GPLv2.0 || tool_platforms = Linux and Mac}}<br />
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework Xenotix XSS Exploit Framework] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows}}<br />
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Zed Attack Proxy] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}<br />
|}<br />
<br />
== References ==<br />
<br />
*[[Source_Code_Analysis_Tools | SAST Tools]] - Similar Information on Static Application Security Testing (SAST) Tools<br />
*http://projects.webappsec.org/Web-Application-Security-Scanner-Evaluation-Criteria<br />
*http://www.slideshare.net/lbsuto/accuracy-and-timecostsofwebappscanners<br />
*http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners.html<br />
*http://www.tssci-security.com/archives/2007/11/24/2007-security-testing-tools-in-review/<br />
*http://www.softwareqatest.com/qatweb1.html#SECURITY<br />
<br />
[[Category:OWASP_Tools_Project]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Content_Security_Policy&diff=229317Content Security Policy2017-05-02T10:43:59Z<p>Pawel Krawczyk: /* Tools */ no longer active</p>
<hr />
<div>{{taggedDocument<br />
| type=pls_review<br />
}}<br />
<br />
Last revision (mm/dd/yy): '''08/31/2013'''<br />
<br />
== Introduction ==<br />
'''CSP''' stands for '''C'''ontent '''S'''ecurity '''P'''olicy. <br />
<br />
Is an W3C specification offering the possbility to instruct the client browser from which location and/or which type of resources are allowed to be loaded. To define a loading behavior, the CSP specification use "directive" where a directive defines a loading behavior for a target resource type.<br />
<br />
<br />
This article is based on version [http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html 1.1] of the W3C specification.<br />
<br />
<br />
Directives can be specified using HTTP response header (a server may send more than one CSP HTTP header field with a given resource representation and a server may send different CSP header field values with different representations of the same resource or with different resources) or HTML Meta tag, the HTTP headers below are defined by the specs:<br />
* '''Content-Security-Policy''' : Defined by W3C Specs as standard header, used by Chrome version 25 and later, Firefox version 23 and later, Opera version 19 and later.<br />
* '''X-Content-Security-Policy''' : Used by Firefox until version 23, and Internet Explorer version 10 (which partially implements Content Security Policy).<br />
* '''X-WebKit-CSP''' : Used by Chrome until version 25<br />
<br />
<br />
<br />
The supported directives are:<br />
* '''default-src''' : Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback),<br />
* '''script-src''' : Define which scripts the protected resource can execute,<br />
* '''object-src''' : Define from where the protected resource can load plugins,<br />
* '''style-src''' : Define which styles (CSS) the user applies to the protected resource,<br />
* '''img-src''' : Define from where the protected resource can load images,<br />
* '''media-src''' : Define from where the protected resource can load video and audio,<br />
* '''frame-src''' : Define from where the protected resource can embed frames,<br />
* '''font-src''' : Define from where the protected resource can load fonts,<br />
* '''connect-src''' : Define which URIs the protected resource can load using script interfaces,<br />
* '''form-action''' : Define which URIs can be used as the action of HTML form elements,<br />
* '''sandbox''' : Specifies an HTML sandbox policy that the user agent applies to the protected resource,<br />
* '''script-nonce''' : Define script execution by requiring the presence of the specified nonce on script elements,<br />
* '''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,<br />
* '''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,<br />
* '''report-uri''' : Specifies a URI to which the user agent sends reports about policy violation<br />
<br />
An introduction to CSP is available on [http://www.html5rocks.com/en/tutorials/security/content-security-policy/ HTML5Rocks]. The browser support is shown on http://caniuse.com/#feat=contentsecuritypolicy<br />
<br />
== Risk ==<br />
The risk with CSP can have 2 main sources:<br />
# Policies misconfiguration,<br />
# Too permissive policies.<br />
<br />
== Countermeasure ==<br />
This article will focus on providing an sample implementation of a JEE Web Filter in order to apply a set of CSP policies on all HTTP response returned by server. <br />
<br />
The policies will instruct the browser to have the loading behavior below using all HTTP headers defined in W3C Specs:<br />
* Explicit loading definition of each resource type,<br />
* Resources are loaded only from source domain,<br />
* Inline style is not allowed,<br />
* For JavaScript:<br />
** ''Inline script'' will be allowed because inline scripting is commonly used (can be disabled if target site does not use this type of scripting),<br />
** ''eval()'' function will be allowed in order to not break use of popular JavaScript libraries (ex: JQuery, JQueryUI, Sencha, ...) because they use eval() function (it was the case last time I have checked the source code from CDN ;) ),<br />
* Generation of a random not guessable script nonce to use into all script tags,<br />
* Plugin types only allow PDF and Flash,<br />
* No font loading (configurable),<br />
* No Audio / Video loading (configurable),<br />
* Enable browser XSS filtering feature.<br />
<br />
<pre style="color:navy"><br />
The support for CSP directives is not the same level in major browsers (Firefox/Chrome/IE). It's recommanded to check the support <br />
provided by target browsers (using site provided in link section of this article) in order to configure CSP policies. The sample <br />
below try to provide a set of policies from which your can add policies specific to your application context.<br />
</pre><br />
<br />
''This implementation provide an option to add CSP directives used by Firefox (Mozilla CSP directives).''<br />
<br />
<pre><br />
import java.io.IOException;<br />
import java.security.MessageDigest;<br />
import java.security.NoSuchAlgorithmException;<br />
import java.security.SecureRandom;<br />
import java.util.ArrayList;<br />
import java.util.List;<br />
<br />
import javax.servlet.Filter;<br />
import javax.servlet.FilterChain;<br />
import javax.servlet.FilterConfig;<br />
import javax.servlet.ServletException;<br />
import javax.servlet.ServletRequest;<br />
import javax.servlet.ServletResponse;<br />
import javax.servlet.annotation.WebFilter;<br />
import javax.servlet.http.HttpServletRequest;<br />
import javax.servlet.http.HttpServletResponse;<br />
<br />
import org.apache.commons.codec.binary.Hex;<br />
<br />
/**<br />
* Sample filter implementation to define a set of Content Security Policies.<br/><br />
* <br />
* This implementation has a dependency on Commons Codec API.<br/><br />
* <br />
* This filter set CSP policies using all HTTP headers defined into W3C specification.<br/><br />
* <br/><br />
* This implementation is oriented to be easily understandable and easily adapted.<br/><br />
* <br />
*/<br />
@WebFilter("/*")<br />
public class CSPPoliciesApplier implements Filter {<br />
<br />
/** Configuration member to specify if web app use web fonts */<br />
public static final boolean APP_USE_WEBFONTS = false;<br />
<br />
/** Configuration member to specify if web app use videos or audios */<br />
public static final boolean APP_USE_AUDIOS_OR_VIDEOS = false;<br />
<br />
/** Configuration member to specify if filter must add CSP directive used by Mozilla (Firefox) */<br />
public static final boolean INCLUDE_MOZILLA_CSP_DIRECTIVES = true;<br />
<br />
/** Filter configuration */<br />
@SuppressWarnings("unused")<br />
private FilterConfig filterConfig = null;<br />
<br />
/** List CSP HTTP Headers */<br />
private List<String> cspHeaders = new ArrayList<String>();<br />
<br />
/** Collection of CSP polcies that will be applied */<br />
private String policies = null;<br />
<br />
/** Used for Script Nonce */<br />
private SecureRandom prng = null;<br />
<br />
/**<br />
* Used to prepare (one time for all) set of CSP policies that will be applied on each HTTP response.<br />
* <br />
* @see javax.servlet.Filter#init(javax.servlet.FilterConfig)<br />
*/<br />
@Override<br />
public void init(FilterConfig fConfig) throws ServletException {<br />
// Get filter configuration<br />
this.filterConfig = fConfig;<br />
<br />
// Init secure random<br />
try {<br />
this.prng = SecureRandom.getInstance("SHA1PRNG");<br />
}<br />
catch (NoSuchAlgorithmException e) {<br />
throw new ServletException(e);<br />
}<br />
<br />
// Define list of CSP HTTP Headers<br />
this.cspHeaders.add("Content-Security-Policy");<br />
this.cspHeaders.add("X-Content-Security-Policy");<br />
this.cspHeaders.add("X-WebKit-CSP");<br />
<br />
// Define CSP policies<br />
// Loading policies for Frame and Sandboxing will be dynamically defined : We need to know if context use Frame<br />
List<String> cspPolicies = new ArrayList<String>();<br />
String originLocationRef = "'self'";<br />
// --Disable default source in order to avoid browser fallback loading using 'default-src' locations<br />
cspPolicies.add("default-src 'none'");<br />
// --Define loading policies for Scripts<br />
cspPolicies.add("script-src " + originLocationRef + " 'unsafe-inline' 'unsafe-eval'");<br />
if (INCLUDE_MOZILLA_CSP_DIRECTIVES) {<br />
cspPolicies.add("options inline-script eval-script");<br />
cspPolicies.add("xhr-src 'self'");<br />
}<br />
// --Define loading policies for Plugins<br />
cspPolicies.add("object-src " + originLocationRef);<br />
// --Define loading policies for Styles (CSS)<br />
cspPolicies.add("style-src " + originLocationRef);<br />
// --Define loading policies for Images<br />
cspPolicies.add("img-src " + originLocationRef);<br />
// --Define loading policies for Form<br />
cspPolicies.add("form-action " + originLocationRef);<br />
// --Define loading policies for Audios/Videos<br />
if (APP_USE_AUDIOS_OR_VIDEOS) {<br />
cspPolicies.add("media-src " + originLocationRef);<br />
}<br />
// --Define loading policies for Fonts<br />
if (APP_USE_WEBFONTS) {<br />
cspPolicies.add("font-src " + originLocationRef);<br />
}<br />
// --Define loading policies for Connection<br />
cspPolicies.add("connect-src " + originLocationRef);<br />
// --Define loading policies for Plugins Types<br />
cspPolicies.add("plugin-types application/pdf application/x-shockwave-flash");<br />
// --Define browser XSS filtering feature running mode<br />
cspPolicies.add("reflected-xss block");<br />
<br />
// Target formating<br />
this.policies = cspPolicies.toString().replaceAll("(\\[|\\])", "").replaceAll(",", ";").trim();<br />
}<br />
<br />
/**<br />
* Add CSP policies on each HTTP response.<br />
* <br />
* @see javax.servlet.Filter#doFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse, javax.servlet.FilterChain)<br />
*/<br />
@Override<br />
public void doFilter(ServletRequest request, ServletResponse response, FilterChain fchain) throws IOException, ServletException {<br />
HttpServletRequest httpRequest = ((HttpServletRequest) request);<br />
HttpServletResponse httpResponse = ((HttpServletResponse) response);<br />
<br />
/* Step 1 : Detect if target resource is a Frame */<br />
// Customize here according to your context...<br />
boolean isFrame = true;<br />
<br />
/* Step 2 : Add CSP policies to HTTP response */<br />
StringBuilder policiesBuffer = new StringBuilder(this.policies);<br />
<br />
// If resource is a frame add Frame/Sandbox CSP policy<br />
if (isFrame) {<br />
// Frame + Sandbox : Here sandbox allow nothing, customize sandbox options depending on your app....<br />
policiesBuffer.append(";").append("frame-src 'self';sandbox");<br />
if (INCLUDE_MOZILLA_CSP_DIRECTIVES) {<br />
policiesBuffer.append(";").append("frame-ancestors 'self'");<br />
}<br />
}<br />
<br />
// Add Script Nonce CSP Policy<br />
// --Generate a random number<br />
String randomNum = new Integer(this.prng.nextInt()).toString();<br />
// --Get its digest<br />
MessageDigest sha;<br />
try {<br />
sha = MessageDigest.getInstance("SHA-1");<br />
}<br />
catch (NoSuchAlgorithmException e) {<br />
throw new ServletException(e);<br />
}<br />
byte[] digest = sha.digest(randomNum.getBytes());<br />
// --Encode it into HEXA<br />
String scriptNonce = Hex.encodeHexString(digest);<br />
policiesBuffer.append(";").append("script-nonce ").append(scriptNonce);<br />
// --Made available script nonce in view app layer<br />
httpRequest.setAttribute("CSP_SCRIPT_NONCE", scriptNonce);<br />
<br />
// Add policies to all HTTP headers<br />
for (String header : this.cspHeaders) {<br />
httpResponse.setHeader(header, policiesBuffer.toString());<br />
}<br />
<br />
/* Step 3 : Let request continue chain filter */<br />
fchain.doFilter(request, response);<br />
}<br />
<br />
/**<br />
* {@inheritDoc}<br />
* <br />
* @see javax.servlet.Filter#destroy()<br />
*/<br />
@Override<br />
public void destroy() {<br />
// Not used<br />
}<br />
}<br />
<br />
</pre><br />
<br />
== Tools ==<br />
<br />
[[Automated Audit using w3af|w3af]] audit tools (http://w3af.org) contain [https://github.com/andresriancho/w3af/blob/master/plugins/grep/csp.py plugin] to automatically audit web application to check if they correctly implement CSP policies. <br />
<br />
<pre style="color:#088A08"><br />
It's very useful to include this type of tools into a web application development process in order to <br />
perform a regular automatic first level check (do not replace an manual audit and manual audit must be also conducted regularly).<br />
</pre><br />
<br />
You can also use [https://www.oxdef.info/csp-tester CSP Tester (browser extension)] to build and test the policy for your web application.<br />
<br />
== Information links ==<br />
* W3C Specifications: CSP 1.0 - http://www.w3.org/TR/CSP, CSP 1.1 - http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html<br />
* Introduction to CSP: http://www.html5rocks.com/en/tutorials/security/content-security-policy<br />
* CSP browser support: http://caniuse.com/#feat=contentsecuritypolicy<br />
* CSP readiness browser testing: http://erlend.oftedal.no/blog/csp/readiness/<br />
<br />
[[Category:Java]]<br />
[[Category: Injection]]<br />
[[Category:Attack]]<br />
[[Category:Injection Attack]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=PL/SQL_Security_Cheat_Sheet&diff=229194PL/SQL Security Cheat Sheet2017-04-27T13:45:24Z<p>Pawel Krawczyk: REGEXP_LIKE + DBMS_ASSERT</p>
<hr />
<div>PL/SQL is a powerful procedural language built on top of Oracle SQL syntax. Extensive library of business-related and data-processing functions it incorporates makes it an attractive environment for building business-critical applications operating fully within the Oracle database. Introduction of PL/SQL Web Toolkit enabled Oracle developers to generate HTML straight from the PL/SQL code and build web applications fully residing from within the Oracle database.<br />
<br />
Just as any other web stack, PL/SQL web applications require careful input validation and other standard safeguards to prevent exploitable [[OWASP Top 10]] vulnerabilities. Oracle <code>htp</code> (hypertext procedures) and <code>htf</code> (hypertext functions) packages contain the primary functions for generating output in PL/SQL web applications as well as output escaping functions. See [https://docs.oracle.com/cd/B14099_19/web.1012/b15896/pshtp.htm Oracle: The htp and htf Packages]<br />
<br />
==Escaping output data to prevent Cross-Site Scripting==<br />
Applications running on newer Oracle versions where APEX packages are available should use <code>apex_escape</code> for contextual escaping of output data in a manner similar to [[ESAPI]] validators. See [https://docs.oracle.com/database/121/AEAPI/apex_escape.htm Oracle: apex_escape]<br />
<br />
* APEX_ESCAPE.HTML<br />
* APEX_ESCAPE.HTML_ATTRIBUTE <br />
* APEX_ESCAPE.HTML_TRUNC<br />
* APEX_ESCAPE.HTML_WHITELIST<br />
* APEX_ESCAPE.JS_LITERAL<br />
* APEX_ESCAPE.LDAP_DN<br />
* APEX_ESCAPE.LDAP_SEARCH_FILTER<br />
* APEX_ESCAPE.NOOP<br />
<br />
Applications should use <code>htp.prints</code> to output text blocks rather than <code>htp.print</code> as the former escapes potentially dangerous characters (<code><>"'</code>). Note that the <code>htp.prints</code> cannot be used as a simple drop-in replacement for <code>htp.print</code> because it will also escape legitimate HTML but by <code>htp</code> usage model raw HTML shouldn't be generally entered in strings but rather generated with appropriate HTML functions (e.g. <code>htp.header(1, 'Hello');</code> will output <code>&lt;H1&gt;Hello&lt;/H1&gt;</code>).<br />
<br />
Sample usage in typical PL/SQL code:<br />
<br />
htp.header(1, 'Details for user ' || apex_escape.html(username)); -- outputs &lt;H1&gt;...&lt;/H1&gt;<br />
htp.print('Username: '); -- just a string literal, no need to escape<br />
htp.italic(apex_escape.html(username), 'class=' || apex_escape.html_attribute(userclass) );<br />
htp.para();<br />
htp.prints(address); -- escapes dangerous chars in address string<br />
htp.script ('var username="' || apex_escape.js_literal(username) || '";');<br />
<br />
On older Oracle platforms <code>htf.escape_sc</code> for output in HTML context can be used and the <code>utl_url.escape</code> function is available to escape URL characters (<code>&"<>%</code>). URL escaping functionality is also provided by legacy <code>htf.escape_url</code> function. These functions are generally less robust than their <code>apex_escape</code> equivalents and not context-aware.<br />
<br />
==Input validation and sanitization==<br />
===Regular expression functions===<br />
IF REGEXP_LIKE('untrusted input', '^[0-9a-zA-z]{2,6}$') THEN /* Match */ ELSE /* No match */ END IF;<br />
select REGEXP_REPLACE('subject<<>>', '[<>]') from dual; -- returns: "subject"<br />
<br />
<br />
===DBMS_ASSERT===<br />
* ENQUOTE_LITERAL — Enquotes a string literal<br />
* ENQUOTE_NAME — Encloses a name in double quotes<br />
* NOOP — Returns the unmodified value<br />
* QUALIFIED_SQL_NAME — Verifies that the input string is a qualified SQL name<br />
* SCHEMA_NAME — Verifies that the input string is an existing schema name<br />
* SIMPLE_SQL_NAME — Verifies that the input string is a simple SQL name<br />
* SQL_OBJECT_NAME — Verifies that the input parameter string is a qualified SQL identifier of an existing SQL object<br />
<br />
Example:<br />
<br />
SELECT SYS.DBMS_ASSERT.SIMPLE_SQL_NAME ('Data with <invalid> characters') FROM dual;<br />
ORA-44003: invalid SQL name<br />
<br />
See [https://docs.oracle.com/database/121/ARPLS/d_assert.htm#ARPLS231 Oracle: DBMS_ASSERT]<br />
<br />
==References==<br />
* [http://www.oracle.com/technetwork/database/features/plsql/overview/how-to-write-injection-proof-plsql-1-129572.pdf Oracle "How to write SQL injection proof PL/SQL"]<br />
* [http://www.oracle.com/technetwork/developer-tools/adf/adfowasptop10-final-2348304.pdf Security in Oracle ADF: Addressing the OWASP Top 10 Security Vulnerabilities]<br />
<br />
==Authors==<br />
* Pawel Krawczyk<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=PL/SQL_Security_Cheat_Sheet&diff=229189PL/SQL Security Cheat Sheet2017-04-27T13:03:02Z<p>Pawel Krawczyk: </p>
<hr />
<div>PL/SQL is a powerful procedural language built on top of Oracle SQL syntax. Extensive library of business-related and data-processing functions it incorporates makes it an attractive environment for building business-critical applications operating fully within the Oracle database. Introduction of PL/SQL Web Toolkit enabled Oracle developers to generate HTML straight from the PL/SQL code and build web applications fully residing from within the Oracle database.<br />
<br />
Just as any other web stack, PL/SQL web applications require careful input validation and other standard safeguards to prevent exploitable [[OWASP Top 10]] vulnerabilities. Oracle <code>htp</code> (hypertext procedures) and <code>htf</code> (hypertext functions) packages contain the primary functions for generating output in PL/SQL web applications as well as output escaping functions. See [https://docs.oracle.com/cd/B14099_19/web.1012/b15896/pshtp.htm Oracle: The htp and htf Packages]<br />
<br />
==Escaping output data to prevent Cross-Site Scripting==<br />
Applications running on newer Oracle versions where APEX packages are available should use <code>apex_escape</code> for contextual escaping of output data in a manner similar to [[ESAPI]] validators. See [https://docs.oracle.com/database/121/AEAPI/apex_escape.htm Oracle: apex_escape]<br />
<br />
* APEX_ESCAPE.HTML<br />
* APEX_ESCAPE.HTML_ATTRIBUTE <br />
* APEX_ESCAPE.HTML_TRUNC<br />
* APEX_ESCAPE.HTML_WHITELIST<br />
* APEX_ESCAPE.JS_LITERAL<br />
* APEX_ESCAPE.LDAP_DN<br />
* APEX_ESCAPE.LDAP_SEARCH_FILTER<br />
* APEX_ESCAPE.NOOP<br />
<br />
Applications should use <code>htp.prints</code> to output text blocks rather than <code>htp.print</code> as the former escapes potentially dangerous characters (<code><>"'</code>). Note that the <code>htp.prints</code> cannot be used as a simple drop-in replacement for <code>htp.print</code> because it will also escape legitimate HTML but by <code>htp</code> usage model raw HTML shouldn't be generally entered in strings but rather generated with appropriate HTML functions (e.g. <code>htp.header(1, 'Hello');</code> will output <code>&lt;H1&gt;Hello&lt;/H1&gt;</code>).<br />
<br />
Sample usage in typical PL/SQL code:<br />
<br />
htp.header(1, 'Details for user ' || apex_escape.html(username)); -- outputs &lt;H1&gt;...&lt;/H1&gt;<br />
htp.print('Username: '); -- just a string literal, no need to escape<br />
htp.italic(apex_escape.html(username), 'class=' || apex_escape.html_attribute(userclass) );<br />
htp.para();<br />
htp.prints(address); -- escapes dangerous chars in address string<br />
htp.script ('var username="' || apex_escape.js_literal(username) || '";');<br />
<br />
On older Oracle platforms <code>htf.escape_sc</code> for output in HTML context can be used and the <code>utl_url.escape</code> function is available to escape URL characters (<code>&"<>%</code>). URL escaping functionality is also provided by legacy <code>htf.escape_url</code> function. These functions are generally less robust than their <code>apex_escape</code> equivalents and not context-aware.<br />
<br />
==Authors==<br />
* Pawel Krawczyk<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=PL/SQL_Security_Cheat_Sheet&diff=229186PL/SQL Security Cheat Sheet2017-04-27T10:48:45Z<p>Pawel Krawczyk: </p>
<hr />
<div>PL/SQL is a powerful procedural language built on top of Oracle SQL syntax. Extensive library of business-related and data-processing functions it incorporates makes it an attractive environment for building business-critical applications operating fully within the Oracle database. Introduction of PL/SQL Web Toolkit enabled Oracle developers to generate HTML straight from the PL/SQL code and build web applications fully residing from within the Oracle database.<br />
<br />
Just as any other web stack, PL/SQL web applications require careful input validation and other standard safeguards to prevent exploitable [[OWASP Top 10]] vulnerabilities. Oracle <code>htp</code> (hypertext procedures) and <code>htf</code> (hypertext functions) packages contain the primary functions for generating output in PL/SQL web applications as well as output escaping functions. See [https://docs.oracle.com/cd/B14099_19/web.1012/b15896/pshtp.htm Oracle: The htp and htf Packages]<br />
<br />
==Escaping==<br />
Applications running on newer Oracle versions where APEX packages are available should use <code>apex_escape</code> for contextual escaping of output data in a manner similar to [[ESAPI]] validators. See [https://docs.oracle.com/database/121/AEAPI/apex_escape.htm Oracle: apex_escape]<br />
<br />
* APEX_ESCAPE.HTML<br />
* APEX_ESCAPE.HTML_ATTRIBUTE <br />
* APEX_ESCAPE.HTML_TRUNC<br />
* APEX_ESCAPE.HTML_WHITELIST<br />
* APEX_ESCAPE.JS_LITERAL<br />
* APEX_ESCAPE.LDAP_DN<br />
* APEX_ESCAPE.LDAP_SEARCH_FILTER<br />
* APEX_ESCAPE.NOOP<br />
<br />
Applications should use <code>htp.prints</code> to output text blocks rather than <code>htp.print</code> as the former escapes potentially dangerous characters (<code><>"'</code>). Note that the <code>htp.prints</code> cannot be used as a simple drop-in replacement for <code>htp.print</code> because it will also escape legitimate HTML but by <code>htp</code> usage model raw HTML shouldn't be generally entered in strings but rather generated with appropriate HTML functions (e.g. <code>htp.header(1, 'Hello');</code> will output <code>&lt;H1&gt;Hello&lt;/H1&gt;</code>).<br />
<br />
Sample usage in typical PL/SQL code:<br />
<br />
htp.header(1, 'Details for user ' || apex_escape.html(username)); -- outputs &lt;H1&gt;...&lt;/H1&gt;<br />
htp.print('Username: '); -- just a string literal, no need to escape<br />
htp.italic(apex_escape.html(username), 'class=' || apex_escape.html_attribute(userclass) );<br />
htp.para();<br />
htp.prints(address); -- escapes dangerous chars in address string<br />
htp.script ('var username="' || apex_escape.js_literal(username) || '";');<br />
<br />
On older Oracle platforms <code>htf.escape_sc</code> for output in HTML context can be used and the <code>utl_url.escape</code> function is available to escape URL characters (<code>&"<>%</code>). URL escaping functionality is also provided by legacy <code>htf.escape_url</code> function. These functions are generally less robust than their <code>apex_escape</code> equivalents and not context-aware.<br />
<br />
==Authors==<br />
* Pawel Krawczyk<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=PL/SQL_Security_Cheat_Sheet&diff=229185PL/SQL Security Cheat Sheet2017-04-27T10:48:26Z<p>Pawel Krawczyk: </p>
<hr />
<div>PL/SQL is a powerful procedural language built on top of Oracle SQL syntax. Extensive library of business-related and data-processing functions it incorporates makes it an attractive environment for building business-critical applications operating fully within the Oracle database. Introduction of PL/SQL Web Toolkit enabled Oracle developers to generate HTML straight from the PL/SQL code and build web applications fully residing from within the Oracle database.<br />
<br />
Just as any other web stack, PL/SQL web applications require careful input validation and other standard safeguards to prevent exploitable [[OWASP Top 10]] vulnerabilities. Oracle <code>htp</code> (hypertext procedures) and <code>htf</code> (hypertext functions) packages contain the primary functions for generating output in PL/SQL web applications as well as output escaping functions. See [https://docs.oracle.com/cd/B14099_19/web.1012/b15896/pshtp.htm Oracle: The htp and htf Packages]<br />
<br />
==Escaping==<br />
Applications running on newer Oracle versions where APEX packages are available should use <code>apex_escape</code> for contextual escaping of output data in a manner similar to [[ESAPI]] validators. See [https://docs.oracle.com/database/121/AEAPI/apex_escape.htm Oracle: apex_escape]<br />
<br />
* APEX_ESCAPE.HTML<br />
* APEX_ESCAPE.HTML_ATTRIBUTE <br />
* APEX_ESCAPE.HTML_TRUNC<br />
* APEX_ESCAPE.HTML_WHITELIST<br />
* APEX_ESCAPE.JS_LITERAL<br />
* APEX_ESCAPE.LDAP_DN<br />
* APEX_ESCAPE.LDAP_SEARCH_FILTER<br />
* APEX_ESCAPE.NOOP<br />
<br />
Applications should use <code>htp.prints</code> to output text blocks rather than <code>htp.print</code> as the former escapes potentially dangerous characters (<code><>"'</code>). Note that the <code>htp.prints</code> cannot be used as a simple drop-in replacement for <code>htp.print</code> because it will also escape legitimate HTML but by <code>htp</code> usage model raw HTML shouldn't be generally entered in strings but rather generated with appropriate HTML functions (e.g. <code>htp.header(1, 'Hello');</code> will output <code>&lt;H1&gt;Hello&lt;/H1&gt;</code>).<br />
<br />
Sample usage in typical PL/SQL code:<br />
<br />
htp.header(1, 'Details for user ' || apex_escape.html(username)); -- outputs &lt;H1&gt;...&lt;/H1&gt;<<br />
htp.print('Username: '); -- just a string literal, no need to escape<br />
htp.italic(apex_escape.html(username), 'class=' || apex_escape.html_attribute(userclass) );<br />
htp.para();<br />
htp.prints(address); -- escapes dangerous chars in address string<br />
htp.script ('var username="' || apex_escape.js_literal(username) || '";');<br />
<br />
On older Oracle platforms <code>htf.escape_sc</code> for output in HTML context can be used and the <code>utl_url.escape</code> function is available to escape URL characters (<code>&"<>%</code>). URL escaping functionality is also provided by legacy <code>htf.escape_url</code> function. These functions are generally less robust than their <code>apex_escape</code> equivalents and not context-aware.<br />
<br />
==Authors==<br />
* Pawel Krawczyk<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=PL/SQL_Security_Cheat_Sheet&diff=229184PL/SQL Security Cheat Sheet2017-04-27T10:46:11Z<p>Pawel Krawczyk: </p>
<hr />
<div>PL/SQL is a powerful procedural language built on top of Oracle SQL syntax. Extensive library of business-related and data-processing functions it incorporates makes it an attractive environment for building business-critical applications operating fully within the Oracle database. Introduction of PL/SQL Web Toolkit enabled Oracle developers to generate HTML straight from the PL/SQL code and build web applications fully residing from within the Oracle database.<br />
<br />
Just as any other web stack, PL/SQL web applications require careful input validation and other standard safeguards to prevent exploitable [[OWASP Top 10]] vulnerabilities. Oracle <code>htp</code> (hypertext procedures) and <code>htf</code> (hypertext functions) packages contain the primary functions for generating output in PL/SQL web applications as well as output escaping functions. [https://docs.oracle.com/cd/B14099_19/web.1012/b15896/pshtp.htm Oracle: The htp and htf Packages]<br />
<br />
==Escaping==<br />
Applications running on newer Oracle versions where APEX packages are available should use <code>apex_escape</code> for contextual escaping of output data in a manner similar to [[ESAPI]] validators. [https://docs.oracle.com/database/121/AEAPI/apex_escape.htm Oracle: apex_escape]<br />
<br />
* APEX_ESCAPE.HTML<br />
* APEX_ESCAPE.HTML_ATTRIBUTE <br />
* APEX_ESCAPE.HTML_TRUNC<br />
* APEX_ESCAPE.HTML_WHITELIST<br />
* APEX_ESCAPE.JS_LITERAL<br />
* APEX_ESCAPE.LDAP_DN<br />
* APEX_ESCAPE.LDAP_SEARCH_FILTER<br />
* APEX_ESCAPE.NOOP<br />
<br />
Applications running on older versions of Oracle may use <code>htp.prints</code> to output text blocks rather than <code>htp.print</code> as the former escapes potentially dangerous characters (<code><>"'</code>). Note that the <code>htp.prints</code> cannot be used as a simple drop-in replacement for <code>htp.print</code> because it will also escape legitimate HTML but by <code>htp</code> usage model raw HTML shouldn't be generally entered in strings but rather generated with appropriate HTML functions (e.g. <code>htp.header(1, 'Hello');</code> will output <code>&lt;H1&gt;Hello&lt;/H1&gt;</code>).<br />
<br />
Sample usage in typical PL/SQL code:<br />
<br />
htp.header(1, 'Details for user ' || apex_escape.html(username));<br />
htp.print('Username: '); -- just a string literal, no need to escape<br />
htp.italic(apex_escape.html(username), 'class=' || apex_escape.html_attribute(userclass) );<br />
htp.para();<br />
htp.prints(address); -- escapes dangerous chars in address string<br />
htp.script ('var username="' || apex_escape.js_literal(username) || '";');<br />
<br />
On older Oracle platforms <code>htf.escape_sc</code> for output in HTML context can be used and the <code>utl_url.escape</code> function is available to escape URL characters (<code>&"<>%</code>). URL escaping functionality is also provided by legacy <code>htf.escape_url</code> function. These functions are generally less robust than their <code>apex_escape</code> equivalents and not context-aware.<br />
<br />
==Authors==<br />
* Pawel Krawczyk<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=PL/SQL_Security_Cheat_Sheet&diff=229183PL/SQL Security Cheat Sheet2017-04-27T10:43:18Z<p>Pawel Krawczyk: more samples</p>
<hr />
<div>PL/SQL is a powerful procedural language built on top of Oracle SQL syntax. Extensive library of business-related and data-processing functions it incorporates makes it an attractive environment for building business-critical applications operating fully within the Oracle database. Introduction of PL/SQL Web Toolkit enabled Oracle developers to generate HTML straight from the PL/SQL code and build web applications fully residing from within the Oracle database.<br />
<br />
Just as any other web stack, PL/SQL web applications require careful input validation and other standard safeguards to prevent exploitable [[OWASP Top 10]] vulnerabilities. Oracle <code>htp</code> (hypertext procedures) and <code>htf</code> (hypertext functions) packages contain the primary functions for generating output in PL/SQL web applications as well as output escaping functions. [https://docs.oracle.com/cd/B14099_19/web.1012/b15896/pshtp.htm Oracle: The htp and htf Packages]<br />
<br />
==Escaping==<br />
Applications running on newer Oracle versions where APEX packages are available should use <code>apex_escape</code> for contextual escaping of output data in a manner similar to [[ESAPI]] validators. [https://docs.oracle.com/database/121/AEAPI/apex_escape.htm Oracle: apex_escape]<br />
<br />
* APEX_ESCAPE.HTML<br />
* APEX_ESCAPE.HTML_ATTRIBUTE <br />
* APEX_ESCAPE.HTML_TRUNC<br />
* APEX_ESCAPE.HTML_WHITELIST<br />
* APEX_ESCAPE.JS_LITERAL<br />
* APEX_ESCAPE.LDAP_DN<br />
* APEX_ESCAPE.LDAP_SEARCH_FILTER<br />
* APEX_ESCAPE.NOOP<br />
<br />
Applications running on older versions of Oracle may use <code>htp.prints</code> to output text blocks rather than <code>htp.print</code> as the former escapes potentially dangerous characters (<code><>"'</code>). Note that the <code>htp.prints</code> cannot be used as a simple drop-in replacement for <code>htp.print</code> because it will also escape legitimate HTML but by <code>htp</code> usage model raw HTML shouldn't be generally entered in strings but rather generated with appropriate HTML functions (e.g. <code>htp.header(1, 'Hello');</code> will output <code>&lt;H1&gt;Hello&lt;/H1&gt;</code>).<br />
<br />
Sample usage in typical PL/SQL code:<br />
<br />
htp.header(1, 'Details for user ' || apex_escape.html(username));<br />
htp.print('<li>Username: ' || htp.italic(apex_escape.html(username), 'class=' || apex_escape.html_attribute(userclass) );<br />
htp.prints(address);<br />
htp.script ('var username="' || apex_escape.js_literal(username) || '";');<br />
<br />
On older Oracle platforms <code>htf.escape_sc</code> for output in HTML context can be used and the <code>utl_url.escape</code> function is available to escape URL characters (<code>&"<>%</code>). URL escaping functionality is also provided by legacy <code>htf.escape_url</code> function. These functions are generally less robust than their <code>apex_escape</code> equivalents.<br />
<br />
==Authors==<br />
* Pawel Krawczyk<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=PL/SQL_Security_Cheat_Sheet&diff=229182PL/SQL Security Cheat Sheet2017-04-27T10:38:22Z<p>Pawel Krawczyk: </p>
<hr />
<div>PL/SQL is a powerful procedural language built on top of Oracle SQL syntax. Extensive library of business-related and data-processing functions it incorporates makes it an attractive environment for building business-critical applications operating fully within the Oracle database. Introduction of PL/SQL Web Toolkit enabled Oracle developers to generate HTML straight from the PL/SQL code and build web applications fully residing from within the Oracle database.<br />
<br />
Just as any other web stack, PL/SQL web applications require careful input validation and other standard safeguards to prevent exploitable [[OWASP Top 10]] vulnerabilities. Oracle <code>htp</code> (hypertext procedures) and <code>htf</code> (hypertext functions) packages contain the primary functions for generating output in PL/SQL web applications as well as output escaping functions. [https://docs.oracle.com/cd/B14099_19/web.1012/b15896/pshtp.htm Oracle: The htp and htf Packages]<br />
<br />
==Escaping==<br />
Applications running on newer Oracle versions where APEX packages are available should use <code>apex_escape</code> for contextual escaping of output data in a manner similar to [[ESAPI]] validators. [https://docs.oracle.com/database/121/AEAPI/apex_escape.htm Oracle: apex_escape]<br />
<br />
* APEX_ESCAPE.HTML<br />
* APEX_ESCAPE.HTML_ATTRIBUTE <br />
* APEX_ESCAPE.HTML_TRUNC<br />
* APEX_ESCAPE.HTML_WHITELIST<br />
* APEX_ESCAPE.JS_LITERAL<br />
* APEX_ESCAPE.LDAP_DN<br />
* APEX_ESCAPE.LDAP_SEARCH_FILTER<br />
* APEX_ESCAPE.NOOP<br />
<br />
Applications running on older versions of Oracle may use <code>htp.prints</code> to output text blocks rather than <code>htp.print</code> as the former escapes potentially dangerous characters (<code><>"'</code>). Note that the <code>htp.prints</code> cannot be used as a simple drop-in replacement for <code>htp.print</code> because it will also escape legitimate HTML but by <code>htp</code> usage model raw HTML shouldn't be generally entered in strings but rather generated with appropriate HTML functions (e.g. <code>htp.header(1, 'Hello');</code> will output <code>&lt;H1&gt;Hello&lt;/H1&gt;</code>).<br />
<br />
Sample usage in typical PL/SQL code:<br />
<br />
htp.print('Username: ' || apex_escape.html(username));<br />
htp.prints(address)<br />
htp.script ('var username="' || apex_escap.js_literal(username) || '";');<br />
<br />
On older Oracle platforms <code>htf.escape_sc</code> for output in HTML context can be used and the <code>utl_url.escape</code> function is available to escape URL characters (<code>&"<>%</code>). URL escaping functionality is also provided by legacy <code>htf.escape_url</code> function. These functions are generally less robust than their <code>apex_escape</code> equivalents.<br />
<br />
==Authors==<br />
* Pawel Krawczyk<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=PL/SQL_Security_Cheat_Sheet&diff=229181PL/SQL Security Cheat Sheet2017-04-27T10:37:51Z<p>Pawel Krawczyk: code sample</p>
<hr />
<div>PL/SQL is a powerful procedural language built on top of Oracle SQL syntax. Extensive library of business-related and data-processing functions it incorporates makes it an attractive environment for building business-critical applications operating fully within the Oracle database. Introduction of PL/SQL Web Toolkit enabled Oracle developers to generate HTML straight from the PL/SQL code and build web applications fully residing from within the Oracle database.<br />
<br />
Just as any other web stack, PL/SQL web applications require careful input validation and other standard safeguards to prevent exploitable [[OWASP Top 10]] vulnerabilities. Oracle <code>htp</code> (hypertext procedures) and <code>htf</code> (hypertext functions) packages contain the primary functions for generating output in PL/SQL web applications as well as output escaping functions. [https://docs.oracle.com/cd/B14099_19/web.1012/b15896/pshtp.htm Oracle: The htp and htf Packages]<br />
<br />
==Escaping==<br />
Applications running on newer Oracle versions where APEX packages are available should use <code>apex_escape</code> for contextual escaping of output data in a manner similar to [[ESAPI]] validators. [https://docs.oracle.com/database/121/AEAPI/apex_escape.htm Oracle: apex_escape]<br />
<br />
* APEX_ESCAPE.HTML<br />
* APEX_ESCAPE.HTML_ATTRIBUTE <br />
* APEX_ESCAPE.HTML_TRUNC<br />
* APEX_ESCAPE.HTML_WHITELIST<br />
* APEX_ESCAPE.JS_LITERAL<br />
* APEX_ESCAPE.LDAP_DN<br />
* APEX_ESCAPE.LDAP_SEARCH_FILTER<br />
* APEX_ESCAPE.NOOP<br />
<br />
Applications running on older versions of Oracle may use <code>htp.prints</code> to output text blocks rather than <code>htp.print</code> as the former escapes potentially dangerous characters (<code><>"'</code>). Note that the <code>htp.prints</code> cannot be used as a simple drop-in replacement for <code>htp.print</code> because it will also escape legitimate HTML but by <code>htp</code> usage model raw HTML shouldn't be generally entered in strings but rather generated with appropriate HTML functions (e.g. <code>htp.header(1, 'Hello');</code> will output <code>&lt;H1&gt;Hello&lt;/H1&gt;</code>).<br />
<br />
Sample usage in typical PL/SQL code:<br />
<br />
htp.print('<b>User' || apex_escape.html(username) || '</b>');<br />
htp.prints(address)<br />
htp.script ('var username="' || apex_escap.js_literal(username) || '";');<br />
<br />
On older Oracle platforms <code>htf.escape_sc</code> for output in HTML context can be used and the <code>utl_url.escape</code> function is available to escape URL characters (<code>&"<>%</code>). URL escaping functionality is also provided by legacy <code>htf.escape_url</code> function. These functions are generally less robust than their <code>apex_escape</code> equivalents.<br />
<br />
==Authors==<br />
* Pawel Krawczyk<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=PL/SQL_Security_Cheat_Sheet&diff=229180PL/SQL Security Cheat Sheet2017-04-27T09:53:32Z<p>Pawel Krawczyk: initial version</p>
<hr />
<div>PL/SQL is a powerful procedural language built on top of Oracle SQL syntax. Extensive library of business-related and data-processing functions it incorporates makes it an attractive environment for building business-critical applications operating fully within the Oracle database. Introduction of PL/SQL Web Toolkit enabled Oracle developers to generate HTML straight from the PL/SQL code and build web applications fully residing from within the Oracle database.<br />
<br />
Just as any other web stack, PL/SQL web applications require careful input validation and other standard safeguards to prevent exploitable [[OWASP Top 10]] vulnerabilities. Oracle `htp` (hypertext procedures) and `htf` (hypertext functions) packages contain the primary functions for generating output in PL/SQL web applications as well as output escaping functions. [https://docs.oracle.com/cd/B14099_19/web.1012/b15896/pshtp.htm Oracle: The htp and htf Packages]<br />
<br />
==Escaping==<br />
Applications running on newer Oracle versions where APEX packages are available should use `apex_escape` for contextual escaping of output data in a manner similar to [[ESAPI]] validators. [https://docs.oracle.com/database/121/AEAPI/apex_escape.htm Oracle: apex_escape]<br />
<br />
* APEX_ESCAPE.HTML<br />
* APEX_ESCAPE.HTML_ATTRIBUTE <br />
* APEX_ESCAPE.HTML_TRUNC<br />
* APEX_ESCAPE.HTML_WHITELIST<br />
* APEX_ESCAPE.JS_LITERAL<br />
* APEX_ESCAPE.LDAP_DN<br />
* APEX_ESCAPE.LDAP_SEARCH_FILTER<br />
* APEX_ESCAPE.NOOP<br />
<br />
Applications running on older versions of Oracle may use '''htp.prints''' to output text blocks rather than '''htp.print''' as the former escapes potentially dangerous characters (`<>"'`). <br />
<br />
For escaping individual data fields `htf.escape_sc` for output in HTML context should be used. The `utl_url.escape` function is available to escape URL characters (`&"<>%`). URL escaping functionality is also provided by legacy `htf.escape_url` function but it's less robust.<br />
<br />
==Authors==<br />
* Pawel Krawczyk<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=SQL_Injection_Prevention_Cheat_Sheet&diff=229179SQL Injection Prevention Cheat Sheet2017-04-27T08:45:42Z<p>Pawel Krawczyk: /* Escaping SQLi in PhP */ typo</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
This article is focused on providing clear, simple, actionable guidance for preventing SQL Injection flaws in your applications. [[SQL Injection]] attacks are unfortunately very common, and this is due to two factors:<br />
<br />
# the significant prevalence of SQL Injection vulnerabilities, and <br />
# the attractiveness of the target (i.e., the database typically contains all the interesting/critical data for your application).<br />
<br />
It’s somewhat shameful that there are so many successful SQL Injection attacks occurring, because it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code.<br />
<br />
SQL Injection flaws are introduced when software developers create dynamic database queries that include user supplied input. To avoid SQL injection flaws is simple. Developers need to either:<br />
a) stop writing dynamic queries; and/or<br />
b) prevent user supplied input which contains malicious SQL from affecting the logic of the executed query.<br />
<br />
This article provides a set of simple techniques for preventing SQL Injection vulnerabilities by avoiding these two problems. These techniques can be used with practically any kind of programming language with any type of database. There are other types of databases, like XML databases, which can have similar problems (e.g., XPath and XQuery injection) and these techniques can be used to protect them as well.<br />
<br />
Primary Defenses:<br />
* '''Option #1: Use of Prepared Statements (Parameterized Queries)'''<br />
* '''Option #2: Use of Stored Procedures'''<br />
* '''Option #3: Escaping all User Supplied Input'''<br />
<br />
Additional Defenses:<br />
* '''Also Enforce: Least Privilege'''<br />
* '''Also Perform: White List Input Validation'''<br />
<br><br />
;Unsafe Example<br />
<br />
SQL injection flaws typically look like this:<br />
<br />
The following (Java) example is UNSAFE, and would allow an attacker to inject code into the query that would be executed by the database. The unvalidated “customerName” parameter that is simply appended to the query allows an attacker to inject any SQL code they want. Unfortunately, this method for accessing databases is all too common.<br />
<br />
String query = "SELECT account_balance FROM user_data WHERE user_name = "<br />
+ request.getParameter("customerName");<br />
<br />
try {<br />
Statement statement = connection.createStatement( … );<br />
ResultSet results = statement.executeQuery( query );<br />
}<br />
<br />
=Primary Defenses=<br />
<br />
==Defense Option 1: Prepared Statements (with Parameterized Queries)==<br />
<br />
The use of prepared statements with variable binding (aka parameterized queries) is how all developers should first be taught how to write database queries. They are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.<br />
<br />
Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. In the safe example below, if an attacker were to enter the userID of tom' or '1'='1, the parameterized query would not be vulnerable and would instead look for a username which literally matched the entire string tom' or '1'='1.<br />
<br />
Language specific recommendations:<br />
* Java EE – use PreparedStatement() with bind variables<br />
* .NET – use parameterized queries like SqlCommand() or OleDbCommand() with bind variables<br />
* PHP – use PDO with strongly typed parameterized queries (using bindParam())<br />
* Hibernate - use createQuery() with bind variables (called named parameters in Hibernate)<br />
* SQLite - use sqlite3_prepare() to create a [http://www.sqlite.org/c3ref/stmt.html statement object]<br />
<br />
In rare circumstances, prepared statements can harm performance. When confronted with this situation, it is best to either a) strongly validate all data or b) escape all user supplied input using an escaping routine specific to your database vendor as described below, rather than using a prepared statement.<br />
<br />
;Safe Java Prepared Statement Example <br />
<br />
The following code example uses a PreparedStatement, Java's implementation of a parameterized query, to execute the same database query.<br />
<br />
String custname = request.getParameter("customerName"); // This should REALLY be validated too<br />
// perform input validation to detect attacks<br />
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";<br />
<br />
'''PreparedStatement pstmt = connection.prepareStatement( query );'''<br />
'''pstmt.setString( 1, custname); '''<br />
ResultSet results = pstmt.executeQuery( );<br />
<br />
;Safe C# .NET Prepared Statement Example <br />
<br />
With .NET, it's even more straightforward. The creation and execution of the query doesn't change. All you have to do is simply pass the parameters to the query using the Parameters.Add() call as shown here.<br />
<br />
String query = <br />
"SELECT account_balance FROM user_data WHERE user_name = ?";<br />
try {<br />
OleDbCommand command = new OleDbCommand(query, connection);<br />
'''command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));'''<br />
OleDbDataReader reader = command.ExecuteReader();<br />
// …<br />
} catch (OleDbException se) {<br />
// error handling<br />
} <br />
<br />
We have shown examples in Java and .NET but practically all other languages, including Cold Fusion, and Classic ASP, support parameterized query interfaces. Even SQL abstraction layers, like the [http://www.hibernate.org/ Hibernate Query Language] (HQL) have the same type of injection problems (which we call [http://cwe.mitre.org/data/definitions/564.html HQL Injection]). HQL supports parameterized queries as well, so we can avoid this problem:<br />
<br />
;Hibernate Query Language (HQL) Prepared Statement (Named Parameters) Examples <br />
<br />
First is an unsafe HQL Statement<br />
<br />
Query unsafeHQLQuery = session.createQuery("from Inventory where productID='"+userSuppliedParameter+"'");<br />
<br />
Here is a safe version of the same query using named parameters<br />
<br />
Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");<br />
safeHQLQuery.setParameter("productid", userSuppliedParameter);<br />
<br />
For examples of parameterized queries in other languages, including Ruby, PHP, Cold Fusion, and Perl, see the [[Query Parameterization Cheat Sheet]] or [http://bobby-tables.com/ http://bobby-tables.com/].<br />
<br />
Developers tend to like the Prepared Statement approach because all the SQL code stays within the application. This makes your application relatively database independent.<br />
<br />
== Defense Option 2: Stored Procedures ==<br />
<br />
Stored procedures are not always safe from SQL injection. However, certain standard stored procedure programming constructs have the same effect as the use of parameterized queries when implemented safely* which is the norm for most stored procedure languages. They require the developer to just build SQL statements with parameters which are automatically parameterized unless the developer does something largely out of the norm. The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Both of these techniques have the same effectiveness in preventing SQL injection so your organization should choose which approach makes the most sense for you.<br />
<br />
&#42;Note: 'Implemented safely' means the stored procedure does not include any unsafe dynamic SQL generation. Developers do not usually generate dynamic SQL inside stored procedures. However, it can be done, but should be avoided. If it can't be avoided, the stored procedure must use input validation or proper escaping as described in this article to make sure that all user supplied input to the stored procedure can't be used to inject SQL code into the dynamically generated query. Auditors should always look for uses of sp_execute, execute or exec within SQL Server stored procedures. Similar audit guidelines are necessary for similar functions for other vendors.<br />
<br />
There are also several cases where stored procedures can increase risk. For example, on MS SQL server, you have 3 main default roles: db_datareader, db_datawriter and db_owner. Before stored procedures came into use, DBA's would give db_datareader or db_datawriter rights to the webservice's user, depending on the requirements. However, stored procedures require execute rights, a role that is not available by default. Some setups where the user management has been centralized, but is limited to those 3 roles, cause all web apps to run under db_owner rights so stored procedures can work. Naturally, that means that if a server is breached the attacker has full rights to the database, where previously they might only have had read-access. More on this topic here. [http://www.sqldbatips.com/showarticle.asp?ID=8 http://www.sqldbatips.com/showarticle.asp?ID=8 ]<br />
<br />
;Safe Java Stored Procedure Example<br />
<br />
The following code example uses a CallableStatement, Java's implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.<br />
<br />
String custname = request.getParameter("customerName"); // This should REALLY be validated<br />
try {<br />
'''CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}");'''<br />
'''cs.setString(1, custname);'''<br />
ResultSet results = cs.executeQuery(); <br />
// … result set handling <br />
} catch (SQLException se) { <br />
// … logging and error handling<br />
}<br />
<br />
;Safe VB .NET Stored Procedure Example <br />
<br />
The following code example uses a SqlCommand, .NET’s implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.<br />
<br />
Try<br />
Dim command As SqlCommand = new SqlCommand("sp_getAccountBalance", connection)<br />
'''command.CommandType = CommandType.StoredProcedure'''<br />
'''command.Parameters.Add(new SqlParameter("@CustomerName", CustomerName.Text))'''<br />
Dim reader As SqlDataReader = command.ExecuteReader()<br />
‘ …<br />
Catch se As SqlException <br />
‘ error handling<br />
End Try<br />
<br />
== Defense Option 3: White List Input Validation ==<br />
<br />
Various parts of SQL queries aren't legal locations for the use of bind variables, such as the names of tables or columns, and the sort order indicator (ASC or DESC). In such situations, input validation or query redesign is the most appropriate defense. For the names of tables or columns, ideally those values come from the code, and not from user parameters. But if user parameter values are used to make different for table names and column names, then the parameter values should be mapped to the legal/expected table or column names to make sure unvalidated user input doesn't end up in the query. Please note, this is a symptom of poor design and a full re-write should be considered if time allows. Here is an example of table name validation.<br />
<br />
String tableName;<br />
switch(PARAM):<br />
case "Value1": tableName = "fooTable";<br />
break;<br />
case "Value2": tableName = "barTable";<br />
break;<br />
...<br />
default : throw new InputValidationException("unexpected value provided for table name");<br />
<br />
The tableName can then be directly appended to the SQL query since it is now known to be one of the legal and expected values for a table name in this query. Keep in mind that generic table validation functions can lead to data loss as table names are used in queries where they are not expected.<br />
<br />
For something simple like a sort order, it would be best if the user supplied input is converted to a boolean, and then that boolean is used to select the safe value to append to the query. This is a very standard need in dynamic query creation. For example:<br />
<br />
public String someMethod(boolean sortOrder) {<br />
<br />
String SQLquery = "some SQL ... order by Salary " + (sortOrder ? "ASC" : "DESC");<br />
...<br />
<br />
Any time user input can be converted to a non-String, like a date, numeric, boolean, enumerated type, etc. before it is appended to a query, or used to select a value to append to the query, this ensures it is safe to do so.<br />
<br />
Input validation is also recommended as a secondary defense in ALL cases, even when using bind variables as is discussed later in this article. More techniques on how to implement strong white list input validation is described in the [[Input Validation Cheat Sheet]].<br />
<br />
==Defense Option 4: Escaping All User Supplied Input==<br />
<br />
This technique should only be used as a last resort, when none of the above are feasible. Input validation is probably a better choice as this methodology is frail compared to other defenses and we cannot guarantee it will prevent all SQL Injection in all situations. <br />
<br />
This technique is to escape user input before putting it in a query. It is very database specific in its implementation. Its usually only recommended to retrofit legacy code when implementing input validation isn't cost effective. Applications built from scratch, or applications requiring low risk tolerance should be built or re-written using parameterized queries, stored procedures, or some kind of Object Relational Mapper (ORM) that builds your queries for you.<br />
<br />
This technique works like this. Each DBMS supports one or more character escaping schemes specific to certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection vulnerabilities.<br />
<br />
* Full details on [[ESAPI|ESAPI are available here on OWASP]].<br />
* The javadoc for [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html ESAPI is available here at its Google Code repository].<br />
* You can also directly [http://code.google.com/p/owasp-esapi-java/source/browse/#svn/trunk/src/main/java/org/owasp/esapi browse the source at Google], which is frequently helpful if the javadoc isn't perfectly clear.<br />
<br />
To find the javadoc specifically for the database encoders, click on the ‘Codec’ class on the left hand side. There are lots of Codecs implemented. The two Database specific codecs are OracleCodec, and MySQLCodec.<br />
<br />
Just click on their names in the ‘All Known Implementing Classes:’ at the top of the Interface Codec page.<br />
<br />
At this time, ESAPI currently has database encoders for:<br />
* Oracle<br />
* MySQL (Both ANSI and native modes are supported)<br />
<br />
Database encoders for:<br />
* SQL Server<br />
* PostgreSQL<br />
<br />
Are forthcoming. If your database encoder is missing, please let us know.<br />
<br />
===Database Specific Escaping Details===<br />
<br />
If you want to build your own escaping routines, here are the escaping details for each of the databases that we have developed ESAPI Encoders for:<br />
<br />
====Oracle Escaping====<br />
<br />
This information is based on the Oracle Escape character information found here: [http://www.orafaq.com/wiki/SQL_FAQ#How_does_one_escape_special_characters_when_writing_SQL_queries.3F http://www.orafaq.com/wiki/SQL_FAQ#How_does_one_escape_special_characters_when_writing_SQL_queries.3F]<br />
<br />
=====Escaping Dynamic Queries=====<br />
<br />
To use an ESAPI database codec is pretty simple. An Oracle example looks something like:<br />
ESAPI.encoder().encodeForSQL( new OracleCodec(), queryparam );<br />
<br />
So, if you had an existing Dynamic query being generated in your code that was going to Oracle that looked like this:<br />
<br />
String query = "SELECT user_id FROM user_data WHERE user_name = '" + req.getParameter("userID") <br />
+ "' and user_password = '" + req.getParameter("pwd") +"'";<br />
try {<br />
Statement statement = connection.createStatement( … );<br />
ResultSet results = statement.executeQuery( query );<br />
}<br />
<br />
You would rewrite the first line to look like this:<br />
<br />
'''Codec ORACLE_CODEC = new OracleCodec();'''<br />
String query = "SELECT user_id FROM user_data WHERE user_name = '" + <br />
'''ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("userID"))''' + "' and user_password = '"<br />
+ '''ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("pwd"))''' +"'";<br />
<br />
And it would now be safe from SQL injection, regardless of the input supplied.<br />
<br />
For maximum code readability, you could also construct your own OracleEncoder.<br />
<br />
Encoder oe = new OracleEncoder();<br />
String query = "SELECT user_id FROM user_data WHERE user_name = '" <br />
+ '''oe.encode( req.getParameter("userID"))''' + "' and user_password = '" <br />
+ '''oe.encode( req.getParameter("pwd"))''' +"'";<br />
<br />
With this type of solution, all your developers would have to do is wrap each user supplied parameter being passed in into an '''ESAPI.encoder().encodeForOracle( )''' call or whatever you named it, and you would be done.<br />
<br />
=====Turn off character replacement=====<br />
<br />
Use SET DEFINE OFF or SET SCAN OFF to ensure that automatic character replacement is turned off. If this character replacement is turned on, the & character will be treated like a SQLPlus variable prefix that could allow an attacker to retrieve private data. <br />
<br />
See [http://download.oracle.com/docs/cd/B19306_01/server.102/b14357/ch12040.htm#i2698854 http://download.oracle.com/docs/cd/B19306_01/server.102/b14357/ch12040.htm#i2698854] and [http://stackoverflow.com/questions/152837/how-to-insert-a-string-which-contains-an http://stackoverflow.com/questions/152837/how-to-insert-a-string-which-contains-an] for more information<br />
<br />
=====Escaping Wildcard characters in Like Clauses=====<br />
<br />
The LIKE keyword allows for text scanning searches. In Oracle, the underscore '_' character matches only one character, while the ampersand '%' is used to match zero or more occurrences of any characters. These characters must be escaped in LIKE clause criteria. For example:<br />
<br />
SELECT name FROM emp <br />
WHERE id LIKE '%/_%' ESCAPE '/';<br />
<br />
SELECT name FROM emp <br />
WHERE id LIKE '%\%%' ESCAPE '\';<br />
<br />
=====Oracle 10g escaping=====<br />
<br />
An alternative for Oracle 10g and later is to place { and } around the string to escape the entire string. However, you have to be careful that there isn't a } character already in the string. You must search for these and if there is one, then you must replace it with }}. Otherwise that character will end the escaping early, and may introduce a vulnerability.<br />
<br />
====MySQL Escaping====<br />
<br />
MySQL supports two escaping modes:<br />
<br />
# ANSI_QUOTES SQL mode, and a mode with this off, which we call<br />
# MySQL mode.<br />
<br />
ANSI SQL mode: Simply encode all ' (single tick) characters with '&#39; (two single ticks)<br />
<br />
MySQL mode, do the following:<br />
<br />
NUL (0x00) --> \0 [This is a zero, not the letter O]<br />
BS (0x08) --> \b<br />
TAB (0x09) --> \t<br />
LF (0x0a) --> \n<br />
CR (0x0d) --> \r<br />
SUB (0x1a) --> \Z<br />
" (0x22) --> \"<br />
% (0x25) --> \%<br />
' (0x27) --> \'<br />
\ (0x5c) --> \\<br />
_ (0x5f) --> \_ <br />
all other non-alphanumeric characters with ASCII values less than 256 --> \c<br />
where 'c' is the original non-alphanumeric character.<br />
<br />
This information is based on the MySQL Escape character information found here: http://mirror.yandex.ru/mirrors/ftp.mysql.com/doc/refman/5.0/en/string-syntax.html<br />
<br />
====SQL Server Escaping====<br />
<br />
We have not implemented the SQL Server escaping routine yet, but the following has good pointers to articles describing how to prevent SQL injection attacks on SQL server<br />
* http://blogs.msdn.com/raulga/archive/2007/01/04/dynamic-sql-sql-injection.aspx<br />
<br />
<br />
====DB2 Escaping====<br />
This information is based on DB2 WebQuery special characters found here: https://www-304.ibm.com/support/docview.wss?uid=nas14488c61e3223e8a78625744f00782983<br />
as well as some information from Oracle's JDBC DB2 driver found here:<br />
http://docs.oracle.com/cd/E12840_01/wls/docs103/jdbc_drivers/sqlescape.html<br />
<br />
Information in regards to differences between several DB2 Universal drivers can be found here: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/ad/rjvjcsqc.htm<br />
<br />
===Hex-encoding all input===<br />
<br />
A somewhat special case of escaping is the process of hex-encode the entire string received from the user (this can be seen as escaping every character). The web application should hex-encode the user input before including it to the SQL statement. The SQL statement should take into account this fact, and accordingly compare the data. For example, if we have to look up a record matching a sessionID, and the user transmitted the string abc123 as session ID, the select statement would be:<br />
<br />
SELECT ... FROM session<br />
WHERE hex_encode (sessionID) = '616263313233'<br />
<br />
(hex_encode should be replace by the particular facility for the database being used). The string 606162313233 is the hex encoded version of the string received from the user (it is the sequence of hex values of the ASCII/UTF-8 codes of the user data).<br />
<br />
If an attacker were to transmit a string containing a single-quote character followed by their attempt to inject SQL code, the constructed SQL statement will only look like:<br />
<br />
WHERE hex_encode ( ... ) = '2720 ... '<br />
<br />
27 being the ASCII code (in hex) of the single-quote, which is simply hex-encoded like any other character in the string. The resulting SQL can only contain numeric digits and a to f letters, and never any special character that could enable an SQL injection.<br />
<br />
===Escaping SQLi in PHP===<br />
<br />
Use prepared statements and parameterized queries. These are SQL statements that are sent to and parsed by the database server separately from any parameters. This way it is impossible for an attacker to inject malicious SQL.<br><br />
You basically have two options to achieve this:<br><br />
<br />
Using [http://php.net/manual/en/book.pdo.php PDO] (for any supported database driver):<br />
<pre><br />
$stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name');<br />
<br />
$stmt->execute(array('name' => $name));<br />
<br />
foreach ($stmt as $row) {<br />
// do something with $row<br />
}<br />
</pre><br />
Using [http://php.net/manual/en/book.mysqli.php MySQLi] (for MySQL):<br />
<pre><br />
$stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?');<br />
$stmt->bind_param('s', $name);<br />
<br />
$stmt->execute();<br />
<br />
$result = $stmt->get_result();<br />
while ($row = $result->fetch_assoc()) {<br />
// do something with $row<br />
}<br />
</pre><br />
If you're connecting to a database other than MySQL, there is a driver-specific second option that you can refer to (e.g. pg_prepare() and pg_execute() for PostgreSQL). PDO is the universal option.<br />
<br />
= Additional Defenses =<br />
<br />
Beyond adopting one of the four primary defenses, we also recommend adopting all of these additional defenses in order to provide defense in depth. These additional defenses are:<br />
<br />
* '''Least Privilege'''<br />
* '''White List Input Validation'''<br />
<br />
== Least Privilege ==<br />
<br />
To minimize the potential damage of a successful SQL injection attack, you should minimize the privileges assigned to every database account in your environment. Do not assign DBA or admin type access rights to your application accounts. We understand that this is easy, and everything just ‘works’ when you do it this way, but it is very dangerous. Start from the ground up to determine what access rights your application accounts require, rather than trying to figure out what access rights you need to take away. Make sure that accounts that only need read access are only granted read access to the tables they need access to. If an account only needs access to portions of a table, consider creating a view that limits access to that portion of the data and assigning the account access to the view instead, rather than the underlying table. Rarely, if ever, grant create or delete access to database accounts.<br />
<br />
If you adopt a policy where you use stored procedures everywhere, and don’t allow application accounts to directly execute their own queries, then restrict those accounts to only be able to execute the stored procedures they need. Don’t grant them any rights directly to the tables in the database.<br />
<br />
SQL injection is not the only threat to your database data. Attackers can simply change the parameter values from one of the legal values they are presented with, to a value that is unauthorized for them, but the application itself might be authorized to access. As such, minimizing the privileges granted to your application will reduce the likelihood of such unauthorized access attempts, even when an attacker is not trying to use SQL injection as part of their exploit.<br />
<br />
While you are at it, you should minimize the privileges of the operating system account that the DBMS runs under. Don't run your DBMS as root or system! Most DBMSs run out of the box with a very powerful system account. For example, MySQL runs as system on Windows by default! Change the DBMS's OS account to something more appropriate, with restricted privileges.<br />
<br />
=== Multiple DB Users ===<br />
<br />
The designer of web applications should not only avoid using the same owner/admin account in the web applications to connect to the database. Different DB users could be used for different web applications. In general, each separate web application that requires access to the database could have a designated database user account that the web-app will use to connect to the DB. That way, the designer of the application can have good granularity in the access control, thus reducing the privileges as much as possible. Each DB user will then have select access to what it needs only, and write-access as needed.<br />
<br />
As an example, a login page requires read access to the username and password fields of a table, but no write access of any form (no insert, update, or delete). However, the sign-up page certainly requires insert privilege to that table; this restriction can only be enforced if these web apps use different DB users to connect to the database.<br />
<br />
=== Views ===<br />
<br />
SQL views can further increase the granularity of access by limiting the read access to specific fields of a table or joins of tables. It could potentially have additional benefits: for example, suppose that the system is required (perhaps due to some specific legal requirements) to store the passwords of the users, instead of salted-hashed passwords. The designer could use views to compensate for this limitation; revoke all access to the table (from all DB users except the owner/admin) and create a view that outputs the hash of the password field and not the field itself. Any SQL injection attack that succeeds in stealing DB information will be restricted to stealing the hash of the passwords (could even be a keyed hash), since no DB user for any of the web applications has access to the table itself.<br />
<br />
== White List Input Validation ==<br />
<br />
In addition to being a primary defense when nothing else is possible (e.g., when a bind variable isn't legal), input validation can also be a secondary defense used to detect unauthorized input before it is passed to the SQL query. For more information please see the [[Input Validation Cheat Sheet]]. Proceed with caution here. Validated data is not necessarily safe to insert into SQL queries via string building.<br />
<br/><br/><br />
<br />
=Related Articles=<br />
<br />
'''SQL Injection Attack Cheat Sheets'''<br />
<br />
The following articles describe how to exploit different kinds of SQL Injection Vulnerabilities on various platforms that this article was created to help you avoid:<br />
<br />
* "SQL Injection Cheat Sheet" - http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/<br />
* "Bypassing WAF's with SQLi" - [[SQL Injection Bypassing WAF]]<br />
<br />
'''Description of SQL Injection Vulnerabilities'''<br />
<br />
* OWASP article on [[SQL Injection]] Vulnerabilities<br />
* OWASP article on [[Blind_SQL_Injection]] Vulnerabilities<br />
<br />
'''How to Avoid SQL Injection Vulnerabilities'''<br />
<br />
* [[:Category:OWASP Guide Project|OWASP Developers Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities<br />
* OWASP Cheat Sheet that provides [[Query_Parameterization_Cheat_Sheet|numerous language specific examples of parameterized queries using both Prepared Statements and Stored Procedures]]<br />
* [http://bobby-tables.com/ The Bobby Tables site (inspired by the XKCD webcomic) has numerous examples in different languages of parameterized Prepared Statements and Stored Procedures]<br />
<br />
'''How to Review Code for SQL Injection Vulnerabilities'''<br />
<br />
* [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities<br />
<br />
'''How to Test for SQL Injection Vulnerabilities'''<br />
<br />
* [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities<br />
<br />
<br/><br/><br />
<br />
= Authors and Primary Editors =<br />
<br />
[[User:wichers|Dave Wichers]] - dave.wichers[at]owasp.org<br/><br />
[[User:jmanico|Jim Manico]] - jim[at]owasp.org<br/><br />
Matt Seil - mseil[at]acm.org<br><br />
[https://owasp.org/index.php/Dhiraj_Mishra Dhiraj Mishra] - mishra.dhiraj[at]owasp.org<br />
<br />
<br/><br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]<br />
[[Category:Popular]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Reflected_File_Download&diff=229153Reflected File Download2017-04-26T09:38:41Z<p>Pawel Krawczyk: disable URLs</p>
<hr />
<div>{{template: Attack}}<br><br />
[[Category:OWASP ASDR Project]]<br />
<br />
'''Reflected File Download''' is an attack combining [http://stackoverflow.com/questions/2163803/what-is-the-semicolon-reserved-for-in-urls URL path segments] (now deprecated) with web services vulnerable to [https://securitycafe.ro/2017/01/18/practical-jsonp-injection/ JSONP Injection] to deliver malware to end users.<br />
<br />
Let's assume we have a vulnerable API that reflects whatever we send to it (the URL was real apparently, now fixed):<br />
<br />
hxxps://google.com/s?q=rfd%22||calc||<br />
{"results":["q", "rfd\"||calc||","I love rfd"]}<br />
<br />
Now, this is normally harmless in a browser as it's JSON so it's not going to be rendered but the browser will rather offer to download the response as a file. Now here's the path segments come to help the attacker:<br />
<br />
hxxps://google.com/s;/setup.bat;?q=rfd%22||calc||<br />
<br />
Everything between semicolons (`;/setup.bat;`) will be not sent to the web service, but instead the browser will interpret it as the file name... to save the API response. Now, a file called setup.bat will be downloaded and run without asking about dangers of running files downloaded from Internet (because it contains the word "setup" in its name). The contents will be interpreted as Windows batch file, and the `calc.exe` command will be run.<br />
<br />
Prevention:<br />
<br />
* sanitize your API's input (in this case they should just allow alphanumerics); escaping is not sufficient<br />
* add `Content-Disposition: attachment; filename="whatever.txt"` on APIs that are not going to be rendered; Google was missing the filename part which actually made the attack easier<br />
* add `X-Content-Type-Options: nosniff` header to API responses<br />
<br />
References:<br />
* [https://www.blackhat.com/docs/eu-14/materials/eu-14-Hafif-Reflected-File-Download-A-New-Web-Attack-Vector.pdf Oren Hafif "Reflected File Download A New Web Attack Vector", BlackHat EU 2014]<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
[[Category:Security Focus Area]]<br />
__NOTOC__<br />
==Overview==</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Reflected_File_Download&diff=229152Reflected File Download2017-04-26T09:37:45Z<p>Pawel Krawczyk: add basic information on RFD and references</p>
<hr />
<div>{{template: Attack}}<br><br />
[[Category:OWASP ASDR Project]]<br />
<br />
'''Reflected File Download''' is an attack combining [http://stackoverflow.com/questions/2163803/what-is-the-semicolon-reserved-for-in-urls URL path segments] (now deprecated) with web services vulnerable to [https://securitycafe.ro/2017/01/18/practical-jsonp-injection/ JSONP Injection] to deliver malware to end users.<br />
<br />
Let's assume we have a vulnerable API that reflects whatever we send to it (the URL was real apparently, now fixed):<br />
<br />
https://google.com/s?q=rfd%22||calc||<br />
<br />
{"results":["q", "rfd\"||calc||","I love rfd"]}<br />
<br />
Now, this is normally harmless in a browser as it's JSON so it's not going to be rendered but the browser will rather offer to download the response as a file. Now here's the path segments come to help the attacker:<br />
<br />
https://google.com/s;/setup.bat;?q=rfd%22||calc||<br />
<br />
Everything between semicolons (`;/setup.bat;`) will be not sent to the web service, but instead the browser will interpret it as the file name... to save the API response. Now, a file called setup.bat will be downloaded and run without asking about dangers of running files downloaded from Internet (because it contains the word "setup" in its name). The contents will be interpreted as Windows batch file, and the `calc.exe` command will be run.<br />
<br />
Prevention:<br />
<br />
* sanitize your API's input (in this case they should just allow alphanumerics); escaping is not sufficient<br />
* add `Content-Disposition: attachment; filename="whatever.txt"` on APIs that are not going to be rendered; Google was missing the filename part which actually made the attack easier<br />
* add `X-Content-Type-Options: nosniff` header to API responses<br />
<br />
References:<br />
* [https://www.blackhat.com/docs/eu-14/materials/eu-14-Hafif-Reflected-File-Download-A-New-Web-Attack-Vector.pdf Oren Hafif "Reflected File Download A New Web Attack Vector", BlackHat EU 2014]<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
[[Category:Security Focus Area]]<br />
__NOTOC__<br />
==Overview==</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=SameSite&diff=228931SameSite2017-04-21T14:44:32Z<p>Pawel Krawczyk: add text from my article https://ipsec.pl/python/2017/understanding-http-cookie-samesite-flag-usage-scenarios.html</p>
<hr />
<div>== Overview ==<br />
<br />
SameSite prevents the browser from sending this cookie along with cross-site requests. The main goal is mitigate the risk of cross-origin information leakage, and provides some protection against cross-site request forgery attacks. Possible values for the flag are <code>lax</code> or <code>strict</code>.<br />
<br />
The <code>strict</code> value will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link. For example, for a GitHub-like website this would mean that if a logged-in user follows a link to a private GitHub project posted on a corporate discussion forum or email, GitHub will '''not''' receive the session cookie and the user will not be able to access the project.<br />
<br />
A bank website however most likely doesn't want to allow any transactional pages to be linked from external sites so the <code>strict</code> flag would be most appropriate here.<br />
<br />
The default <code>lax</code> value provides a reasonable balance between security and usability for websites that want to maintain user's logged-in session after the user arrives from an external link. In the above GitHub scenario, the session cookie would be allowed when following a regular link from an external website while blocking it in CSRF-prone request methods (e.g. <code>POST</code>).<br />
<br />
As of April 2017 the SameSite attribute is implemented in Chrome and Opera.<br />
<br />
== References ==<br />
<br />
* https://tools.ietf.org/html/draft-west-first-party-cookies-07<br />
* https://caniuse.com/#search=samesite<br />
* http://www.sjoerdlangkemper.nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/<br />
* https://chloe.re/2016/04/13/goodbye-csrf-samesite-to-the-rescue/</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Session_Management_Cheat_Sheet&diff=228930Session Management Cheat Sheet2017-04-21T14:38:08Z<p>Pawel Krawczyk: /* HttpOnly Attribute */ SameSite Attribute</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
'''Web Authentication, Session Management, and Access Control''' <br />
<br />
A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session. <br />
<br />
Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication. <br />
<br />
Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet]. <br />
<br />
HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications: <br />
<br />
[[Image:Session-Management-Diagram Cheat-Sheet.png|center|Session-Management-Diagram Cheat-Sheet.png]] <br> The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging. <br />
<br />
The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application. <br />
<br />
<br> <br />
<br />
= Session ID Properties =<br />
<br />
In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair. <br />
<br />
With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties: <br />
<br />
== Session ID Name Fingerprinting ==<br />
<br />
The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID. <br />
<br />
The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID &amp; CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application. <br />
<br />
It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”. <br />
<br />
== Session ID Length ==<br />
<br />
The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions. <br />
<br />
The session ID length must be at least 128 bits (16 bytes).<br />
<br />
'''''NOTE''''': The session ID length of 128 bits is provided as a reference based on the assumptions made on the next section "Session ID Entropy". However, this number should not be considered as an absolute minimum value, as other implementation factors might influence its strength. For example, there are well-known implementations, such as Microsoft ASP.NET, making use of 120-bit random numbers for its session IDs (represented by 20-character strings [10]) that can provide a very good effective entropy, and as a result, can be considered long enough to avoid guessing or brute force attacks.<br />
<br />
== Session ID Entropy ==<br />
<br />
The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used. <br />
<br />
The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).<br> <br />
<br />
'''''NOTE''''': The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2]. If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2]. <br />
<br />
== Session ID Content (or Value) ==<br />
<br />
The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application. <br />
<br />
The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository. <br />
<br />
It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits). <br />
<br />
<br> <br />
<br />
= Session Management Implementation =<br />
<br />
The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC 2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers. <br />
<br />
The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 &amp; 2965 &amp; 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods. <br />
<br />
The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3]. <br />
<br />
== Built-in Session Management Implementations ==<br />
<br />
Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time. <br />
<br />
However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document. <br />
<br />
The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access. <br />
<br />
== Used vs. Accepted Session ID Exchange Mechanisms ==<br />
<br />
A web application should make use of cookies for session ID exchange management. If a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application should avoid accepting it as part of a defensive strategy to stop session fixation.<br />
<br />
'''''NOTE''''': Even if a web application makes use of cookies as its default session ID exchange mechanism, it might accept other exchange mechanisms too. It is therefore required to confirm via thorough testing all the different mechanisms currently accepted by the web application when processing and managing session IDs, and limit the accepted session ID tracking mechanisms to just cookies. In the past, some web applications used URL parameters, or even switched from cookies to URL parameters (via automatic URL rewriting), if certain conditions are met (for example, the identification of web clients without support for cookies or not accepting cookies due to user privacy concerns).<br />
<br />
== Transport Layer Security ==<br />
<br />
In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged. <br />
<br />
Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4]. <br />
<br />
The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application: <br />
<br />
*Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network. <br />
*Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID. <br />
*Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open. <br />
*Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.<br />
* Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.<br />
<br />
See the OWASP Transport Layer Protection Cheat Sheet: [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]. <br />
<br />
It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today. <br />
<br />
<br> <br />
<br />
= Cookies =<br />
<br />
The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID: <br />
<br />
== Secure Attribute ==<br />
<br />
The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic. <br />
<br />
Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.<br />
<br />
See also: [https://www.owasp.org/index.php/SecureFlag SecureFlag]<br />
<br />
== HttpOnly Attribute ==<br />
<br />
The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks. <br />
<br />
See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet].<br />
<br />
See also: [https://www.owasp.org/index.php/HttpOnly HttpOnly]<br />
<br />
== SameSite Attribute ==<br />
SameSite allows a server define a cookie attribute making it impossible to the browser send this cookie along with cross-site requests. The main goal is mitigate the risk of cross-origin information leakage, and provides some protection against cross-site request forgery attacks.<br />
<br />
See also: [https://www.owasp.org/index.php/SameSite SameSite]<br />
<br />
== Domain and Path Attributes ==<br />
<br />
The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie. <br />
<br />
It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID. <br />
<br />
Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com. <br />
<br />
Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4]. <br />
<br />
Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host. <br />
<br />
Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain. <br />
<br />
== Expire and Max-Age Attributes ==<br />
<br />
Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it. <br />
<br />
* Ensure that sensitive information is not comprised, by ensuring that sensitive information is not persistent / encrypting / stored on a need basis for the duration of the need<br />
<br />
* Ensure that unauthorized activities cannot take place via cookie manipulation<br />
<br />
* Ensure secure flag is set to prevent accidental transmission over “the wire” in a non-secure manner<br />
<br />
* Determine if all state transitions in the application code properly check for the cookies and enforce their use<br />
<br />
* Ensure entire cookie should be encrypted if sensitive data is persisted in the cookie<br />
<br />
* Define all cookies being used by the application, their name and why they are needed<br />
<br />
<br />
<br><br />
<br />
= Session ID Life Cycle =<br />
<br />
== Session ID Generation and Verification: Permissive and Strict Session Management ==<br />
<br />
There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application. <br />
<br />
The session tokens should be handled by the web server if possible or generated via a cryptographically secure random number generator.<br />
<br />
Although the most common mechanism in use today is the strict one (more secure). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated. <br />
<br />
== Manage Session ID as Any Other User Input ==<br />
<br />
Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application. <br />
<br />
== Renew the Session ID After Any Privilege Level Change ==<br />
<br />
The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed. <br />
<br />
The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) &amp; HttpSession.invalidate()” (J2EE), “Session.Abandon() &amp; Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() &amp; session_regenerate_id(true)” (PHP). <br />
<br />
The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4]. <br />
<br />
A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states. <br />
<br />
== Considerations When Using Multiple Cookies ==<br />
<br />
If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session. <br />
<br />
It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session [4]. <br />
<br />
Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.<br />
<br />
<br><br />
<br />
= Session Expiration =<br />
<br />
In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active. <br />
<br />
The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring. Both the idle and absolute timeout values are highly dependent on how critical the web application and its data are. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications. <br />
<br />
When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The latter is the most relevant and mandatory from a security perspective. <br />
<br />
For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the “Expires” (or “Max-Age”) attribute to a date from the past (in case a persistent cookie is being used): <br />
<pre>Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT </pre> <br />
In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as “HttpSession.invalidate()” (J2EE), “Session.Abandon()“ (ASP .NET) or “session_destroy()/unset()“ (PHP). <br />
<br />
== Automatic Session Expiration ==<br />
<br />
=== Idle Timeout ===<br />
<br />
All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID. <br />
<br />
The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time. <br />
<br />
Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration. <br />
<br />
=== Absolute Timeout ===<br />
<br />
All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session. <br />
<br />
The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user. <br />
<br />
=== Renewal Timeout ===<br />
<br />
Alternatively, the web application can implement an additional renewal timeout after which the session ID is automatically renewed, in the middle of the user session, and independently of the session activity and, therefore, of the idle timeout. <br />
<br />
After a specific amount of time since the session was initially created, the web application can regenerate a new ID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it. At that time, when the client switches to the new ID inside the current session, the application invalidates the previous ID.<br />
<br />
This scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be reused to hijack the user session, even when the victim user session is still active. The user session remains alive and open on the legitimate client, although its associated session ID value is transparently renewed periodically during the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements the idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is an application requirement to keep the user sessions opened for long periods of time).<br />
<br />
Depending of the implementation, potentially there could be a race condition where the attacker with a still valid previous session ID sends a request before the victim user, right after the renewal timeout has just expired, and obtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the attack as her session will be suddenly terminated because her associated session ID is not valid anymore.<br />
<br />
<br />
== Manual Session Expiration ==<br />
<br />
Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application. <br />
<br />
=== Logout Button ===<br />
<br />
Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time. As described [[Session_Management_Cheat_Sheet#Session_Expiration|above]], the web application must invalidate the session at least on server side.<br />
<br />
'''NOTE''': Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements such as the PopUp LogOut Firefox add-on [9] allow conscientious users to protect their sessions by helping to close them diligently.<br />
<br />
== Web Content Caching ==<br />
<br />
Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers [5], and/or equivalent META tags on all or (at least) sensitive web pages. <br />
<br />
Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the “Cache-Control: no-cache="Set-Cookie, Set-Cookie2"” directive, to allow web clients to cache everything except the session ID. <br />
<br />
<br> <br />
<br />
= Additional Client-Side Defenses for Session Management =<br />
<br />
Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders. <br />
<br />
== Initial Login Timeout ==<br />
<br />
Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID. <br />
<br />
This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks. <br />
<br />
== Force Session Logout On Web Browser Window Close Events ==<br />
<br />
Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button. <br />
<br />
== Disable Web Browser Cross-Tab Sessions ==<br />
<br />
Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to re-authenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them. <br />
<br />
'''''NOTE''''': This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all web browser tabs/windows.&nbsp; <br />
<br />
== Automatic Client Logout ==<br />
<br />
JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously). <br />
<br />
The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.<br />
<br />
<br> <br />
<br />
= Session Attacks Detection =<br />
<br />
== Session ID Guessing and Brute Force Detection ==<br />
<br />
If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs. <br />
<br />
Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es). <br />
<br />
== Detecting Session ID Anomalies ==<br />
<br />
Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session. <br />
<br />
== Binding the Session ID to Other User Properties ==<br />
<br />
With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session. <br />
<br />
Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does. <br />
<br />
== Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs ==<br />
<br />
Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session. <br />
<br />
The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.<br />
<br />
In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.<br />
<br />
The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.<br />
<br />
== Simultaneous Session Logons ==<br />
<br />
It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active. <br />
<br />
It is recommended for web applications to add user capabilities that allow checking the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc. <br />
<br />
<br> <br />
<br />
= Session Management WAF Protections =<br />
<br />
There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term. In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described. <br />
<br />
Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the “Secure” and “HttpOnly” flags, applying basic rewriting rules on the “Set-Cookie” header for all the web application responses that set a new cookie. On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session). <br />
<br />
The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions. <br />
<br />
<br> <br />
<br />
= Related Articles =<br />
<br />
[0] '''OWASP Cookies Database. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_Cookies_Database <br />
<br />
[1] '''"HTTP State Management Mechanism". RFC 6265. IETF.''' http://tools.ietf.org/html/rfc6265 <br />
<br />
[2] '''Insufficient Session-ID Length. OWASP.''' https://www.owasp.org/index.php/Insufficient_Session-ID_Length <br />
<br />
[3] '''Session Fixation. Mitja Kolšek. 2002.''' http://www.acrossecurity.com/papers/session_fixation.pdf <br />
<br />
[4] '''"SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.''' <br />
<br />
https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf <br />
<br />
https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf <br />
<br />
[5] '''"Hypertext Transfer Protocol -- HTTP/1.1". RFC2616. IETF.''' http://tools.ietf.org/html/rfc2616 <br />
<br />
[6] '''OWASP ModSecurity Core Rule Set (CSR) Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project <br />
<br />
[7] '''OWASP AppSensor Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project <br />
<br />
[8] '''HttpOnly Session ID in URL and Page Body | Cross Site Scripting''' http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html<br />
<br />
[9] '''PopUp LogOut Firefox add-on''' https://addons.mozilla.org/en-US/firefox/addon/popup-logout/ & http://popuplogout.iniqua.com<br />
<br />
[10] '''How and why session IDs are reused in ASP.NET''' https://support.microsoft.com/en-us/kb/899918<br />
<br />
= Authors and Primary Editors =<br />
<br />
Raul Siles (DinoSec) - raul[at]dinosec.com <br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Session_Management_Cheat_Sheet&diff=228929Session Management Cheat Sheet2017-04-21T14:37:12Z<p>Pawel Krawczyk: /* HttpOnly Attribute */</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
'''Web Authentication, Session Management, and Access Control''' <br />
<br />
A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session. <br />
<br />
Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication. <br />
<br />
Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet]. <br />
<br />
HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications: <br />
<br />
[[Image:Session-Management-Diagram Cheat-Sheet.png|center|Session-Management-Diagram Cheat-Sheet.png]] <br> The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging. <br />
<br />
The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application. <br />
<br />
<br> <br />
<br />
= Session ID Properties =<br />
<br />
In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair. <br />
<br />
With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties: <br />
<br />
== Session ID Name Fingerprinting ==<br />
<br />
The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID. <br />
<br />
The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID &amp; CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application. <br />
<br />
It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”. <br />
<br />
== Session ID Length ==<br />
<br />
The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions. <br />
<br />
The session ID length must be at least 128 bits (16 bytes).<br />
<br />
'''''NOTE''''': The session ID length of 128 bits is provided as a reference based on the assumptions made on the next section "Session ID Entropy". However, this number should not be considered as an absolute minimum value, as other implementation factors might influence its strength. For example, there are well-known implementations, such as Microsoft ASP.NET, making use of 120-bit random numbers for its session IDs (represented by 20-character strings [10]) that can provide a very good effective entropy, and as a result, can be considered long enough to avoid guessing or brute force attacks.<br />
<br />
== Session ID Entropy ==<br />
<br />
The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used. <br />
<br />
The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).<br> <br />
<br />
'''''NOTE''''': The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2]. If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2]. <br />
<br />
== Session ID Content (or Value) ==<br />
<br />
The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application. <br />
<br />
The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository. <br />
<br />
It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits). <br />
<br />
<br> <br />
<br />
= Session Management Implementation =<br />
<br />
The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC 2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers. <br />
<br />
The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 &amp; 2965 &amp; 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods. <br />
<br />
The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3]. <br />
<br />
== Built-in Session Management Implementations ==<br />
<br />
Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time. <br />
<br />
However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document. <br />
<br />
The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access. <br />
<br />
== Used vs. Accepted Session ID Exchange Mechanisms ==<br />
<br />
A web application should make use of cookies for session ID exchange management. If a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application should avoid accepting it as part of a defensive strategy to stop session fixation.<br />
<br />
'''''NOTE''''': Even if a web application makes use of cookies as its default session ID exchange mechanism, it might accept other exchange mechanisms too. It is therefore required to confirm via thorough testing all the different mechanisms currently accepted by the web application when processing and managing session IDs, and limit the accepted session ID tracking mechanisms to just cookies. In the past, some web applications used URL parameters, or even switched from cookies to URL parameters (via automatic URL rewriting), if certain conditions are met (for example, the identification of web clients without support for cookies or not accepting cookies due to user privacy concerns).<br />
<br />
== Transport Layer Security ==<br />
<br />
In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged. <br />
<br />
Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4]. <br />
<br />
The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application: <br />
<br />
*Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network. <br />
*Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID. <br />
*Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open. <br />
*Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.<br />
* Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.<br />
<br />
See the OWASP Transport Layer Protection Cheat Sheet: [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]. <br />
<br />
It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today. <br />
<br />
<br> <br />
<br />
= Cookies =<br />
<br />
The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID: <br />
<br />
== Secure Attribute ==<br />
<br />
The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic. <br />
<br />
Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.<br />
<br />
See also: [https://www.owasp.org/index.php/SecureFlag SecureFlag]<br />
<br />
== HttpOnly Attribute ==<br />
<br />
The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks. <br />
<br />
See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet].<br />
<br />
See also: [https://www.owasp.org/index.php/HttpOnly HttpOnly]<br />
<br />
== Domain and Path Attributes ==<br />
<br />
The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie. <br />
<br />
It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID. <br />
<br />
Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com. <br />
<br />
Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4]. <br />
<br />
Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host. <br />
<br />
Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain. <br />
<br />
== Expire and Max-Age Attributes ==<br />
<br />
Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it. <br />
<br />
* Ensure that sensitive information is not comprised, by ensuring that sensitive information is not persistent / encrypting / stored on a need basis for the duration of the need<br />
<br />
* Ensure that unauthorized activities cannot take place via cookie manipulation<br />
<br />
* Ensure secure flag is set to prevent accidental transmission over “the wire” in a non-secure manner<br />
<br />
* Determine if all state transitions in the application code properly check for the cookies and enforce their use<br />
<br />
* Ensure entire cookie should be encrypted if sensitive data is persisted in the cookie<br />
<br />
* Define all cookies being used by the application, their name and why they are needed<br />
<br />
<br />
<br><br />
<br />
= Session ID Life Cycle =<br />
<br />
== Session ID Generation and Verification: Permissive and Strict Session Management ==<br />
<br />
There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application. <br />
<br />
The session tokens should be handled by the web server if possible or generated via a cryptographically secure random number generator.<br />
<br />
Although the most common mechanism in use today is the strict one (more secure). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated. <br />
<br />
== Manage Session ID as Any Other User Input ==<br />
<br />
Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application. <br />
<br />
== Renew the Session ID After Any Privilege Level Change ==<br />
<br />
The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed. <br />
<br />
The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) &amp; HttpSession.invalidate()” (J2EE), “Session.Abandon() &amp; Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() &amp; session_regenerate_id(true)” (PHP). <br />
<br />
The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4]. <br />
<br />
A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states. <br />
<br />
== Considerations When Using Multiple Cookies ==<br />
<br />
If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session. <br />
<br />
It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session [4]. <br />
<br />
Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.<br />
<br />
<br><br />
<br />
= Session Expiration =<br />
<br />
In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active. <br />
<br />
The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring. Both the idle and absolute timeout values are highly dependent on how critical the web application and its data are. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications. <br />
<br />
When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The latter is the most relevant and mandatory from a security perspective. <br />
<br />
For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the “Expires” (or “Max-Age”) attribute to a date from the past (in case a persistent cookie is being used): <br />
<pre>Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT </pre> <br />
In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as “HttpSession.invalidate()” (J2EE), “Session.Abandon()“ (ASP .NET) or “session_destroy()/unset()“ (PHP). <br />
<br />
== Automatic Session Expiration ==<br />
<br />
=== Idle Timeout ===<br />
<br />
All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID. <br />
<br />
The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time. <br />
<br />
Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration. <br />
<br />
=== Absolute Timeout ===<br />
<br />
All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session. <br />
<br />
The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user. <br />
<br />
=== Renewal Timeout ===<br />
<br />
Alternatively, the web application can implement an additional renewal timeout after which the session ID is automatically renewed, in the middle of the user session, and independently of the session activity and, therefore, of the idle timeout. <br />
<br />
After a specific amount of time since the session was initially created, the web application can regenerate a new ID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it. At that time, when the client switches to the new ID inside the current session, the application invalidates the previous ID.<br />
<br />
This scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be reused to hijack the user session, even when the victim user session is still active. The user session remains alive and open on the legitimate client, although its associated session ID value is transparently renewed periodically during the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements the idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is an application requirement to keep the user sessions opened for long periods of time).<br />
<br />
Depending of the implementation, potentially there could be a race condition where the attacker with a still valid previous session ID sends a request before the victim user, right after the renewal timeout has just expired, and obtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the attack as her session will be suddenly terminated because her associated session ID is not valid anymore.<br />
<br />
<br />
== Manual Session Expiration ==<br />
<br />
Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application. <br />
<br />
=== Logout Button ===<br />
<br />
Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time. As described [[Session_Management_Cheat_Sheet#Session_Expiration|above]], the web application must invalidate the session at least on server side.<br />
<br />
'''NOTE''': Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements such as the PopUp LogOut Firefox add-on [9] allow conscientious users to protect their sessions by helping to close them diligently.<br />
<br />
== Web Content Caching ==<br />
<br />
Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers [5], and/or equivalent META tags on all or (at least) sensitive web pages. <br />
<br />
Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the “Cache-Control: no-cache="Set-Cookie, Set-Cookie2"” directive, to allow web clients to cache everything except the session ID. <br />
<br />
<br> <br />
<br />
= Additional Client-Side Defenses for Session Management =<br />
<br />
Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders. <br />
<br />
== Initial Login Timeout ==<br />
<br />
Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID. <br />
<br />
This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks. <br />
<br />
== Force Session Logout On Web Browser Window Close Events ==<br />
<br />
Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button. <br />
<br />
== Disable Web Browser Cross-Tab Sessions ==<br />
<br />
Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to re-authenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them. <br />
<br />
'''''NOTE''''': This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all web browser tabs/windows.&nbsp; <br />
<br />
== Automatic Client Logout ==<br />
<br />
JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously). <br />
<br />
The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.<br />
<br />
<br> <br />
<br />
= Session Attacks Detection =<br />
<br />
== Session ID Guessing and Brute Force Detection ==<br />
<br />
If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs. <br />
<br />
Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es). <br />
<br />
== Detecting Session ID Anomalies ==<br />
<br />
Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session. <br />
<br />
== Binding the Session ID to Other User Properties ==<br />
<br />
With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session. <br />
<br />
Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does. <br />
<br />
== Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs ==<br />
<br />
Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session. <br />
<br />
The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.<br />
<br />
In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.<br />
<br />
The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.<br />
<br />
== Simultaneous Session Logons ==<br />
<br />
It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active. <br />
<br />
It is recommended for web applications to add user capabilities that allow checking the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc. <br />
<br />
<br> <br />
<br />
= Session Management WAF Protections =<br />
<br />
There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term. In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described. <br />
<br />
Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the “Secure” and “HttpOnly” flags, applying basic rewriting rules on the “Set-Cookie” header for all the web application responses that set a new cookie. On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session). <br />
<br />
The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions. <br />
<br />
<br> <br />
<br />
= Related Articles =<br />
<br />
[0] '''OWASP Cookies Database. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_Cookies_Database <br />
<br />
[1] '''"HTTP State Management Mechanism". RFC 6265. IETF.''' http://tools.ietf.org/html/rfc6265 <br />
<br />
[2] '''Insufficient Session-ID Length. OWASP.''' https://www.owasp.org/index.php/Insufficient_Session-ID_Length <br />
<br />
[3] '''Session Fixation. Mitja Kolšek. 2002.''' http://www.acrossecurity.com/papers/session_fixation.pdf <br />
<br />
[4] '''"SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.''' <br />
<br />
https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf <br />
<br />
https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf <br />
<br />
[5] '''"Hypertext Transfer Protocol -- HTTP/1.1". RFC2616. IETF.''' http://tools.ietf.org/html/rfc2616 <br />
<br />
[6] '''OWASP ModSecurity Core Rule Set (CSR) Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project <br />
<br />
[7] '''OWASP AppSensor Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project <br />
<br />
[8] '''HttpOnly Session ID in URL and Page Body | Cross Site Scripting''' http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html<br />
<br />
[9] '''PopUp LogOut Firefox add-on''' https://addons.mozilla.org/en-US/firefox/addon/popup-logout/ & http://popuplogout.iniqua.com<br />
<br />
[10] '''How and why session IDs are reused in ASP.NET''' https://support.microsoft.com/en-us/kb/899918<br />
<br />
= Authors and Primary Editors =<br />
<br />
Raul Siles (DinoSec) - raul[at]dinosec.com <br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Session_Management_Cheat_Sheet&diff=228928Session Management Cheat Sheet2017-04-21T14:34:15Z<p>Pawel Krawczyk: /* Secure Attribute */</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
'''Web Authentication, Session Management, and Access Control''' <br />
<br />
A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session. <br />
<br />
Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication. <br />
<br />
Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet]. <br />
<br />
HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications: <br />
<br />
[[Image:Session-Management-Diagram Cheat-Sheet.png|center|Session-Management-Diagram Cheat-Sheet.png]] <br> The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging. <br />
<br />
The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application. <br />
<br />
<br> <br />
<br />
= Session ID Properties =<br />
<br />
In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair. <br />
<br />
With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties: <br />
<br />
== Session ID Name Fingerprinting ==<br />
<br />
The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID. <br />
<br />
The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID &amp; CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application. <br />
<br />
It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”. <br />
<br />
== Session ID Length ==<br />
<br />
The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions. <br />
<br />
The session ID length must be at least 128 bits (16 bytes).<br />
<br />
'''''NOTE''''': The session ID length of 128 bits is provided as a reference based on the assumptions made on the next section "Session ID Entropy". However, this number should not be considered as an absolute minimum value, as other implementation factors might influence its strength. For example, there are well-known implementations, such as Microsoft ASP.NET, making use of 120-bit random numbers for its session IDs (represented by 20-character strings [10]) that can provide a very good effective entropy, and as a result, can be considered long enough to avoid guessing or brute force attacks.<br />
<br />
== Session ID Entropy ==<br />
<br />
The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used. <br />
<br />
The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).<br> <br />
<br />
'''''NOTE''''': The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2]. If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2]. <br />
<br />
== Session ID Content (or Value) ==<br />
<br />
The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application. <br />
<br />
The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository. <br />
<br />
It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits). <br />
<br />
<br> <br />
<br />
= Session Management Implementation =<br />
<br />
The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC 2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers. <br />
<br />
The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 &amp; 2965 &amp; 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods. <br />
<br />
The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3]. <br />
<br />
== Built-in Session Management Implementations ==<br />
<br />
Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time. <br />
<br />
However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document. <br />
<br />
The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access. <br />
<br />
== Used vs. Accepted Session ID Exchange Mechanisms ==<br />
<br />
A web application should make use of cookies for session ID exchange management. If a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application should avoid accepting it as part of a defensive strategy to stop session fixation.<br />
<br />
'''''NOTE''''': Even if a web application makes use of cookies as its default session ID exchange mechanism, it might accept other exchange mechanisms too. It is therefore required to confirm via thorough testing all the different mechanisms currently accepted by the web application when processing and managing session IDs, and limit the accepted session ID tracking mechanisms to just cookies. In the past, some web applications used URL parameters, or even switched from cookies to URL parameters (via automatic URL rewriting), if certain conditions are met (for example, the identification of web clients without support for cookies or not accepting cookies due to user privacy concerns).<br />
<br />
== Transport Layer Security ==<br />
<br />
In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged. <br />
<br />
Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4]. <br />
<br />
The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application: <br />
<br />
*Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network. <br />
*Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID. <br />
*Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open. <br />
*Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.<br />
* Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.<br />
<br />
See the OWASP Transport Layer Protection Cheat Sheet: [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]. <br />
<br />
It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today. <br />
<br />
<br> <br />
<br />
= Cookies =<br />
<br />
The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID: <br />
<br />
== Secure Attribute ==<br />
<br />
The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic. <br />
<br />
Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.<br />
<br />
See also: [https://www.owasp.org/index.php/SecureFlag SecureFlag]<br />
<br />
== HttpOnly Attribute ==<br />
<br />
The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks. <br />
<br />
See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet]. <br />
<br />
== Domain and Path Attributes ==<br />
<br />
The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie. <br />
<br />
It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID. <br />
<br />
Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com. <br />
<br />
Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4]. <br />
<br />
Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host. <br />
<br />
Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain. <br />
<br />
== Expire and Max-Age Attributes ==<br />
<br />
Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it. <br />
<br />
* Ensure that sensitive information is not comprised, by ensuring that sensitive information is not persistent / encrypting / stored on a need basis for the duration of the need<br />
<br />
* Ensure that unauthorized activities cannot take place via cookie manipulation<br />
<br />
* Ensure secure flag is set to prevent accidental transmission over “the wire” in a non-secure manner<br />
<br />
* Determine if all state transitions in the application code properly check for the cookies and enforce their use<br />
<br />
* Ensure entire cookie should be encrypted if sensitive data is persisted in the cookie<br />
<br />
* Define all cookies being used by the application, their name and why they are needed<br />
<br />
<br />
<br><br />
<br />
= Session ID Life Cycle =<br />
<br />
== Session ID Generation and Verification: Permissive and Strict Session Management ==<br />
<br />
There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application. <br />
<br />
The session tokens should be handled by the web server if possible or generated via a cryptographically secure random number generator.<br />
<br />
Although the most common mechanism in use today is the strict one (more secure). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated. <br />
<br />
== Manage Session ID as Any Other User Input ==<br />
<br />
Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application. <br />
<br />
== Renew the Session ID After Any Privilege Level Change ==<br />
<br />
The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed. <br />
<br />
The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) &amp; HttpSession.invalidate()” (J2EE), “Session.Abandon() &amp; Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() &amp; session_regenerate_id(true)” (PHP). <br />
<br />
The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4]. <br />
<br />
A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states. <br />
<br />
== Considerations When Using Multiple Cookies ==<br />
<br />
If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session. <br />
<br />
It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session [4]. <br />
<br />
Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.<br />
<br />
<br><br />
<br />
= Session Expiration =<br />
<br />
In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active. <br />
<br />
The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring. Both the idle and absolute timeout values are highly dependent on how critical the web application and its data are. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications. <br />
<br />
When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The latter is the most relevant and mandatory from a security perspective. <br />
<br />
For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the “Expires” (or “Max-Age”) attribute to a date from the past (in case a persistent cookie is being used): <br />
<pre>Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT </pre> <br />
In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as “HttpSession.invalidate()” (J2EE), “Session.Abandon()“ (ASP .NET) or “session_destroy()/unset()“ (PHP). <br />
<br />
== Automatic Session Expiration ==<br />
<br />
=== Idle Timeout ===<br />
<br />
All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID. <br />
<br />
The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time. <br />
<br />
Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration. <br />
<br />
=== Absolute Timeout ===<br />
<br />
All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session. <br />
<br />
The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user. <br />
<br />
=== Renewal Timeout ===<br />
<br />
Alternatively, the web application can implement an additional renewal timeout after which the session ID is automatically renewed, in the middle of the user session, and independently of the session activity and, therefore, of the idle timeout. <br />
<br />
After a specific amount of time since the session was initially created, the web application can regenerate a new ID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it. At that time, when the client switches to the new ID inside the current session, the application invalidates the previous ID.<br />
<br />
This scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be reused to hijack the user session, even when the victim user session is still active. The user session remains alive and open on the legitimate client, although its associated session ID value is transparently renewed periodically during the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements the idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is an application requirement to keep the user sessions opened for long periods of time).<br />
<br />
Depending of the implementation, potentially there could be a race condition where the attacker with a still valid previous session ID sends a request before the victim user, right after the renewal timeout has just expired, and obtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the attack as her session will be suddenly terminated because her associated session ID is not valid anymore.<br />
<br />
<br />
== Manual Session Expiration ==<br />
<br />
Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application. <br />
<br />
=== Logout Button ===<br />
<br />
Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time. As described [[Session_Management_Cheat_Sheet#Session_Expiration|above]], the web application must invalidate the session at least on server side.<br />
<br />
'''NOTE''': Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements such as the PopUp LogOut Firefox add-on [9] allow conscientious users to protect their sessions by helping to close them diligently.<br />
<br />
== Web Content Caching ==<br />
<br />
Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers [5], and/or equivalent META tags on all or (at least) sensitive web pages. <br />
<br />
Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the “Cache-Control: no-cache="Set-Cookie, Set-Cookie2"” directive, to allow web clients to cache everything except the session ID. <br />
<br />
<br> <br />
<br />
= Additional Client-Side Defenses for Session Management =<br />
<br />
Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders. <br />
<br />
== Initial Login Timeout ==<br />
<br />
Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID. <br />
<br />
This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks. <br />
<br />
== Force Session Logout On Web Browser Window Close Events ==<br />
<br />
Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button. <br />
<br />
== Disable Web Browser Cross-Tab Sessions ==<br />
<br />
Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to re-authenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them. <br />
<br />
'''''NOTE''''': This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all web browser tabs/windows.&nbsp; <br />
<br />
== Automatic Client Logout ==<br />
<br />
JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously). <br />
<br />
The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.<br />
<br />
<br> <br />
<br />
= Session Attacks Detection =<br />
<br />
== Session ID Guessing and Brute Force Detection ==<br />
<br />
If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs. <br />
<br />
Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es). <br />
<br />
== Detecting Session ID Anomalies ==<br />
<br />
Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session. <br />
<br />
== Binding the Session ID to Other User Properties ==<br />
<br />
With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session. <br />
<br />
Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does. <br />
<br />
== Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs ==<br />
<br />
Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session. <br />
<br />
The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.<br />
<br />
In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.<br />
<br />
The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.<br />
<br />
== Simultaneous Session Logons ==<br />
<br />
It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active. <br />
<br />
It is recommended for web applications to add user capabilities that allow checking the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc. <br />
<br />
<br> <br />
<br />
= Session Management WAF Protections =<br />
<br />
There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term. In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described. <br />
<br />
Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the “Secure” and “HttpOnly” flags, applying basic rewriting rules on the “Set-Cookie” header for all the web application responses that set a new cookie. On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session). <br />
<br />
The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions. <br />
<br />
<br> <br />
<br />
= Related Articles =<br />
<br />
[0] '''OWASP Cookies Database. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_Cookies_Database <br />
<br />
[1] '''"HTTP State Management Mechanism". RFC 6265. IETF.''' http://tools.ietf.org/html/rfc6265 <br />
<br />
[2] '''Insufficient Session-ID Length. OWASP.''' https://www.owasp.org/index.php/Insufficient_Session-ID_Length <br />
<br />
[3] '''Session Fixation. Mitja Kolšek. 2002.''' http://www.acrossecurity.com/papers/session_fixation.pdf <br />
<br />
[4] '''"SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.''' <br />
<br />
https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf <br />
<br />
https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf <br />
<br />
[5] '''"Hypertext Transfer Protocol -- HTTP/1.1". RFC2616. IETF.''' http://tools.ietf.org/html/rfc2616 <br />
<br />
[6] '''OWASP ModSecurity Core Rule Set (CSR) Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project <br />
<br />
[7] '''OWASP AppSensor Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project <br />
<br />
[8] '''HttpOnly Session ID in URL and Page Body | Cross Site Scripting''' http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html<br />
<br />
[9] '''PopUp LogOut Firefox add-on''' https://addons.mozilla.org/en-US/firefox/addon/popup-logout/ & http://popuplogout.iniqua.com<br />
<br />
[10] '''How and why session IDs are reused in ASP.NET''' https://support.microsoft.com/en-us/kb/899918<br />
<br />
= Authors and Primary Editors =<br />
<br />
Raul Siles (DinoSec) - raul[at]dinosec.com <br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Password_Storage_Cheat_Sheet&diff=228923Password Storage Cheat Sheet2017-04-21T11:10:32Z<p>Pawel Krawczyk: /* Leverage an adaptive one-way function */ formatting, update Argon2 wording</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
Media covers the theft of large collections of passwords on an almost daily basis. Media coverage of password theft discloses the password storage scheme, the weakness of that scheme, and often discloses a large population of compromised credentials that can affect multiple web sites or other applications. This article provides guidance on properly storing passwords, secret question responses, and similar credential information. Proper storage helps prevent theft, compromise, and malicious use of credentials.<br />
Information systems store passwords and other credentials in a variety of protected forms. Common vulnerabilities allow the theft of protected passwords through attack vectors such as SQL Injection. Protected passwords can also be stolen from artifacts such as logs, dumps, and backups.<br />
<br />
Specific guidance herein protects against stored credential theft but the bulk of guidance aims to prevent credential compromise. That is, this guidance helps designs resist revealing users’ credentials or allowing system access in the event threats steal protected credential information. For more information and a thorough treatment of this topic, refer to the Secure Password Storage Threat Model here [http://goo.gl/Spvzs http://goo.gl/Spvzs].<br />
<br />
= Guidance =<br />
<br />
== Do not limit the character set and set long max lengths for credentials ==<br />
<br />
Some organizations restrict the 1) types of special characters and 2) length of credentials accepted by systems because of their inability to prevent SQL Injection, Cross-site scripting, command-injection and other forms of injection attacks. These restrictions, while well-intentioned, facilitate certain simple attacks such as brute force.<br />
<br />
Do not allow short or no-length passwords and do not apply character set, or encoding restrictions on the entry or storage of credentials. Continue applying encoding, escaping, masking, outright omission, and other best practices to eliminate injection risks.<br />
<br />
A reasonable long password length is 160. Very long password policies can lead to DOS in certain circumstances[http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/].<br />
<br />
== Use a cryptographically strong credential-specific salt ==<br />
<br />
A salt is fixed-length cryptographically-strong random value. Append credential data to the salt and use this as input to a protective function. Store the protected form appended to the salt as follows:<br />
<br />
<code>[protected form] = [salt] + protect([protection func], [salt] + [credential]);</code><br />
<br />
Follow these practices to properly implement credential-specific salts:<br />
<br />
* Generate a unique salt upon creation of each stored credential (not just per user or system wide);<br />
* Use cryptographically-strong random [*3] data;<br />
* As storage permits, use a 32 byte or 64 byte salt (actual size dependent on protection function);<br />
* Scheme security does not depend on hiding, splitting, or otherwise obscuring the salt.<br />
<br />
Salts serve two purposes: 1) prevent the protected form from revealing two identical credentials and 2) augment entropy fed to protecting function without relying on credential complexity. The second aims to make pre-computed lookup attacks [*2] on an individual credential and time-based attacks on a population intractable.<br />
<br />
== Impose infeasible verification on attacker ==<br />
<br />
The function used to protect stored credentials should balance attacker and defender verification. The defender needs an acceptable response time for verification of users’ credentials during peak use. However, the time required to map <code><credential> → <protected form></code> must remain beyond threats’ hardware (GPU, FPGA) and technique (dictionary-based, brute force, etc) capabilities.<br />
<br />
Two approaches facilitate this, each imperfectly.<br />
<br />
=== Leverage an adaptive one-way function ===<br />
<br />
Adaptive one-way functions compute a one-way (irreversible) transform. Each function allows configuration of ‘work factor’. Underlying mechanisms used to achieve irreversibility and govern work factors (such as time, space, and parallelism) vary between functions and remain unimportant to this discussion. <br />
<br />
Select:<br />
<br />
* '''Argon2'''[*7] is the winner of the [https://password-hashing.net/ password hashing competition] and should be considered as your first choice for new applications; <br />
* '''PBKDF2''' [*4] when FIPS certification or enterprise support on many platforms is required;<br />
* '''scrypt''' [*5] where resisting any/all hardware accelerated attacks is necessary but support isn’t.<br />
* '''bcrypt''' where PBKDF2 or scrypt support is not available.<br />
<br />
Example protect() pseudo-code follows:<br />
<br />
<code>return [salt] + pbkdf2([salt], [credential], c=10000); </code><br />
<br />
Designers select one-way adaptive functions to implement protect() because these functions can be configured to cost (linearly or exponentially) more than a hash function to execute. Defenders adjust work factor to keep pace with threats’ increasing hardware capabilities. Those implementing adaptive one-way functions must tune work factors so as to impede attackers while providing acceptable user experience and scale. <br />
<br />
Additionally, adaptive one-way functions do not effectively prevent reversal of common dictionary-based credentials (users with password ‘password’) regardless of user population size or salt usage.<br />
<br />
==== Work Factor ====<br />
<br />
Since resources are normally considered limited, a common rule of thumb for tuning the work factor (or cost) is to make protect() run as slow as possible without affecting the users' experience and without increasing the need for extra hardware over budget. So, if the registration and authentication's cases accept protect() taking up to 1 second, you can tune the cost so that it takes 1 second to run on your hardware. This way, it shouldn't be so slow that your users become affected, but it should also affect the attackers' attempt as much as possible. <br />
<br />
While there is a minimum number of iterations recommended to ensure data safety, this value changes every year as technology improves. An example of the iteration count chosen by a well known company is the 10,000 iterations Apple uses for its iTunes passwords (using PBKDF2)[http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf](PDF file). However, it is critical to understand that a single work factor does not fit all designs. Experimentation is important.[*6]<br />
<br />
=== Leverage Keyed functions ===<br />
<br />
Keyed functions, such as HMACs, compute a one-way (irreversible) transform using a private key and given input. For example, HMACs inherit properties of hash functions including their speed, allowing for near instant verification. Key size imposes infeasible size- and/or space- requirements on compromise--even for common credentials (aka password = ‘password’).<br />
Designers protecting stored credentials with keyed functions:<br />
<br />
* Use a single “site-wide” key;<br />
* Protect this key as any private key using best practices;<br />
* Store the key outside the credential store (aka: not in the database);<br />
* Generate the key using cryptographically-strong pseudo-random data;<br />
* Do not worry about output block size (i.e. SHA-256 vs. SHA-512).<br />
<br />
Example protect() pseudo-code follows:<br />
<br />
<code>return [salt] + HMAC-SHA-256([key], [salt] + [credential]); </code><br />
<br />
Upholding security improvement over (solely) salted schemes relies on proper key management.<br />
<br />
== Design password storage assuming eventual compromise ==<br />
<br />
The frequency and ease with which threats steal protected credentials demands “design for failure”. Having detected theft, a credential storage scheme must support continued operation by marking credential data as compromised. It's also critical to engage alternative credential validation workflows as follows:<br />
<br />
# Protect the user’s account<br />
## Invalidate authentication ‘shortcuts’ by disallowing login without 2nd factors, secret questions or some other form os strong authentication.<br />
## Disallow changes to user accounts such as editing secret questions and changing account multi-factor configuration settings.<br />
# Load and use new protection scheme<br />
## Load a new, stronger credential protection scheme<br />
## Include version information stored with form<br />
## Set ‘tainted’/‘compromised’ bit until user resets credentials<br />
## Rotate any keys and/or adjust protection function parameters such as work factor or salt<br />
## Increment scheme version number<br />
# When user logs in:<br />
## Validate credentials based on stored version (old or new); if older compromised version is still active for user, demand 2nd factor or secret answers until the new method is implemented or activated for that user<br />
## Prompt user for credential change, apologize, & conduct out-of-band confirmation<br />
## Convert stored credentials to new scheme as user successfully log in<br />
<br />
= References=<br />
<br />
* [1] Morris, R. Thompson, K., Password Security: A Case History, 04/03/1978, p4: http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps<br />
* [2] Space-based (Lookup) attacks: Space-time Tradeoff: Hellman, M., Crypanalytic Time-Memory Trade-Off, Transactions of Information Theory, Vol. IT-26, No. 4, July, 1980 http://www-ee.stanford.edu/~hellman/publications/36.pdf Rainbow Tables -http://ophcrack.sourceforge.net/tables.php<br />
* [3] For example: [http://docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html SecureRandom.html].<br />
* [4] Kalski, B., PKCS #5: Password-Based Cryptography Specification Version 2.0, IETF RFC 2898, September, 2000, p9 http://www.ietf.org/rfc/rfc2898.txt<br />
* [5] Percival, C., Stronger Key Derivation Via Sequential Memory-Hard Functions, BSDCan ‘09, May, 2009 http://www.tarsnap.com/scrypt/scrypt.pdf<br />
* [6] For instance, one might set work factors targeting the following run times: (1) Password-generated session key - fraction of a second; (2) User credential - ~0.5 seconds; (3) Password-generated site (or other long-lived) key - potentially a second or more.<br />
* [7] Argon2 detailed specifications can be found here. https://password-hashing.net/argon2-specs.pdf<br />
<br />
= Authors and Primary Editors =<br />
<br />
John Steven - john.steven[at]owasp.org (author)<br/><br />
Jim Manico - jim[at]owasp.org (editor)<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Authentication_Cheat_Sheet&diff=228922Authentication Cheat Sheet2017-04-21T11:07:56Z<p>Pawel Krawczyk: /* Password Complexity */ typo</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
<br/><b>English</b> | [[Authentication_Cheat_Sheet_Español | Spanish]]<br/><br />
<br/><br />
__TOC__{{TOC hidden}}<br />
= Introduction = <br />
<br />
'''Authentication''' is the process of verification that an individual, entity or website is who it claims to be. Authentication in the context of web applications is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.<br />
<br />
'''Session Management''' is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.<br />
<br />
== Authentication General Guidelines ==<br />
<br />
=== User IDs ===<br />
<br />
Make sure your usernames/userids are case insensitive. User 'smith' and user 'Smith' should be the same user. User names should also be unique. For high security applications usernames could be assigned and secret instead of user-defined public data.<br />
<br />
==== Email address as a User ID ====<br />
<br />
For information on validating email addresses, please visit the [https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#Email_Address_Validation input validation cheatsheet email discussion].<br />
<br />
=== Implement Proper Password Strength Controls ===<br />
<br />
A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password through either manual or automated means. The following characteristics define a strong password: <br />
<br />
==== Password Length ====<br />
<br />
Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess. <br />
<br />
* '''Minimum''' length of the passwords should be '''enforced''' by the application.<br />
** Passwords '''shorter than 10 characters''' are considered to be weak ([http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf NIST SP800-132]).<br />
<br />
While minimum length enforcement may cause problems with memorizing passwords among some users, applications should encourage them to set ''passphrases'' (sentences or combination of words) that can be much longer than typical passwords and yet much easier to remember.<br />
<br />
* '''Maximum''' password length should not be set '''too low''', as it will prevent users from creating passphrases. Typical maximum length is 128 characters.<br />
** Passphrases shorter than 20 characters are usually considered weak if they only consist of lower case Latin characters.<br />
<br />
==== Password Complexity ====<br />
<br />
Applications should enforce password complexity rules to discourage easy to guess passwords. Password mechanisms should allow virtually any character the user can type to be part of their password, including the space character. Passwords should, obviously, be case sensitive in order to increase their complexity. Occasionally, we find systems where passwords aren't case sensitive, frequently due to legacy system issues like old mainframes that didn't have case sensitive passwords.<br />
<br />
The password change mechanism should require a minimum level of complexity that makes sense for the application and its user population. For example:<br />
<br />
*Password must meet at least 3 out of the following 4 complexity rules<br />
**at least 1 uppercase character (A-Z) <br />
**at least 1 lowercase character (a-z) <br />
**at least 1 digit (0-9) <br />
**at least 1 [[Password special characters|special character (punctuation)]] &mdash; do not forget to treat space as special characters too<br />
*at least 10 characters <br />
*at most 128 characters<br />
*not more than 2 identical characters in a row (e.g., 111 not allowed)<br />
<br />
Further reading:<br />
<br />
* [https://www.youtube.com/watch?v=zUM7i8fsf0g Your Password Complexity Requirements are Worthless - OWASP AppSecUSA 2014] presentation for further discussion of legacy password complexity rules<br />
* [https://www.korelogic.com/Resources/Presentations/bsidesavl_pathwell_2014-06.pdf PathWell: Password Topology Histogram Wear-Leveling]<br />
<br />
==== Password Topologies ====<br />
<br />
* Ban commonly used password topologies<br />
* Force multiple users to use different password topologies<br />
* Require a minimum topology change between old and new passwords<br />
<br />
==== Additional Information ====<br />
<br />
* Make sure that every character the user types in is actually included in the password. We've seen systems that truncate the password at a length shorter than what the user provided (e.g., truncated at 15 characters when they entered 20).<br />
* As application's require more complex password policies, they need to be very clear about what these policies are. The required policy needs to be explicitly stated on the password change page<br />
* If the new password doesn't comply with the complexity policy, the error message should describe EVERY complexity rule that the new password does not comply with, not just the 1st rule it doesn't comply with.<br />
<br />
=== Implement Secure Password Recovery Mechanism ===<br />
<br />
It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see [[Forgot Password Cheat Sheet]] for details on this feature.<br />
<br />
=== Store Passwords in a Secure Fashion ===<br />
<br />
It is critical for a application to store a password using the right cryptographic technique. Please see [[Password Storage Cheat Sheet]] for details on this feature.<br />
<br />
=== Transmit Passwords Only Over TLS or Other Strong Transport ===<br />
<br />
See: [[Transport Layer Protection Cheat Sheet]]<br />
<br />
The login page and all subsequent authenticated pages must be exclusively accessed over TLS or other strong transport. The initial login page, referred to as the "login landing page", must be served over TLS or other strong transport. Failure to utilize TLS or other strong transport 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 or other strong transport for authenticated pages after login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session.<br />
<br />
=== Require Re-authentication for Sensitive Features ===<br />
<br />
In order to mitigate CSRF and session hijacking, it's important to require the current credentials for an account before updating sensitive account information such as the user's password, user's email, or before sensitive transactions, such as shipping a purchase to a new address. Without this countermeasure, an attacker may be able to execute sensitive transactions through a CSRF or XSS attack without needing to know the user's current credentials. Additionally, an attacker may get temporary physical access to a user's browser or steal their session ID to take over the user's session.<br />
<br />
=== Consider Strong Transaction Authentication ===<br />
<br />
Some applications should use a second factor to check whether a user may perform sensitive operations. For more information see the [https://www.owasp.org/index.php/Transaction_Authorization_Cheat_Sheet Transaction Authorization Cheat Sheet].<br />
<br />
==== TLS Client Authentication ====<br />
<br />
TLS Client Authentication, also known as two-way TLS authentication, consists of both, browser and server, sending their respective TLS certificates during the TLS handshake process. Just as you can validate the authenticity of a server by using the certificate and asking a well known Certificate Authority (CA) if the certificate is valid, the server can authenticate the user by receiving a certificate from the client and validating against a third party CA or its own CA. To do this, the server must provide the user with a certificate generated specifically for him, assigning values to the subject so that these can be used to determine what user the certificate should validate. The user installs the certificate on a browser and now uses it for the website.<br />
<br />
It is a good idea to do this when:<br />
<br />
*It is acceptable (or even preferred) that the user only has access to the website from only a single computer/browser.<br />
*The user is not easily scared by the process of installing TLS certificates on his browser or there will be someone, probably from IT support, that will do this for the user.<br />
*The website requires an extra step of security.<br />
*It is also a good thing to use when the website is for an intranet of a company or organization.<br />
<br />
It is generally not a good idea to use this method for widely and publicly available websites that will have an average user. For example, it wouldn't be a good idea to implement this for a website like Facebook. While this technique can prevent the user from having to type a password (thus protecting against an average keylogger from stealing it), it is still considered a good idea to consider using both a password and TLS client authentication combined.<br />
<br />
For more information, see: [https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake Client-authenticated TLS handshake]<br />
<br />
=== Authentication and Error Messages ===<br />
<br />
Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration. An application should respond (both HTTP and HTML) in a generic manner.<br />
<br />
===== Authentication Responses =====<br />
<br />
An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should also give no indication to the status of an existing account.<br />
<br />
===== Incorrect Response Examples =====<br />
<br />
*"Login for User foo: invalid password" <br />
*"Login failed, invalid user ID" <br />
*"Login failed; account disabled" <br />
*"Login failed; this user is not active"<br />
<br />
===== Correct Response Example =====<br />
<br />
*"Login failed; Invalid userID or password"<br />
<br />
The correct response does not indicate if the user ID or password is the incorrect parameter and hence inferring a valid user ID. <br />
<br />
===== Error Codes and URLs =====<br />
<br />
The application may return a different HTTP Error code depending on the authentication attempt response. It may respond with a 200 for a positive result and a 403 for a negative result. Even though a generic error page is shown to a user, the HTTP response code may differ which can leak information about whether the account is valid or not.<br />
<br />
=== Prevent Brute-Force Attacks ===<br />
<br />
If an attacker is able to guess passwords without the account becoming disabled due to failed authentication attempts, the attacker has an opportunity to continue with a brute force attack until the account is compromised. Automating brute-force/password guessing attacks on web applications is a trivial challenge. Password lockout mechanisms should be employed that lock out an account if more than a preset number of unsuccessful login attempts are made. Password lockout mechanisms have a logical weakness. An attacker that undertakes a large number of authentication attempts on known account names can produce a result that locks out entire blocks of user accounts. Given that the intent of a password lockout system is to protect from brute-force attacks, a sensible strategy is to lockout accounts for a period of time (e.g., 20 minutes). This significantly slows down attackers, while allowing the accounts to reopen automatically for legitimate users.<br />
<br />
Also, multi-factor authentication is a very powerful deterrent when trying to prevent brute force attacks since the credentials are a moving target. When multi-factor is implemented and active, account lockout may no longer be necessary.<br />
<br />
== Logging and Monitoring == <br />
Enable logging and monitoring of authentication functions to detect attacks / failures on a real time basis<br />
<br />
*Ensure that all failures are logged and reviewed<br />
*Ensure that all password failures are logged and reviewed<br />
*Ensure that all account lockouts are logged and reviewed<br />
<br />
== Use of authentication protocols that require no password ==<br />
<br />
While authentication through a user/password combination and using multi-factor authentication is considered generally secure, there are use cases where it isn't considered the best option or even safe. Examples of this are third party applications that desire connecting to the web application, either from a mobile device, another website, desktop or other situations. When this happens, it is NOT considered safe to allow the third party application to store the user/password combo, since then it extends the attack surface into their hands, where it isn't in your control. For this, and other use cases, there are several authentication protocols that can protect you from exposing your users' data to attackers.<br />
<br />
=== OAuth ===<br />
<br />
Open Authorization (OAuth) is a protocol that allows an application to authenticate against a server as a user, without requiring passwords or any third party server that acts as an identity provider. It uses a token generated by the server, and provides how the authorization flows most occur, so that a client, such as a mobile application, can tell the server what user is using the service. <br />
<br />
The recommendation is to use and implement OAuth 1.0a or OAuth 2.0, since the very first version (OAuth1.0) has been found to be vulnerable to session fixation.<br />
<br />
OAuth 2.0 relies on HTTPS for security and is currently used and implemented by API's from companies such as Facebook, Google, Twitter and Microsoft. OAuth1.0a is more difficult to use because it requires the use of cryptographic libraries for digital signatures. However, since OAuth1.0a does not rely on HTTPS for security it can be more suited for higher risk transactions.<br />
<br />
=== OpenId ===<br />
<br />
OpenId is an HTTP-based protocol that uses identity providers to validate that a user is who he says he is. It is a very simple protocol which allows a service provider initiated way for single sign-on (SSO). This allows the user to re-use a single identity given to a trusted OpenId identity provider and be the same user in multiple websites, without the need to provide any website the password, except for the OpenId identity provider.<br />
<br />
Due to its simplicity and that it provides protection of passwords, OpenId has been well adopted. Some of the well known identity providers for OpenId are Stack Exchange, Google, Facebook and Yahoo!<br />
<br />
For non-enterprise environments, OpenId is considered a secure and often better choice, as long as the identity provider is of trust.<br />
<br />
=== SAML ===<br />
<br />
Security Assertion Markup Language (SAML) is often considered to compete with OpenId. The most recommended version is 2.0, since it is very feature complete and provides a strong security. Like OpenId, SAML uses identity providers, but unlike OpenId, it is XML-based and provides more flexibility. SAML is based on browser redirects which send XML data. Furthermore, SAML isn't only initiated by a service provider; it can also be initiated from the identity provider. This allows the user to navigate through different portals while still being authenticated without having to do anything, making the process transparent.<br />
<br />
While OpenId has taken most of the consumer market, SAML is often the choice for enterprise applications. The reason for this is often that there are few OpenId identity providers which are considered of enterprise class (meaning that the way they validate the user identity doesn't have high standards required for enterprise identity). It is more common to see SAML being used inside of intranet websites, sometimes even using a server from the intranet as the identity provider.<br />
<br />
In the past few years, applications like SAP ERP and SharePoint (SharePoint by using Active Directory Federation Services 2.0) have decided to use SAML 2.0 authentication as an often preferred method for single sign-on implementations whenever enterprise federation is required for web services and web applications.<br />
<br />
'''See also: [[SAML Security Cheat Sheet]]'''<br />
<br />
=== FIDO ===<br />
The Fast Identity Online (FIDO) Alliance has created two protocols to facilitate online authentication : the Universal Authentication Framework (UAF) protocol and the Universal Second Factor (U2F) protocol. While UAF focuses on passwordless authentication, U2F allows the addition of a second factor to existing password-based authentication. Both protocols are based on a public key cryptography challenge-response model. <br />
<br />
UAF takes advantage of existing security technologies present on devices for authentication including fingerprint sensors, cameras(face biometrics), microphones(voice biometrics), Trusted Execution Environments(TEEs), Secure Elements(SEs) and others. The protocol is designed to plug-in these device capabilities into a common authentication framework. UAF works with both native applications and web applications.<br />
<br />
U2F augments password-based authentication using a hardware token (typically USB) that stores cryptographic authentication keys and uses them for signing. The user can use the same token as a second factor for multiple applications. U2F works with web applications. It provides '''protection against phishing''' by using the URL of the website to lookup the stored authentication key.<br />
<br />
== Session Management General Guidelines ==<br />
<br />
Session management is directly related to authentication. The '''Session Management General Guidelines''' previously available on this OWASP Authentication Cheat Sheet have been integrated into the [[Session Management Cheat Sheet]].<br />
<br />
== Password Managers ==<br />
<br />
Password managers are programs, browser plugins or web services that automate management of large number of different credentials, including memorizing and filling-in, generating random passwords on different sites etc. While use of password managers is subject to controversies and many organisations block their usage, their contribution to authentication security is positive, as pointed out by [https://www.ncsc.gov.uk/blog-post/what-does-ncsc-think-password-managers National Cyber Security Centre].<br />
<br />
Web applications should at least not make password managers job more difficult than necessary by observing the following recommendations:<br />
<br />
* use standard HTML forms for username and password input with appropriate `type` attributes,<br />
* do not artificially limit user passwords to a length "reasonable for humans" and allow passwords lengths up to 128 characters,<br />
* do not artificially prevent copy and paste on username and password fields,<br />
* avoid plugin-based login pages (Flash, Silverlight etc)<br />
<br />
As of 2017 [https://w3c.github.io/webappsec-credential-management/ Credential Management Level 1] standard for web browsers is being developed that may further facilitate interaction between password managers and complex log-in schemes (e.g. single sign-on).<br />
<br />
== Additional Resources ==<br />
<br />
A PDF of this cheatsheet has been created here. https://magic.piktochart.com/output/7003174-authentication-cheat-sheet<br />
<br />
== Authors and Primary Editors ==<br />
<br />
Eoin Keary eoinkeary[at]owasp.org <br/><br />
Jim Manico<br/><br />
Timo Goosen<br/><br />
Pawel Krawczyk<br/><br />
Sven Neuhaus<br/><br />
Manuel Aude Morales <br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Authentication_Cheat_Sheet&diff=228921Authentication Cheat Sheet2017-04-21T11:07:35Z<p>Pawel Krawczyk: /* Implement Proper Password Strength Controls */ the presentation is from 2014 and most of the recommendations are addressed here</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
<br/><b>English</b> | [[Authentication_Cheat_Sheet_Español | Spanish]]<br/><br />
<br/><br />
__TOC__{{TOC hidden}}<br />
= Introduction = <br />
<br />
'''Authentication''' is the process of verification that an individual, entity or website is who it claims to be. Authentication in the context of web applications is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.<br />
<br />
'''Session Management''' is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.<br />
<br />
== Authentication General Guidelines ==<br />
<br />
=== User IDs ===<br />
<br />
Make sure your usernames/userids are case insensitive. User 'smith' and user 'Smith' should be the same user. User names should also be unique. For high security applications usernames could be assigned and secret instead of user-defined public data.<br />
<br />
==== Email address as a User ID ====<br />
<br />
For information on validating email addresses, please visit the [https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#Email_Address_Validation input validation cheatsheet email discussion].<br />
<br />
=== Implement Proper Password Strength Controls ===<br />
<br />
A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password through either manual or automated means. The following characteristics define a strong password: <br />
<br />
==== Password Length ====<br />
<br />
Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess. <br />
<br />
* '''Minimum''' length of the passwords should be '''enforced''' by the application.<br />
** Passwords '''shorter than 10 characters''' are considered to be weak ([http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf NIST SP800-132]).<br />
<br />
While minimum length enforcement may cause problems with memorizing passwords among some users, applications should encourage them to set ''passphrases'' (sentences or combination of words) that can be much longer than typical passwords and yet much easier to remember.<br />
<br />
* '''Maximum''' password length should not be set '''too low''', as it will prevent users from creating passphrases. Typical maximum length is 128 characters.<br />
** Passphrases shorter than 20 characters are usually considered weak if they only consist of lower case Latin characters.<br />
<br />
==== Password Complexity ====<br />
<br />
Applications should enforce password complexity rules to discourage easy to guess passwords. Password mechanisms should allow virtually any character the user can type to be part of their password, including the space character. Passwords should, obviously, be case sensitive in order to increase their complexity. Occasionally, we find systems where passwords aren't case sensitive, frequently due to legacy system issues like old mainframes that didn't have case sensitive passwords.<br />
<br />
The password change mechanism should require a minimum level of complexity that makes sense for the application and its user population. For example:<br />
<br />
*Password must meet at least 3 out of the following 4 complexity rules<br />
**at least 1 uppercase character (A-Z) <br />
**at least 1 lowercase character (a-z) <br />
**at least 1 digit (0-9) <br />
**at least 1 [[Password special characters|special character (punctuation)]] &mdash; do not forget to treat space as special characters too<br />
*at least 10 characters <br />
*at most 128 characters<br />
*not more than 2 identical characters in a row (e.g., 111 not allowed)<br />
<br />
Further reading:<br />
<br />
* [https://www.youtube.com/watch?v=zUM7i8fsf0g Your Password Complexity Requirements are Worthless - OWASP AppSecUSA 2014] presentation for further discussion of legacy password complexity rules<br />
* [https://www.korelogic.com/Resources/Presentations/bsidesavl_pathwell_2014-06.pdf PathWell: Password Topology<br />
Histogram Wear-Leveling]<br />
<br />
==== Password Topologies ====<br />
<br />
* Ban commonly used password topologies<br />
* Force multiple users to use different password topologies<br />
* Require a minimum topology change between old and new passwords<br />
<br />
==== Additional Information ====<br />
<br />
* Make sure that every character the user types in is actually included in the password. We've seen systems that truncate the password at a length shorter than what the user provided (e.g., truncated at 15 characters when they entered 20).<br />
* As application's require more complex password policies, they need to be very clear about what these policies are. The required policy needs to be explicitly stated on the password change page<br />
* If the new password doesn't comply with the complexity policy, the error message should describe EVERY complexity rule that the new password does not comply with, not just the 1st rule it doesn't comply with.<br />
<br />
=== Implement Secure Password Recovery Mechanism ===<br />
<br />
It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see [[Forgot Password Cheat Sheet]] for details on this feature.<br />
<br />
=== Store Passwords in a Secure Fashion ===<br />
<br />
It is critical for a application to store a password using the right cryptographic technique. Please see [[Password Storage Cheat Sheet]] for details on this feature.<br />
<br />
=== Transmit Passwords Only Over TLS or Other Strong Transport ===<br />
<br />
See: [[Transport Layer Protection Cheat Sheet]]<br />
<br />
The login page and all subsequent authenticated pages must be exclusively accessed over TLS or other strong transport. The initial login page, referred to as the "login landing page", must be served over TLS or other strong transport. Failure to utilize TLS or other strong transport 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 or other strong transport for authenticated pages after login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session.<br />
<br />
=== Require Re-authentication for Sensitive Features ===<br />
<br />
In order to mitigate CSRF and session hijacking, it's important to require the current credentials for an account before updating sensitive account information such as the user's password, user's email, or before sensitive transactions, such as shipping a purchase to a new address. Without this countermeasure, an attacker may be able to execute sensitive transactions through a CSRF or XSS attack without needing to know the user's current credentials. Additionally, an attacker may get temporary physical access to a user's browser or steal their session ID to take over the user's session.<br />
<br />
=== Consider Strong Transaction Authentication ===<br />
<br />
Some applications should use a second factor to check whether a user may perform sensitive operations. For more information see the [https://www.owasp.org/index.php/Transaction_Authorization_Cheat_Sheet Transaction Authorization Cheat Sheet].<br />
<br />
==== TLS Client Authentication ====<br />
<br />
TLS Client Authentication, also known as two-way TLS authentication, consists of both, browser and server, sending their respective TLS certificates during the TLS handshake process. Just as you can validate the authenticity of a server by using the certificate and asking a well known Certificate Authority (CA) if the certificate is valid, the server can authenticate the user by receiving a certificate from the client and validating against a third party CA or its own CA. To do this, the server must provide the user with a certificate generated specifically for him, assigning values to the subject so that these can be used to determine what user the certificate should validate. The user installs the certificate on a browser and now uses it for the website.<br />
<br />
It is a good idea to do this when:<br />
<br />
*It is acceptable (or even preferred) that the user only has access to the website from only a single computer/browser.<br />
*The user is not easily scared by the process of installing TLS certificates on his browser or there will be someone, probably from IT support, that will do this for the user.<br />
*The website requires an extra step of security.<br />
*It is also a good thing to use when the website is for an intranet of a company or organization.<br />
<br />
It is generally not a good idea to use this method for widely and publicly available websites that will have an average user. For example, it wouldn't be a good idea to implement this for a website like Facebook. While this technique can prevent the user from having to type a password (thus protecting against an average keylogger from stealing it), it is still considered a good idea to consider using both a password and TLS client authentication combined.<br />
<br />
For more information, see: [https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake Client-authenticated TLS handshake]<br />
<br />
=== Authentication and Error Messages ===<br />
<br />
Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration. An application should respond (both HTTP and HTML) in a generic manner.<br />
<br />
===== Authentication Responses =====<br />
<br />
An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should also give no indication to the status of an existing account.<br />
<br />
===== Incorrect Response Examples =====<br />
<br />
*"Login for User foo: invalid password" <br />
*"Login failed, invalid user ID" <br />
*"Login failed; account disabled" <br />
*"Login failed; this user is not active"<br />
<br />
===== Correct Response Example =====<br />
<br />
*"Login failed; Invalid userID or password"<br />
<br />
The correct response does not indicate if the user ID or password is the incorrect parameter and hence inferring a valid user ID. <br />
<br />
===== Error Codes and URLs =====<br />
<br />
The application may return a different HTTP Error code depending on the authentication attempt response. It may respond with a 200 for a positive result and a 403 for a negative result. Even though a generic error page is shown to a user, the HTTP response code may differ which can leak information about whether the account is valid or not.<br />
<br />
=== Prevent Brute-Force Attacks ===<br />
<br />
If an attacker is able to guess passwords without the account becoming disabled due to failed authentication attempts, the attacker has an opportunity to continue with a brute force attack until the account is compromised. Automating brute-force/password guessing attacks on web applications is a trivial challenge. Password lockout mechanisms should be employed that lock out an account if more than a preset number of unsuccessful login attempts are made. Password lockout mechanisms have a logical weakness. An attacker that undertakes a large number of authentication attempts on known account names can produce a result that locks out entire blocks of user accounts. Given that the intent of a password lockout system is to protect from brute-force attacks, a sensible strategy is to lockout accounts for a period of time (e.g., 20 minutes). This significantly slows down attackers, while allowing the accounts to reopen automatically for legitimate users.<br />
<br />
Also, multi-factor authentication is a very powerful deterrent when trying to prevent brute force attacks since the credentials are a moving target. When multi-factor is implemented and active, account lockout may no longer be necessary.<br />
<br />
== Logging and Monitoring == <br />
Enable logging and monitoring of authentication functions to detect attacks / failures on a real time basis<br />
<br />
*Ensure that all failures are logged and reviewed<br />
*Ensure that all password failures are logged and reviewed<br />
*Ensure that all account lockouts are logged and reviewed<br />
<br />
== Use of authentication protocols that require no password ==<br />
<br />
While authentication through a user/password combination and using multi-factor authentication is considered generally secure, there are use cases where it isn't considered the best option or even safe. Examples of this are third party applications that desire connecting to the web application, either from a mobile device, another website, desktop or other situations. When this happens, it is NOT considered safe to allow the third party application to store the user/password combo, since then it extends the attack surface into their hands, where it isn't in your control. For this, and other use cases, there are several authentication protocols that can protect you from exposing your users' data to attackers.<br />
<br />
=== OAuth ===<br />
<br />
Open Authorization (OAuth) is a protocol that allows an application to authenticate against a server as a user, without requiring passwords or any third party server that acts as an identity provider. It uses a token generated by the server, and provides how the authorization flows most occur, so that a client, such as a mobile application, can tell the server what user is using the service. <br />
<br />
The recommendation is to use and implement OAuth 1.0a or OAuth 2.0, since the very first version (OAuth1.0) has been found to be vulnerable to session fixation.<br />
<br />
OAuth 2.0 relies on HTTPS for security and is currently used and implemented by API's from companies such as Facebook, Google, Twitter and Microsoft. OAuth1.0a is more difficult to use because it requires the use of cryptographic libraries for digital signatures. However, since OAuth1.0a does not rely on HTTPS for security it can be more suited for higher risk transactions.<br />
<br />
=== OpenId ===<br />
<br />
OpenId is an HTTP-based protocol that uses identity providers to validate that a user is who he says he is. It is a very simple protocol which allows a service provider initiated way for single sign-on (SSO). This allows the user to re-use a single identity given to a trusted OpenId identity provider and be the same user in multiple websites, without the need to provide any website the password, except for the OpenId identity provider.<br />
<br />
Due to its simplicity and that it provides protection of passwords, OpenId has been well adopted. Some of the well known identity providers for OpenId are Stack Exchange, Google, Facebook and Yahoo!<br />
<br />
For non-enterprise environments, OpenId is considered a secure and often better choice, as long as the identity provider is of trust.<br />
<br />
=== SAML ===<br />
<br />
Security Assertion Markup Language (SAML) is often considered to compete with OpenId. The most recommended version is 2.0, since it is very feature complete and provides a strong security. Like OpenId, SAML uses identity providers, but unlike OpenId, it is XML-based and provides more flexibility. SAML is based on browser redirects which send XML data. Furthermore, SAML isn't only initiated by a service provider; it can also be initiated from the identity provider. This allows the user to navigate through different portals while still being authenticated without having to do anything, making the process transparent.<br />
<br />
While OpenId has taken most of the consumer market, SAML is often the choice for enterprise applications. The reason for this is often that there are few OpenId identity providers which are considered of enterprise class (meaning that the way they validate the user identity doesn't have high standards required for enterprise identity). It is more common to see SAML being used inside of intranet websites, sometimes even using a server from the intranet as the identity provider.<br />
<br />
In the past few years, applications like SAP ERP and SharePoint (SharePoint by using Active Directory Federation Services 2.0) have decided to use SAML 2.0 authentication as an often preferred method for single sign-on implementations whenever enterprise federation is required for web services and web applications.<br />
<br />
'''See also: [[SAML Security Cheat Sheet]]'''<br />
<br />
=== FIDO ===<br />
The Fast Identity Online (FIDO) Alliance has created two protocols to facilitate online authentication : the Universal Authentication Framework (UAF) protocol and the Universal Second Factor (U2F) protocol. While UAF focuses on passwordless authentication, U2F allows the addition of a second factor to existing password-based authentication. Both protocols are based on a public key cryptography challenge-response model. <br />
<br />
UAF takes advantage of existing security technologies present on devices for authentication including fingerprint sensors, cameras(face biometrics), microphones(voice biometrics), Trusted Execution Environments(TEEs), Secure Elements(SEs) and others. The protocol is designed to plug-in these device capabilities into a common authentication framework. UAF works with both native applications and web applications.<br />
<br />
U2F augments password-based authentication using a hardware token (typically USB) that stores cryptographic authentication keys and uses them for signing. The user can use the same token as a second factor for multiple applications. U2F works with web applications. It provides '''protection against phishing''' by using the URL of the website to lookup the stored authentication key.<br />
<br />
== Session Management General Guidelines ==<br />
<br />
Session management is directly related to authentication. The '''Session Management General Guidelines''' previously available on this OWASP Authentication Cheat Sheet have been integrated into the [[Session Management Cheat Sheet]].<br />
<br />
== Password Managers ==<br />
<br />
Password managers are programs, browser plugins or web services that automate management of large number of different credentials, including memorizing and filling-in, generating random passwords on different sites etc. While use of password managers is subject to controversies and many organisations block their usage, their contribution to authentication security is positive, as pointed out by [https://www.ncsc.gov.uk/blog-post/what-does-ncsc-think-password-managers National Cyber Security Centre].<br />
<br />
Web applications should at least not make password managers job more difficult than necessary by observing the following recommendations:<br />
<br />
* use standard HTML forms for username and password input with appropriate `type` attributes,<br />
* do not artificially limit user passwords to a length "reasonable for humans" and allow passwords lengths up to 128 characters,<br />
* do not artificially prevent copy and paste on username and password fields,<br />
* avoid plugin-based login pages (Flash, Silverlight etc)<br />
<br />
As of 2017 [https://w3c.github.io/webappsec-credential-management/ Credential Management Level 1] standard for web browsers is being developed that may further facilitate interaction between password managers and complex log-in schemes (e.g. single sign-on).<br />
<br />
== Additional Resources ==<br />
<br />
A PDF of this cheatsheet has been created here. https://magic.piktochart.com/output/7003174-authentication-cheat-sheet<br />
<br />
== Authors and Primary Editors ==<br />
<br />
Eoin Keary eoinkeary[at]owasp.org <br/><br />
Jim Manico<br/><br />
Timo Goosen<br/><br />
Pawel Krawczyk<br/><br />
Sven Neuhaus<br/><br />
Manuel Aude Morales <br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Authentication_Cheat_Sheet&diff=228919Authentication Cheat Sheet2017-04-21T11:01:15Z<p>Pawel Krawczyk: /* Password Managers */ National Cyber Security Centre on password managers, update the recommendations</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
<br/><b>English</b> | [[Authentication_Cheat_Sheet_Español | Spanish]]<br/><br />
<br/><br />
__TOC__{{TOC hidden}}<br />
= Introduction = <br />
<br />
'''Authentication''' is the process of verification that an individual, entity or website is who it claims to be. Authentication in the context of web applications is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.<br />
<br />
'''Session Management''' is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.<br />
<br />
== Authentication General Guidelines ==<br />
<br />
=== User IDs ===<br />
<br />
Make sure your usernames/userids are case insensitive. User 'smith' and user 'Smith' should be the same user. User names should also be unique. For high security applications usernames could be assigned and secret instead of user-defined public data.<br />
<br />
==== Email address as a User ID ====<br />
<br />
For information on validating email addresses, please visit the [https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#Email_Address_Validation input validation cheatsheet email discussion].<br />
<br />
=== Implement Proper Password Strength Controls ===<br />
<br />
A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password through either manual or automated means. The following characteristics define a strong password: <br />
<br />
==== Warning ====<br />
<br />
The following advice is disputed. Please view the OWASP presentation, "[https://www.youtube.com/watch?v=zUM7i8fsf0g Your Password Complexity Requirements are Worthless - OWASP AppSecUSA 2014]" for more information.<br />
<br />
==== Password Length ====<br />
<br />
Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess. <br />
<br />
* '''Minimum''' length of the passwords should be '''enforced''' by the application.<br />
** Passwords '''shorter than 10 characters''' are considered to be weak ([http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf]).<br />
<br />
While minimum length enforcement may cause problems with memorizing passwords among some users, applications should encourage them to set ''passphrases'' (sentences or combination of words) that can be much longer than typical passwords and yet much easier to remember.<br />
<br />
* '''Maximum''' password length should not be set '''too low''', as it will prevent users from creating passphrases. Typical maximum length is 128 characters.<br />
** Passphrases shorter than 20 characters are usually considered weak if they only consist of lower case Latin characters.<br />
<br />
==== Password Complexity ====<br />
<br />
Applications should enforce password complexity rules to discourage easy to guess passwords. Password mechanisms should allow virtually any character the user can type to be part of their password, including the space character. Passwords should, obviously, be case sensitive in order to increase their complexity. Occasionally, we find systems where passwords aren't case sensitive, frequently due to legacy system issues like old mainframes that didn't have case sensitive passwords.<br />
<br />
The password change mechanism should require a minimum level of complexity that makes sense for the application and its user population. For example:<br />
<br />
*Password must meet at least 3 out of the following 4 complexity rules<br />
**at least 1 uppercase character (A-Z) <br />
**at least 1 lowercase character (a-z) <br />
**at least 1 digit (0-9) <br />
**at least 1 [[Password special characters|special character (punctuation)]] &mdash; do not forget to treat space as special characters too<br />
*at least 10 characters <br />
*at most 128 characters<br />
*not more than 2 identical characters in a row (e.g., 111 not allowed)<br />
<br />
==== Password Topologies ====<br />
<br />
* Ban commonly used password topologies<br />
* Force multiple users to use different password topologies<br />
* Require a minimum topology change between old and new passwords<br />
<br />
==== Additional Information ====<br />
<br />
* Make sure that every character the user types in is actually included in the password. We've seen systems that truncate the password at a length shorter than what the user provided (e.g., truncated at 15 characters when they entered 20).<br />
* As application's require more complex password policies, they need to be very clear about what these policies are. The required policy needs to be explicitly stated on the password change page<br />
* If the new password doesn't comply with the complexity policy, the error message should describe EVERY complexity rule that the new password does not comply with, not just the 1st rule it doesn't comply with.<br />
<br />
=== Implement Secure Password Recovery Mechanism ===<br />
<br />
It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see [[Forgot Password Cheat Sheet]] for details on this feature.<br />
<br />
=== Store Passwords in a Secure Fashion ===<br />
<br />
It is critical for a application to store a password using the right cryptographic technique. Please see [[Password Storage Cheat Sheet]] for details on this feature.<br />
<br />
=== Transmit Passwords Only Over TLS or Other Strong Transport ===<br />
<br />
See: [[Transport Layer Protection Cheat Sheet]]<br />
<br />
The login page and all subsequent authenticated pages must be exclusively accessed over TLS or other strong transport. The initial login page, referred to as the "login landing page", must be served over TLS or other strong transport. Failure to utilize TLS or other strong transport 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 or other strong transport for authenticated pages after login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session.<br />
<br />
=== Require Re-authentication for Sensitive Features ===<br />
<br />
In order to mitigate CSRF and session hijacking, it's important to require the current credentials for an account before updating sensitive account information such as the user's password, user's email, or before sensitive transactions, such as shipping a purchase to a new address. Without this countermeasure, an attacker may be able to execute sensitive transactions through a CSRF or XSS attack without needing to know the user's current credentials. Additionally, an attacker may get temporary physical access to a user's browser or steal their session ID to take over the user's session.<br />
<br />
=== Consider Strong Transaction Authentication ===<br />
<br />
Some applications should use a second factor to check whether a user may perform sensitive operations. For more information see the [https://www.owasp.org/index.php/Transaction_Authorization_Cheat_Sheet Transaction Authorization Cheat Sheet].<br />
<br />
==== TLS Client Authentication ====<br />
<br />
TLS Client Authentication, also known as two-way TLS authentication, consists of both, browser and server, sending their respective TLS certificates during the TLS handshake process. Just as you can validate the authenticity of a server by using the certificate and asking a well known Certificate Authority (CA) if the certificate is valid, the server can authenticate the user by receiving a certificate from the client and validating against a third party CA or its own CA. To do this, the server must provide the user with a certificate generated specifically for him, assigning values to the subject so that these can be used to determine what user the certificate should validate. The user installs the certificate on a browser and now uses it for the website.<br />
<br />
It is a good idea to do this when:<br />
<br />
*It is acceptable (or even preferred) that the user only has access to the website from only a single computer/browser.<br />
*The user is not easily scared by the process of installing TLS certificates on his browser or there will be someone, probably from IT support, that will do this for the user.<br />
*The website requires an extra step of security.<br />
*It is also a good thing to use when the website is for an intranet of a company or organization.<br />
<br />
It is generally not a good idea to use this method for widely and publicly available websites that will have an average user. For example, it wouldn't be a good idea to implement this for a website like Facebook. While this technique can prevent the user from having to type a password (thus protecting against an average keylogger from stealing it), it is still considered a good idea to consider using both a password and TLS client authentication combined.<br />
<br />
For more information, see: [https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake Client-authenticated TLS handshake]<br />
<br />
=== Authentication and Error Messages ===<br />
<br />
Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration. An application should respond (both HTTP and HTML) in a generic manner.<br />
<br />
===== Authentication Responses =====<br />
<br />
An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should also give no indication to the status of an existing account.<br />
<br />
===== Incorrect Response Examples =====<br />
<br />
*"Login for User foo: invalid password" <br />
*"Login failed, invalid user ID" <br />
*"Login failed; account disabled" <br />
*"Login failed; this user is not active"<br />
<br />
===== Correct Response Example =====<br />
<br />
*"Login failed; Invalid userID or password"<br />
<br />
The correct response does not indicate if the user ID or password is the incorrect parameter and hence inferring a valid user ID. <br />
<br />
===== Error Codes and URLs =====<br />
<br />
The application may return a different HTTP Error code depending on the authentication attempt response. It may respond with a 200 for a positive result and a 403 for a negative result. Even though a generic error page is shown to a user, the HTTP response code may differ which can leak information about whether the account is valid or not.<br />
<br />
=== Prevent Brute-Force Attacks ===<br />
<br />
If an attacker is able to guess passwords without the account becoming disabled due to failed authentication attempts, the attacker has an opportunity to continue with a brute force attack until the account is compromised. Automating brute-force/password guessing attacks on web applications is a trivial challenge. Password lockout mechanisms should be employed that lock out an account if more than a preset number of unsuccessful login attempts are made. Password lockout mechanisms have a logical weakness. An attacker that undertakes a large number of authentication attempts on known account names can produce a result that locks out entire blocks of user accounts. Given that the intent of a password lockout system is to protect from brute-force attacks, a sensible strategy is to lockout accounts for a period of time (e.g., 20 minutes). This significantly slows down attackers, while allowing the accounts to reopen automatically for legitimate users.<br />
<br />
Also, multi-factor authentication is a very powerful deterrent when trying to prevent brute force attacks since the credentials are a moving target. When multi-factor is implemented and active, account lockout may no longer be necessary.<br />
<br />
== Logging and Monitoring == <br />
Enable logging and monitoring of authentication functions to detect attacks / failures on a real time basis<br />
<br />
*Ensure that all failures are logged and reviewed<br />
*Ensure that all password failures are logged and reviewed<br />
*Ensure that all account lockouts are logged and reviewed<br />
<br />
== Use of authentication protocols that require no password ==<br />
<br />
While authentication through a user/password combination and using multi-factor authentication is considered generally secure, there are use cases where it isn't considered the best option or even safe. Examples of this are third party applications that desire connecting to the web application, either from a mobile device, another website, desktop or other situations. When this happens, it is NOT considered safe to allow the third party application to store the user/password combo, since then it extends the attack surface into their hands, where it isn't in your control. For this, and other use cases, there are several authentication protocols that can protect you from exposing your users' data to attackers.<br />
<br />
=== OAuth ===<br />
<br />
Open Authorization (OAuth) is a protocol that allows an application to authenticate against a server as a user, without requiring passwords or any third party server that acts as an identity provider. It uses a token generated by the server, and provides how the authorization flows most occur, so that a client, such as a mobile application, can tell the server what user is using the service. <br />
<br />
The recommendation is to use and implement OAuth 1.0a or OAuth 2.0, since the very first version (OAuth1.0) has been found to be vulnerable to session fixation.<br />
<br />
OAuth 2.0 relies on HTTPS for security and is currently used and implemented by API's from companies such as Facebook, Google, Twitter and Microsoft. OAuth1.0a is more difficult to use because it requires the use of cryptographic libraries for digital signatures. However, since OAuth1.0a does not rely on HTTPS for security it can be more suited for higher risk transactions.<br />
<br />
=== OpenId ===<br />
<br />
OpenId is an HTTP-based protocol that uses identity providers to validate that a user is who he says he is. It is a very simple protocol which allows a service provider initiated way for single sign-on (SSO). This allows the user to re-use a single identity given to a trusted OpenId identity provider and be the same user in multiple websites, without the need to provide any website the password, except for the OpenId identity provider.<br />
<br />
Due to its simplicity and that it provides protection of passwords, OpenId has been well adopted. Some of the well known identity providers for OpenId are Stack Exchange, Google, Facebook and Yahoo!<br />
<br />
For non-enterprise environments, OpenId is considered a secure and often better choice, as long as the identity provider is of trust.<br />
<br />
=== SAML ===<br />
<br />
Security Assertion Markup Language (SAML) is often considered to compete with OpenId. The most recommended version is 2.0, since it is very feature complete and provides a strong security. Like OpenId, SAML uses identity providers, but unlike OpenId, it is XML-based and provides more flexibility. SAML is based on browser redirects which send XML data. Furthermore, SAML isn't only initiated by a service provider; it can also be initiated from the identity provider. This allows the user to navigate through different portals while still being authenticated without having to do anything, making the process transparent.<br />
<br />
While OpenId has taken most of the consumer market, SAML is often the choice for enterprise applications. The reason for this is often that there are few OpenId identity providers which are considered of enterprise class (meaning that the way they validate the user identity doesn't have high standards required for enterprise identity). It is more common to see SAML being used inside of intranet websites, sometimes even using a server from the intranet as the identity provider.<br />
<br />
In the past few years, applications like SAP ERP and SharePoint (SharePoint by using Active Directory Federation Services 2.0) have decided to use SAML 2.0 authentication as an often preferred method for single sign-on implementations whenever enterprise federation is required for web services and web applications.<br />
<br />
'''See also: [[SAML Security Cheat Sheet]]'''<br />
<br />
=== FIDO ===<br />
The Fast Identity Online (FIDO) Alliance has created two protocols to facilitate online authentication : the Universal Authentication Framework (UAF) protocol and the Universal Second Factor (U2F) protocol. While UAF focuses on passwordless authentication, U2F allows the addition of a second factor to existing password-based authentication. Both protocols are based on a public key cryptography challenge-response model. <br />
<br />
UAF takes advantage of existing security technologies present on devices for authentication including fingerprint sensors, cameras(face biometrics), microphones(voice biometrics), Trusted Execution Environments(TEEs), Secure Elements(SEs) and others. The protocol is designed to plug-in these device capabilities into a common authentication framework. UAF works with both native applications and web applications.<br />
<br />
U2F augments password-based authentication using a hardware token (typically USB) that stores cryptographic authentication keys and uses them for signing. The user can use the same token as a second factor for multiple applications. U2F works with web applications. It provides '''protection against phishing''' by using the URL of the website to lookup the stored authentication key.<br />
<br />
== Session Management General Guidelines ==<br />
<br />
Session management is directly related to authentication. The '''Session Management General Guidelines''' previously available on this OWASP Authentication Cheat Sheet have been integrated into the [[Session Management Cheat Sheet]].<br />
<br />
== Password Managers ==<br />
<br />
Password managers are programs, browser plugins or web services that automate management of large number of different credentials, including memorizing and filling-in, generating random passwords on different sites etc. While use of password managers is subject to controversies and many organisations block their usage, their contribution to authentication security is positive, as pointed out by [https://www.ncsc.gov.uk/blog-post/what-does-ncsc-think-password-managers National Cyber Security Centre].<br />
<br />
Web applications should at least not make password managers job more difficult than necessary by observing the following recommendations:<br />
<br />
* use standard HTML forms for username and password input with appropriate `type` attributes,<br />
* do not artificially limit user passwords to a length "reasonable for humans" and allow passwords lengths up to 128 characters,<br />
* do not artificially prevent copy and paste on username and password fields,<br />
* avoid plugin-based login pages (Flash, Silverlight etc)<br />
<br />
As of 2017 [https://w3c.github.io/webappsec-credential-management/ Credential Management Level 1] standard for web browsers is being developed that may further facilitate interaction between password managers and complex log-in schemes (e.g. single sign-on).<br />
<br />
== Additional Resources ==<br />
<br />
A PDF of this cheatsheet has been created here. https://magic.piktochart.com/output/7003174-authentication-cheat-sheet<br />
<br />
== Authors and Primary Editors ==<br />
<br />
Eoin Keary eoinkeary[at]owasp.org <br/><br />
Jim Manico<br/><br />
Timo Goosen<br/><br />
Pawel Krawczyk<br/><br />
Sven Neuhaus<br/><br />
Manuel Aude Morales <br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=User:Pawel_Krawczyk&diff=228149User:Pawel Krawczyk2017-03-30T13:06:51Z<p>Pawel Krawczyk: </p>
<hr />
<div>'''Paweł Krawczyk'''<br />
<br />
* [https://www.linkedin.com/in/pawelkrawczyk my LinkedIn profile]<br />
* [https://ipsec.pl/ IPSec.pl my application security and electronic signature articles]<br />
* [https://webcookies.org/ free web application cookie and security scanner]<br />
* [https://echelon.pl/ my articles in Polish]<br />
<br />
My draft articles:<br />
<br />
* [[User:Pawel_Krawczyk/List_of_useful_HTTP_headers]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=User:Pawel_Krawczyk&diff=223584User:Pawel Krawczyk2016-11-22T06:52:07Z<p>Pawel Krawczyk: </p>
<hr />
<div>'''Paweł Krawczyk'''<br />
<br />
* [https://www.linkedin.com/in/pawelkrawczyk my LinkedIn profile]<br />
* [https://ipsec.pl/ IPSec.pl my application security and electronic signature articles]<br />
* [https://webcookies.org/ my tool for web application cookie inspection]<br />
* [https://echelon.pl/ my articles in Polish]<br />
<br />
My draft articles:<br />
<br />
* [[User:Pawel_Krawczyk/List_of_useful_HTTP_headers]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Transport_Layer_Protection_Cheat_Sheet&diff=195988Transport Layer Protection Cheat Sheet2015-06-09T20:54:14Z<p>Pawel Krawczyk: /* Rule - REMOVED - Do Not Perform Redirects from Non-TLS Page to TLS Login Page */ if it's removed, it should be removed</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
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> <br />
<br />
== Architectural Decision ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
= Providing Transport Layer Protection with SSL/TLS =<br />
<br />
== Benefits ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Basic Requirements ==<br />
<br />
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.<br />
<br />
== SSL vs. TLS ==<br />
<br />
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"]].<br />
<br />
[[Image:Asvs_cryptomodule.gif|thumb|350px|right|Cryptomodule Parts and Operation]]<br />
<br />
== When to Use a FIPS 140-2 Validated Cryptomodule ==<br />
<br />
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]. <br />
<br />
A cryptomodule, whether it is a software library or a hardware device, basically consists of three parts:<br />
<br />
* Components that implement cryptographic algorithms (symmetric and asymmetric algorithms, hash algorithms, random number generator algorithms, and message authentication code algorithms) <br />
* Components that call and manage cryptographic functions (inputs and outputs include cryptographic keys and so-called critical security parameters) <br />
* A physical container around the components that implement cryptographic algorithms and the components that call and manage cryptographic functions<br />
<br />
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:<br />
<br />
* Calling and managing cryptographic functions<br />
* Securely Handling inputs and output<br />
* Ensuring the secure construction of the physical container around the components<br />
<br />
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.<br />
<br />
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].<br />
<br />
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]<br />
<br />
== Secure Server Design ==<br />
<br />
=== Rule - Use TLS for All Login Pages and All Authenticated Pages ===<br />
<br />
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. <br />
<br />
=== Rule - Use TLS on Any Networks (External and Internal) Transmitting Sensitive Data ===<br />
<br />
All networks, both external and internal, which transmit sensitive data must utilize TLS or an equivalent transport layer security mechanism. 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. <br />
<br />
=== Rule - Do Not Provide Non-TLS Pages for Secure Content ===<br />
<br />
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.<br />
<br />
=== Rule - Do Not Mix TLS and Non-TLS Content ===<br />
<br />
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. <br />
<br />
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'<br />
<br />
=== Rule - Use "Secure" Cookie Flag ===<br />
<br />
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.<br />
<br />
=== Rule - Keep Sensitive Data Out of the URL ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
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]<br />
<br />
=== Rule - Prevent Caching of Sensitive Data ===<br />
<br />
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.<br />
<br />
=== Rule - Use HTTP Strict Transport Security ===<br />
<br />
See: [[HTTP Strict Transport Security]]<br />
<br />
===Rule - Use Public Key Pinning===<br />
<br />
See: [[Certificate and Public Key Pinning]]<br />
<br />
<span id="Server_Certificate_and_Protocol_Configuration"></span> <!-- backward compatible anchor --><br />
<br />
== Server Certificate ==<br />
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.<br />
<br />
=== Rule - Use Strong Keys & Protect Them ===<br />
<br />
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.<br />
<br />
=== Rule - Use a Certificate That Supports Required Domain Names ===<br />
<br />
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.<br />
<br />
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).<br />
<br />
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".<br />
<br />
=== Rule - Use Fully Qualified Names in Certificates ===<br />
<br />
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.<br />
<br />
=== Rule - Do Not Use Wildcard Certificates ===<br />
<br />
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.<br />
<br />
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://www.cabforum.org/EV_Certificate_Guidelines.pdf EV Certificate Guidelines].<br />
<br />
=== Rule - Do Not Use RFC 1918 Addresses in Certificates ===<br />
<br />
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.<br />
<br />
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."<br />
<br />
=== Rule - Use an Appropriate Certification Authority for the Application's User Base ===<br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
=== Rule - Always Provide All Needed Certificates ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
To avoid the “Which Directory?" problem, a server should provide the user with all required certificates used in a path validation.<br />
<br />
=== Rule - Be aware of and have a plan for the SHA-1 deprecation plan ===<br />
<br />
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]<br />
<br />
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. <br />
<br />
== Server Protocol and Cipher Configuration ==<br />
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.<br />
<br />
=== Rule - Only Support Strong Protocols ===<br />
<br />
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 - TLS1.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.<br />
<br />
[http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers Nearly all modern browsers support at least TLS 1.0]. As of February 2013, contemporary browsers (Chrome v20+, 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 which support the protocols. The client and server (usually) negotiate the best protocol, that is supported on both sides.<br />
<br />
TLS 1.0 is still widely used as 'best' protocol by a lot of browsers, that are not patched to the very latest version. It suffers [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 only after risk analysis and acceptance.<br />
<br />
Under no circumstances neither SSLv2 nor SSLv3 should be enabled as a protocol selection:<br />
* The [http://www.schneier.com/paper-ssl-revised.pdf SSLv2 protocol is broken] and does not provide adequate transport layer protection.<br />
* [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.<br />
<br />
=== Rule - Prefer Ephemeral Key Exchanges ===<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Rule - Only Support Strong Cryptographic Ciphers ===<br />
<br />
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 CipherSuites:<br />
* Use the very latest recommendations, they may be volantile these days<br />
* Setup your Policy to get a Whitelist for recommended Ciphers, e.g.:<br />
** Activate to set the Cipher Order by the Server<br />
** 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]<br />
** 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/draft-irtf-cfrg-curves-02 DRAFT-irtf-cfrg-curves]), that is not yet defined for TLS, cf. [http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 IANA] <!--- as at June 2014 ---><br />
** 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]) <!--- as at June 2014 ---><br />
** 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.<br />
** Watch also for Stream Ciphers which XOR the key stream with plaintext (such as AES/CTR mode) <!--- Jim please check this ---><br />
** Priorize the ciphers by the sizes of the Cipher and the MAC<br />
** Use SHA1 or above for digests, prefer SHA2 (or equivalent)<br />
** 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_3DES_EDE_CBC_SHA (0xa) does this job.<br />
*** Disable cipher suites that do not offer encryption (eNULL, NULL)<br />
*** 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).<br />
*** Disable export level ciphers (EXP, eg. ciphers containing DES)<br />
*** 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.html BSI: TR-02102 Part 2 (German)])<br />
*** Disable the use of MD5 as a hashing mechanism for payload traffic<br />
*** Disable the use of IDEA Cipher Suites (see [https://tools.ietf.org/html/rfc5469])<br />
*** Disable RC4 cipher suites (see [https://tools.ietf.org/html/rfc7465], [http://www.isg.rhul.ac.uk/tls/])<br />
** Ciphers should be usable for DH-Pamameters >= 2048 bits, without blocking legacy browsers (The cipher ‘DHE-RSA-AES128-SHA’ is suppressed as some browsers like to use it but are not capable to cope with DH-Params > 1024 bits.)<br />
* Define a Cipher String that works with different Versions of your encryption tool, like openssl<br />
* Verify your cipher string<br />
** with an audit-tool, like [[O-Saft|OWASP 'O-Saft' (OWASP SSL audit for testers / OWASP SSL advanced forensic tool)]]<br />
** listing it manually with your encryption software, e.g. openssl ciphers -v <cipher-string> (the result may differ by version), e.g.:<br />
{{Top_10_2010:ExampleBeginTemplate|year=2013}} <br />
openssl ciphers -v "EDH+aRSA+AESGCM:EDH+aRSA+AES:DHE-RSA-AES256-SHA:EECDH+aRSA+AESGCM:EECDH+aRSA+AES:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:RSA+AESGCM:RSA+AES+SHA:DES-CBC3-SHA:-DHE-RSA-AES128-SHA" <br><br />
<nowiki>#</nowiki>add optionally ':!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:!ADH:!IDEA' to protect older Versions of OpenSSL<br><br />
<nowiki>#</nowiki>you may use openssl ciphers -V "..." for openssl >= 1.0.1:<br />
<small><br />
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD<br />
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD<br />
0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256<br />
0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1<br />
0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256<br />
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD<br />
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD<br />
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384<br />
0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1<br />
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256<br />
0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1<br />
0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD<br />
0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD<br />
0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1<br />
0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1<br />
0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1<br />
</small><br />
{{Top_10_2010:ExampleEndTemplate}}<br />
<br />
* 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)]<br />
* Check new software and hardware versions for new security settings.<br />
<br />
<b>Notes:</b><br />
* 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]).<br />
* 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].<br />
* 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.<br />
<br />
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.html 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].<br />
<br />
=== Rule - Support TLS-PSK and TLS-SRP for Mutual Authentication ===<br />
<br />
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 cipehr suites] and [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 9 SRP cipher suites].<br />
<br />
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.<br />
<br />
Finally, using a PAKE removes the need to trust an outside party, such as a Certification Authority (CA).<br />
<br />
=== Rule - Only Support Secure Renegotiations ===<br />
<br />
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.<br />
<br />
=== Rule - Disable Compression ===<br />
<br />
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.<br />
<br />
== Test your overall TLS/SSL setup and your Certificate ==<br />
This section shows the most common references only. For more tools and such, please refer to [[#Tools|Tools]].<br />
<br />
* [[Testing_for_SSL-TLS_%28OWASP-CM-001%29 | OWASP Testing Guide: Chapter on SSL/TLS Testing]]<br />
* [[O-Saft|OWASP 'O-Saft' (OWASP SSL audit for testers / OWASP SSL advanced forensic tool)]]<br />
* [https://www.ssllabs.com/ssltest SSL LABS Server Test]<br />
* 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<br />
<br />
== Client (Browser) Configuration ==<br />
<br />
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:<br />
<br />
* The application server establishes connections to other applications over TLS for purposes such as web services or any exchange of data<br />
* A thick client application is connecting to a server via TLS<br />
<br />
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.<br />
* [http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html NIST PKI Testing]<br />
* [https://tools.ietf.org/html/rfc5280 IETF RFC 5280]<br />
<br />
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.<br />
<br />
== Additional Controls ==<br />
<br />
=== Extended Validation Certificates ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
=== Client-Side Certificates ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
=== Certificate and Public Key Pinning ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
For more information, please see the [[Pinning Cheat Sheet]].<br />
<br />
= Providing Transport Layer Protection for Back End and Other Connections =<br />
<br />
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. <br />
<br />
== Secure Internal Network Fallacy ==<br />
<br />
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.<br />
<br />
<br />
= Tools =<br />
=== local/offline ===<br />
* [[O-Saft|O-Saft - OWASP SSL advanced forensic tool)]]<br />
* [http://sourceforge.net/projects/sslscan/ SSLScan - Fast SSL Scanner]<br />
* [https://github.com/iSECPartners/sslyze SSLyze]<br />
* [http://www.g-sec.lu/sslaudit/sslaudit.zip SSL Audit]<br />
<br />
=== Online ===<br />
* [https://www.ssllabs.com/ssltest SSL LABS Server Test]<br />
<br />
<br />
= Related Articles =<br />
<br />
* Mozilla – [https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations Mozilla Recommended Configurations]<br />
* OWASP – [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]] <br />
* OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]<br />
* OWASP – ASVS Article on [[Why you need to use a FIPS 140-2 validated cryptomodule]]<br />
* SSL Labs – [https://www.ssllabs.com/projects/best-practices/index.html SSL/TLS Deployment Best Practices]<br />
* SSL Labs – [http://www.ssllabs.com/projects/rating-guide/index.html SSL Server Rating Guide]<br />
* ENISA – [http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report Algorithms, Key Sizes and Parameters Report]<br />
* BSI – [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html BSI TR-02102 Part 2 (German)]<br />
* 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]<br />
* 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]<br />
* NIST – [http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf FIPS 140-2 Security Requirements for Cryptographic Modules]<br />
* 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]<br />
* 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]<br />
* NIST – [http://csrc.nist.gov/publications/drafts.html#sp800-95 SP 800-95 Guide to Secure Web Services] <br />
* IETF – [https://tools.ietf.org/html/rfc5280 RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile]<br />
* IETF – [https://tools.ietf.org/html/rfc2246 RFC 2246 The Transport Layer Security (TLS) Protocol Version 1.0 (JAN 1999)]<br />
* IETF – [https://tools.ietf.org/html/rfc4346 RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 (APR 2006)]<br />
* IETF – [https://tools.ietf.org/html/rfc5246 RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 (AUG 2008)]<br />
* IETF – [https://tools.ietf.org/html/rfc7525 RFC 7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)]<br />
* bettercrypto - [https://bettercrypto.org Applied Crypto Hardening: HOWTO for secure crypto settings of the most common services (DRAFT)]<br />
<br />
<br />
= Authors and Primary Editors =<br />
<br />
Michael Coates - michael.coates[at]owasp.org <br/><br />
Dave Wichers - dave.wichers[at]owasp.org <br/><br />
Michael Boberski - boberski_michael[at]bah.com<br/><br />
Tyler Reguly -treguly[at]sslfail.com<br />
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]<br />
[[Category:OWASP Best Practices]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=HTTP_Strict_Transport_Security&diff=195987HTTP Strict Transport Security2015-06-09T20:53:11Z<p>Pawel Krawczyk: /* Links */ typo</p>
<hr />
<div><br><br />
== Description ==<br />
<br />
HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.<br />
<br />
<br><br />
<br />
The specification has been released and published end of 2012 as RFC 6797 (HTTP Strict Transport Security (HSTS)) by the IETF. (Reference see in the links at the bottom.)<br />
<br />
== Examples ==<br />
<br />
Simple example, using a long (1 year) max-age:<br />
<br />
Strict-Transport-Security: max-age=31536000<br />
<br />
If all present and future subdomains will be HTTPS:<br />
<br />
Strict-Transport-Security: max-age=31536000; includeSubDomains<br />
<br />
'''Recommended:''' If the site owner would like their domain to be included in the [https://hstspreload.appspot.com/ HSTS preload list] maintained by Chrome (and used by Firefox and Safari), then use:<br />
<br />
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload<br />
<br />
The `preload` flag indicates the site owner's consent to have their domain preloaded. The site owner still needs to then go and submit the domain to the list.<br />
<br />
== Excessively Strict STS ==<br />
<br />
Use caution when setting excessively strict STS policies. Including subdomains should only be used in environments where all sites within your organization for the given domain name require ssl. Max-age limits should be carefully considered as infrequent visitors may find your site inaccessible if you relax your policy.<br />
<br />
Before enabling includeSubDomains, also consider the impact of any existing DNS CNAME records for CDNs, email services, or other 3rd party services. Since includeSubDomains will force such CNAME subdomains to https:// it's likely the browser will throw a domain-mismatch error, which is hard to reverse because of the browser caching nature of HSTS.<br />
<br />
== Browser Support ==<br />
<br />
{| width="400" cellspacing="1" cellpadding="1" border="1"<br />
|-<br />
| '''Browser'''<br><br />
| '''Support Introduced'''<br><br />
|-<br />
| Internet Explorer <br><br />
| support expected starting with ie12[https://threatpost.com/ie-12-to-support-hsts-encryption-protocol/105266]<br><br />
|-<br />
| Firefox<br><br />
| 4<br><br />
|-<br />
| Opera<br><br />
| 12<br><br />
|-<br />
| Safari<br><br />
| Mavericks (Mac OS X 10.9)<br><br />
|-<br />
| Chrome<br><br />
| 4.0.211.0<br><br />
|}<br />
<br />
<br><br />
A detailed overview of supporting browsers can be found at [http://caniuse.com/#feat=stricttransportsecurity caniuse.com].<br />
== Server Side ==<br />
<br />
The web server side needs to inject the HSTS header. <br />
<br />
For HTTP sites on the same domain it is [http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec#section-6.1 not recommended] to add a HSTS header but to do a permanent redirect (301 status code) to the HTTPS site.<br />
<br />
An Apache HTTPd example that will permanently redirect a URL to the identical URL with a HTTPS scheme, is as follows:<br />
<br />
<VirtualHost *:80><br />
ServerAlias *<br />
RewriteEngine On<br />
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]<br />
</VirtualHost><br />
<br />
On the HTTPS site configuration the following is needed to add the header as [http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec#section-6.1 recommended by the standard]:<br />
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"<br />
<br />
The following links show how to set response headers in other web servers:<br />
* [http://wiki.nginx.org/HttpHeadersModule NGINX]<br />
* [http://redmine.lighttpd.net/wiki/lighttpd/Docs:ModSetEnv#Options Lighttpd]<br />
* [http://httpd.apache.org/docs/2.2/mod/mod_headers.html HTTPd]<br />
<br />
==== IIS ====<br />
Whilst [http://technet.microsoft.com/en-us/library/cc753133(WS.10).aspx custom headers] can be configured in IIS without any extensions, it is not possible to restrict these headers to secure transport channels [http://tools.ietf.org/html/rfc6797#section-7.2 as per the HSTS specification]. This leaves the following options. <br />
<br />
===== Custom Module =====<br />
HSTS has been implemented, per the specification, as an [http://hstsiis.codeplex.com/ open source IIS module].<br />
<br />
===== URL Rewrite =====<br />
Install [http://www.iis.net/downloads/microsoft/url-rewrite Microsoft URL Rewrite] and use following rewrite rules.<br />
<br />
<configuration><br />
<system.webServer><br />
<rewrite><br />
<rules><br />
<rule name="HTTPS_301_Redirect" stopProcessing="true"><br />
<match url="(.*)" /><br />
<conditions><br />
<add input="{HTTPS}" pattern="^OFF$" /><br />
</conditions><br />
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" appendQueryString="false" redirectType="Permanent" /><br />
</rule><br />
</rules><br />
<outboundRules><br />
<rule name="Add_HSTS_Header" preCondition="USING_HTTPS" patternSyntax="Wildcard"><br />
<match serverVariable="RESPONSE_Strict-Transport-Security" pattern="*" /><br />
<action type="Rewrite" value="max-age=31536000" /><br />
</rule><br />
<preConditions><br />
<preCondition name="USING_HTTPS"><br />
<add input="{HTTPS}" pattern="^ON$" /><br />
</preCondition><br />
</preConditions><br />
</outboundRules><br />
</rewrite><br />
</system.webServer><br />
</configuration><br />
<br />
== Threats ==<br />
<br />
HSTS addresses the following threats:<br />
* User bookmarks or manually types http://example.com and is subject to a man-in-the-middle attacker<br />
** HSTS automatically redirects HTTP requests to HTTPS for the target domain<br />
* Web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP<br />
** HSTS automatically redirects HTTP requests to HTTPS for the target domain<br />
* A man-in-the-middle attacker attempts to intercept traffic from a victim user using an invalid certificate and hopes the user will accept the bad certificate<br />
** HSTS does not allow a user to override the invalid certificate message<br />
<br />
<br />
== Links ==<br />
* [http://www.youtube.com/watch?v=zEV3HOuM_Vw&feature=youtube_gdata AppSecTutorial Series - Episode 4]<br />
* [http://dev.chromium.org/sts Chromium Projects/HSTS]<br />
* [http://tools.ietf.org/html/rfc6797 HSTS Spec]<br />
* [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security Wikipedia]<br />
* [https://developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security Mozilla Developer Network]<br />
* [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet OWASP TLS Protection Cheat Sheet]<br />
* [https://developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security Firefox STS Support]<br />
* [http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1148.html Google Chrome STS Support]<br />
* [http://www.thoughtcrime.org/software/sslstrip/ Moxie Marlinspike's Black Hat 2009 talk on sslstrip, that demonstrates why you need HSTS]<br />
<br />
[[Category:Control|Control]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Transport_Layer_Protection_Cheat_Sheet&diff=195986Transport Layer Protection Cheat Sheet2015-06-09T20:52:55Z<p>Pawel Krawczyk: /* Rule - Use HTTP Strict Transport Security */ link to appropriate articles on STS and PKP instead of duplicating content, add PKP</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
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> <br />
<br />
== Architectural Decision ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
= Providing Transport Layer Protection with SSL/TLS =<br />
<br />
== Benefits ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Basic Requirements ==<br />
<br />
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.<br />
<br />
== SSL vs. TLS ==<br />
<br />
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"]].<br />
<br />
[[Image:Asvs_cryptomodule.gif|thumb|350px|right|Cryptomodule Parts and Operation]]<br />
<br />
== When to Use a FIPS 140-2 Validated Cryptomodule ==<br />
<br />
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]. <br />
<br />
A cryptomodule, whether it is a software library or a hardware device, basically consists of three parts:<br />
<br />
* Components that implement cryptographic algorithms (symmetric and asymmetric algorithms, hash algorithms, random number generator algorithms, and message authentication code algorithms) <br />
* Components that call and manage cryptographic functions (inputs and outputs include cryptographic keys and so-called critical security parameters) <br />
* A physical container around the components that implement cryptographic algorithms and the components that call and manage cryptographic functions<br />
<br />
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:<br />
<br />
* Calling and managing cryptographic functions<br />
* Securely Handling inputs and output<br />
* Ensuring the secure construction of the physical container around the components<br />
<br />
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.<br />
<br />
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].<br />
<br />
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]<br />
<br />
== Secure Server Design ==<br />
<br />
=== Rule - Use TLS for All Login Pages and All Authenticated Pages ===<br />
<br />
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. <br />
<br />
=== Rule - Use TLS on Any Networks (External and Internal) Transmitting Sensitive Data ===<br />
<br />
All networks, both external and internal, which transmit sensitive data must utilize TLS or an equivalent transport layer security mechanism. 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. <br />
<br />
=== Rule - Do Not Provide Non-TLS Pages for Secure Content ===<br />
<br />
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.<br />
<br />
=== Rule - REMOVED - Do Not Perform Redirects from Non-TLS Page to TLS Login Page ===<br />
<br />
This recommendation has been removed. Ultimately, the below guidance will only provide user education and cannot provide any technical controls to protect the user against a man-in-the-middle attack. <br />
<br />
--<br />
<br />
A common practice is to redirect users that have requested a non-TLS version of the login page to the TLS version (e.g. http://example.com/login redirects to https://example.com/login). This practice creates an additional attack vector for a man in the middle attack. In addition, redirecting from non-TLS versions to the TLS version reinforces to the user that the practice of requesting the non-TLS page is acceptable and secure.<br />
<br />
In this scenario, the man-in-the-middle attack is used by the attacker to intercept the non-TLS to TLS redirect message. The attacker then injects the HTML of the actual login page and changes the form to post over unencrypted HTTP. This allows the attacker to view the user's credentials as they are transmitted in the clear.<br />
<br />
It is recommended to display a security warning message to the user whenever the non-TLS login page is requested. This security warning should urge the user to always type "HTTPS" into the browser or bookmark the secure login page. This approach will help educate users on the correct and most secure method of accessing the application.<br />
<br />
Currently there are no controls that an application can enforce to entirely mitigate this risk. Ultimately, this issue is the responsibility of the user since the application cannot prevent the user from initially typing [http://owasp.org http://example.com/login] (versus HTTPS). <br />
<br />
Note: [http://www.w3.org/Security/wiki/Strict_Transport_Security Strict Transport Security] will address this issue and will provide a server side control to instruct supporting browsers that the site should only be accessed over HTTPS<br />
<br />
=== Rule - Do Not Mix TLS and Non-TLS Content ===<br />
<br />
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. <br />
<br />
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'<br />
<br />
=== Rule - Use "Secure" Cookie Flag ===<br />
<br />
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.<br />
<br />
=== Rule - Keep Sensitive Data Out of the URL ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
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]<br />
<br />
=== Rule - Prevent Caching of Sensitive Data ===<br />
<br />
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.<br />
<br />
=== Rule - Use HTTP Strict Transport Security ===<br />
<br />
See: [[HTTP Strict Transport Security]]<br />
<br />
===Rule - Use Public Key Pinning===<br />
<br />
See: [[Certificate and Public Key Pinning]]<br />
<br />
<span id="Server_Certificate_and_Protocol_Configuration"></span> <!-- backward compatible anchor --><br />
<br />
== Server Certificate ==<br />
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.<br />
<br />
=== Rule - Use Strong Keys & Protect Them ===<br />
<br />
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.<br />
<br />
=== Rule - Use a Certificate That Supports Required Domain Names ===<br />
<br />
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.<br />
<br />
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).<br />
<br />
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".<br />
<br />
=== Rule - Use Fully Qualified Names in Certificates ===<br />
<br />
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.<br />
<br />
=== Rule - Do Not Use Wildcard Certificates ===<br />
<br />
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.<br />
<br />
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://www.cabforum.org/EV_Certificate_Guidelines.pdf EV Certificate Guidelines].<br />
<br />
=== Rule - Do Not Use RFC 1918 Addresses in Certificates ===<br />
<br />
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.<br />
<br />
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."<br />
<br />
=== Rule - Use an Appropriate Certification Authority for the Application's User Base ===<br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
=== Rule - Always Provide All Needed Certificates ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
To avoid the “Which Directory?" problem, a server should provide the user with all required certificates used in a path validation.<br />
<br />
=== Rule - Be aware of and have a plan for the SHA-1 deprecation plan ===<br />
<br />
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]<br />
<br />
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. <br />
<br />
== Server Protocol and Cipher Configuration ==<br />
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.<br />
<br />
=== Rule - Only Support Strong Protocols ===<br />
<br />
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 - TLS1.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.<br />
<br />
[http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers Nearly all modern browsers support at least TLS 1.0]. As of February 2013, contemporary browsers (Chrome v20+, 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 which support the protocols. The client and server (usually) negotiate the best protocol, that is supported on both sides.<br />
<br />
TLS 1.0 is still widely used as 'best' protocol by a lot of browsers, that are not patched to the very latest version. It suffers [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 only after risk analysis and acceptance.<br />
<br />
Under no circumstances neither SSLv2 nor SSLv3 should be enabled as a protocol selection:<br />
* The [http://www.schneier.com/paper-ssl-revised.pdf SSLv2 protocol is broken] and does not provide adequate transport layer protection.<br />
* [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.<br />
<br />
=== Rule - Prefer Ephemeral Key Exchanges ===<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Rule - Only Support Strong Cryptographic Ciphers ===<br />
<br />
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 CipherSuites:<br />
* Use the very latest recommendations, they may be volantile these days<br />
* Setup your Policy to get a Whitelist for recommended Ciphers, e.g.:<br />
** Activate to set the Cipher Order by the Server<br />
** 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]<br />
** 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/draft-irtf-cfrg-curves-02 DRAFT-irtf-cfrg-curves]), that is not yet defined for TLS, cf. [http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 IANA] <!--- as at June 2014 ---><br />
** 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]) <!--- as at June 2014 ---><br />
** 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.<br />
** Watch also for Stream Ciphers which XOR the key stream with plaintext (such as AES/CTR mode) <!--- Jim please check this ---><br />
** Priorize the ciphers by the sizes of the Cipher and the MAC<br />
** Use SHA1 or above for digests, prefer SHA2 (or equivalent)<br />
** 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_3DES_EDE_CBC_SHA (0xa) does this job.<br />
*** Disable cipher suites that do not offer encryption (eNULL, NULL)<br />
*** 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).<br />
*** Disable export level ciphers (EXP, eg. ciphers containing DES)<br />
*** 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.html BSI: TR-02102 Part 2 (German)])<br />
*** Disable the use of MD5 as a hashing mechanism for payload traffic<br />
*** Disable the use of IDEA Cipher Suites (see [https://tools.ietf.org/html/rfc5469])<br />
*** Disable RC4 cipher suites (see [https://tools.ietf.org/html/rfc7465], [http://www.isg.rhul.ac.uk/tls/])<br />
** Ciphers should be usable for DH-Pamameters >= 2048 bits, without blocking legacy browsers (The cipher ‘DHE-RSA-AES128-SHA’ is suppressed as some browsers like to use it but are not capable to cope with DH-Params > 1024 bits.)<br />
* Define a Cipher String that works with different Versions of your encryption tool, like openssl<br />
* Verify your cipher string<br />
** with an audit-tool, like [[O-Saft|OWASP 'O-Saft' (OWASP SSL audit for testers / OWASP SSL advanced forensic tool)]]<br />
** listing it manually with your encryption software, e.g. openssl ciphers -v <cipher-string> (the result may differ by version), e.g.:<br />
{{Top_10_2010:ExampleBeginTemplate|year=2013}} <br />
openssl ciphers -v "EDH+aRSA+AESGCM:EDH+aRSA+AES:DHE-RSA-AES256-SHA:EECDH+aRSA+AESGCM:EECDH+aRSA+AES:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:RSA+AESGCM:RSA+AES+SHA:DES-CBC3-SHA:-DHE-RSA-AES128-SHA" <br><br />
<nowiki>#</nowiki>add optionally ':!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:!ADH:!IDEA' to protect older Versions of OpenSSL<br><br />
<nowiki>#</nowiki>you may use openssl ciphers -V "..." for openssl >= 1.0.1:<br />
<small><br />
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD<br />
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD<br />
0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256<br />
0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1<br />
0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256<br />
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD<br />
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD<br />
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384<br />
0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1<br />
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256<br />
0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1<br />
0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD<br />
0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD<br />
0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1<br />
0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1<br />
0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1<br />
</small><br />
{{Top_10_2010:ExampleEndTemplate}}<br />
<br />
* 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)]<br />
* Check new software and hardware versions for new security settings.<br />
<br />
<b>Notes:</b><br />
* 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]).<br />
* 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].<br />
* 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.<br />
<br />
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.html 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].<br />
<br />
=== Rule - Support TLS-PSK and TLS-SRP for Mutual Authentication ===<br />
<br />
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 cipehr suites] and [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 9 SRP cipher suites].<br />
<br />
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.<br />
<br />
Finally, using a PAKE removes the need to trust an outside party, such as a Certification Authority (CA).<br />
<br />
=== Rule - Only Support Secure Renegotiations ===<br />
<br />
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.<br />
<br />
=== Rule - Disable Compression ===<br />
<br />
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.<br />
<br />
== Test your overall TLS/SSL setup and your Certificate ==<br />
This section shows the most common references only. For more tools and such, please refer to [[#Tools|Tools]].<br />
<br />
* [[Testing_for_SSL-TLS_%28OWASP-CM-001%29 | OWASP Testing Guide: Chapter on SSL/TLS Testing]]<br />
* [[O-Saft|OWASP 'O-Saft' (OWASP SSL audit for testers / OWASP SSL advanced forensic tool)]]<br />
* [https://www.ssllabs.com/ssltest SSL LABS Server Test]<br />
* 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<br />
<br />
== Client (Browser) Configuration ==<br />
<br />
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:<br />
<br />
* The application server establishes connections to other applications over TLS for purposes such as web services or any exchange of data<br />
* A thick client application is connecting to a server via TLS<br />
<br />
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.<br />
* [http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html NIST PKI Testing]<br />
* [https://tools.ietf.org/html/rfc5280 IETF RFC 5280]<br />
<br />
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.<br />
<br />
== Additional Controls ==<br />
<br />
=== Extended Validation Certificates ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
=== Client-Side Certificates ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
=== Certificate and Public Key Pinning ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
For more information, please see the [[Pinning Cheat Sheet]].<br />
<br />
= Providing Transport Layer Protection for Back End and Other Connections =<br />
<br />
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. <br />
<br />
== Secure Internal Network Fallacy ==<br />
<br />
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.<br />
<br />
<br />
= Tools =<br />
=== local/offline ===<br />
* [[O-Saft|O-Saft - OWASP SSL advanced forensic tool)]]<br />
* [http://sourceforge.net/projects/sslscan/ SSLScan - Fast SSL Scanner]<br />
* [https://github.com/iSECPartners/sslyze SSLyze]<br />
* [http://www.g-sec.lu/sslaudit/sslaudit.zip SSL Audit]<br />
<br />
=== Online ===<br />
* [https://www.ssllabs.com/ssltest SSL LABS Server Test]<br />
<br />
<br />
= Related Articles =<br />
<br />
* Mozilla – [https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations Mozilla Recommended Configurations]<br />
* OWASP – [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]] <br />
* OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]<br />
* OWASP – ASVS Article on [[Why you need to use a FIPS 140-2 validated cryptomodule]]<br />
* SSL Labs – [https://www.ssllabs.com/projects/best-practices/index.html SSL/TLS Deployment Best Practices]<br />
* SSL Labs – [http://www.ssllabs.com/projects/rating-guide/index.html SSL Server Rating Guide]<br />
* ENISA – [http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report Algorithms, Key Sizes and Parameters Report]<br />
* BSI – [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html BSI TR-02102 Part 2 (German)]<br />
* 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]<br />
* 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]<br />
* NIST – [http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf FIPS 140-2 Security Requirements for Cryptographic Modules]<br />
* 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]<br />
* 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]<br />
* NIST – [http://csrc.nist.gov/publications/drafts.html#sp800-95 SP 800-95 Guide to Secure Web Services] <br />
* IETF – [https://tools.ietf.org/html/rfc5280 RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile]<br />
* IETF – [https://tools.ietf.org/html/rfc2246 RFC 2246 The Transport Layer Security (TLS) Protocol Version 1.0 (JAN 1999)]<br />
* IETF – [https://tools.ietf.org/html/rfc4346 RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 (APR 2006)]<br />
* IETF – [https://tools.ietf.org/html/rfc5246 RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 (AUG 2008)]<br />
* IETF – [https://tools.ietf.org/html/rfc7525 RFC 7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)]<br />
* bettercrypto - [https://bettercrypto.org Applied Crypto Hardening: HOWTO for secure crypto settings of the most common services (DRAFT)]<br />
<br />
<br />
= Authors and Primary Editors =<br />
<br />
Michael Coates - michael.coates[at]owasp.org <br/><br />
Dave Wichers - dave.wichers[at]owasp.org <br/><br />
Michael Boberski - boberski_michael[at]bah.com<br/><br />
Tyler Reguly -treguly[at]sslfail.com<br />
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]<br />
[[Category:OWASP Best Practices]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=HTTP_Strict_Transport_Security&diff=195985HTTP Strict Transport Security2015-06-09T20:52:25Z<p>Pawel Krawczyk: /* Links */ add AppSec tutorials</p>
<hr />
<div><br><br />
== Description ==<br />
<br />
HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.<br />
<br />
<br><br />
<br />
The specification has been released and published end of 2012 as RFC 6797 (HTTP Strict Transport Security (HSTS)) by the IETF. (Reference see in the links at the bottom.)<br />
<br />
== Examples ==<br />
<br />
Simple example, using a long (1 year) max-age:<br />
<br />
Strict-Transport-Security: max-age=31536000<br />
<br />
If all present and future subdomains will be HTTPS:<br />
<br />
Strict-Transport-Security: max-age=31536000; includeSubDomains<br />
<br />
'''Recommended:''' If the site owner would like their domain to be included in the [https://hstspreload.appspot.com/ HSTS preload list] maintained by Chrome (and used by Firefox and Safari), then use:<br />
<br />
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload<br />
<br />
The `preload` flag indicates the site owner's consent to have their domain preloaded. The site owner still needs to then go and submit the domain to the list.<br />
<br />
== Excessively Strict STS ==<br />
<br />
Use caution when setting excessively strict STS policies. Including subdomains should only be used in environments where all sites within your organization for the given domain name require ssl. Max-age limits should be carefully considered as infrequent visitors may find your site inaccessible if you relax your policy.<br />
<br />
Before enabling includeSubDomains, also consider the impact of any existing DNS CNAME records for CDNs, email services, or other 3rd party services. Since includeSubDomains will force such CNAME subdomains to https:// it's likely the browser will throw a domain-mismatch error, which is hard to reverse because of the browser caching nature of HSTS.<br />
<br />
== Browser Support ==<br />
<br />
{| width="400" cellspacing="1" cellpadding="1" border="1"<br />
|-<br />
| '''Browser'''<br><br />
| '''Support Introduced'''<br><br />
|-<br />
| Internet Explorer <br><br />
| support expected starting with ie12[https://threatpost.com/ie-12-to-support-hsts-encryption-protocol/105266]<br><br />
|-<br />
| Firefox<br><br />
| 4<br><br />
|-<br />
| Opera<br><br />
| 12<br><br />
|-<br />
| Safari<br><br />
| Mavericks (Mac OS X 10.9)<br><br />
|-<br />
| Chrome<br><br />
| 4.0.211.0<br><br />
|}<br />
<br />
<br><br />
A detailed overview of supporting browsers can be found at [http://caniuse.com/#feat=stricttransportsecurity caniuse.com].<br />
== Server Side ==<br />
<br />
The web server side needs to inject the HSTS header. <br />
<br />
For HTTP sites on the same domain it is [http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec#section-6.1 not recommended] to add a HSTS header but to do a permanent redirect (301 status code) to the HTTPS site.<br />
<br />
An Apache HTTPd example that will permanently redirect a URL to the identical URL with a HTTPS scheme, is as follows:<br />
<br />
<VirtualHost *:80><br />
ServerAlias *<br />
RewriteEngine On<br />
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]<br />
</VirtualHost><br />
<br />
On the HTTPS site configuration the following is needed to add the header as [http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec#section-6.1 recommended by the standard]:<br />
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"<br />
<br />
The following links show how to set response headers in other web servers:<br />
* [http://wiki.nginx.org/HttpHeadersModule NGINX]<br />
* [http://redmine.lighttpd.net/wiki/lighttpd/Docs:ModSetEnv#Options Lighttpd]<br />
* [http://httpd.apache.org/docs/2.2/mod/mod_headers.html HTTPd]<br />
<br />
==== IIS ====<br />
Whilst [http://technet.microsoft.com/en-us/library/cc753133(WS.10).aspx custom headers] can be configured in IIS without any extensions, it is not possible to restrict these headers to secure transport channels [http://tools.ietf.org/html/rfc6797#section-7.2 as per the HSTS specification]. This leaves the following options. <br />
<br />
===== Custom Module =====<br />
HSTS has been implemented, per the specification, as an [http://hstsiis.codeplex.com/ open source IIS module].<br />
<br />
===== URL Rewrite =====<br />
Install [http://www.iis.net/downloads/microsoft/url-rewrite Microsoft URL Rewrite] and use following rewrite rules.<br />
<br />
<configuration><br />
<system.webServer><br />
<rewrite><br />
<rules><br />
<rule name="HTTPS_301_Redirect" stopProcessing="true"><br />
<match url="(.*)" /><br />
<conditions><br />
<add input="{HTTPS}" pattern="^OFF$" /><br />
</conditions><br />
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" appendQueryString="false" redirectType="Permanent" /><br />
</rule><br />
</rules><br />
<outboundRules><br />
<rule name="Add_HSTS_Header" preCondition="USING_HTTPS" patternSyntax="Wildcard"><br />
<match serverVariable="RESPONSE_Strict-Transport-Security" pattern="*" /><br />
<action type="Rewrite" value="max-age=31536000" /><br />
</rule><br />
<preConditions><br />
<preCondition name="USING_HTTPS"><br />
<add input="{HTTPS}" pattern="^ON$" /><br />
</preCondition><br />
</preConditions><br />
</outboundRules><br />
</rewrite><br />
</system.webServer><br />
</configuration><br />
<br />
== Threats ==<br />
<br />
HSTS addresses the following threats:<br />
* User bookmarks or manually types http://example.com and is subject to a man-in-the-middle attacker<br />
** HSTS automatically redirects HTTP requests to HTTPS for the target domain<br />
* Web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP<br />
** HSTS automatically redirects HTTP requests to HTTPS for the target domain<br />
* A man-in-the-middle attacker attempts to intercept traffic from a victim user using an invalid certificate and hopes the user will accept the bad certificate<br />
** HSTS does not allow a user to override the invalid certificate message<br />
<br />
<br />
== Links ==<br />
* [[http://www.youtube.com/watch?v=zEV3HOuM_Vw&feature=youtube_gdata AppSecTutorial Series - Episode 4]<br />
* [http://dev.chromium.org/sts Chromium Projects/HSTS]<br />
* [http://tools.ietf.org/html/rfc6797 HSTS Spec]<br />
* [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security Wikipedia]<br />
* [https://developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security Mozilla Developer Network]<br />
* [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet OWASP TLS Protection Cheat Sheet]<br />
* [https://developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security Firefox STS Support]<br />
* [http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1148.html Google Chrome STS Support]<br />
* [http://www.thoughtcrime.org/software/sslstrip/ Moxie Marlinspike's Black Hat 2009 talk on sslstrip, that demonstrates why you need HSTS]<br />
<br />
[[Category:Control|Control]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Authentication_Cheat_Sheet&diff=195984Authentication Cheat Sheet2015-06-09T20:49:00Z<p>Pawel Krawczyk: /* SAML */ reference SAML Security Cheat Sheet</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
'''Authentication''' is the process of verification that an individual, entity or website is who it claims to be. Authentication in the context of web applications is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.<br />
<br />
'''Session Management''' is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.<br />
<br />
= Authentication General Guidelines =<br />
<br />
== User IDs ==<br />
<br />
Make sure your usernames/userids are case insensitive. User 'smith' and user 'Smith' should be the same user. <br />
<br />
=== Email address as a User ID ===<br />
<br />
Many sites use email addresses as a user id, which is a good mechanism for ensuring a unique identifier for each user without adding the burden of remembering a new username. However, many web applications do not treat email addresses correctly due to common misconceptions about what constitutes a valid address.<br />
<br />
Specifically, it is completely valid to have an mailbox address which:<br />
* Is case sensitive in the local-part<br />
* Has non-alphanumeric characters in the local-part (including + and '''@''')<br />
* Has zero or more labels (though zero is admittedly not going to occur)<br />
<br />
The local-part is the part of the mailbox address to the left of the rightmost @ character.<br />
The domain is the part of the mailbox address to the right of the rightmost @ character and consists of zero or more labels joined by a period character.<br />
<br />
At the time of writing, RFC 5321 is the current standard defining SMTP and what constitutes a valid mailbox address.<br />
<br />
Please note, email addresses should be consider to be public data. For high security applications usernames could be assigned and secret instead of user-defined public data.<br />
<br />
==== Validation ====<br />
Many web applications contain computationally expensive and inaccurate regular expressions that attempt to validate email addresses.<br />
<br />
Recent changes to the landscape mean that the number of false-negatives will increase, particularly due to:<br />
* Increased popularity of sub-addressing by providers such as Gmail (commonly using <tt>+</tt> as a token in the local-part to affect delivery)<br />
* New gTLDs with long names (many regular expressions check the number and length of each label in the domain)<br />
<br />
Following RFC 5321, best practice for validating an email address would be to:<br />
* Check for presence of at least one <tt>@</tt> symbol in the address<br />
* Ensure the local-part is no longer than 64 octets<br />
* Ensure the domain is no longer than 255 octets<br />
* Ensure the address is deliverable<br />
<br />
To ensure an address is deliverable, the only way to check this is to send the user an email and have the user take action to confirm receipt.<br />
Beyond confirming that the email address is valid and deliverable, this also provides a positive acknowledgement that the user has access to the mailbox and is likely to be authorised to use it. This does not mean that other users cannot access this mailbox, for example when the user makes use of a service that generates a throw away email address.<br />
<br />
==== Address Normalisation ====<br />
As the local-part of email addresses are, in fact - case sensitive, it is important to store and compare email addresses correctly.<br />
To normalise an email address input, you would convert the domain part ONLY to lowercase.<br />
<br />
Unfortunately this does and will make input harder to normalise and correctly match to a users intent.<br />
<br />
It is reasonable to only accept one unique capitalisation of an otherwise identical address, however in this case it is critical to:<br />
* Store the user-part as provided and verified by user verification<br />
* Perform comparisons by <tt>lowercase(provided)==lowercase(persisted)</tt><br />
<br />
== Implement Proper Password Strength Controls ==<br />
<br />
A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password through either manual or automated means. The following characteristics define a strong password: <br />
<br />
=== Password Length ===<br />
<br />
Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess. <br />
<br />
* '''Minimum''' length of the passwords should be '''enforced''' by the application.<br />
** Passwords '''shorter than 10 characters''' are considered to be weak ([http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf]).<br />
<br />
While minimum length enforcement may cause problems with memorizing passwords among some users, applications should encourage them to set ''passphrases'' (sentences or combination of words) that can be much longer than typical passwords and yet much easier to remember.<br />
<br />
* '''Maximum''' password length should not be set '''too low''', as it will prevent users from creating passphrases. Typical maximum length is 128 characters.<br />
** Passphrases shorter than 20 characters are usually considered weak if they only consist of lower case Latin characters.<br />
<br />
* Every character counts!!<br />
**Make sure that every character the user types in is actually included in the password. We've seen systems that truncate the password at a length shorter than what the user provided (e.g., truncated at 15 characters when they entered 20).<br />
**This is usually handled by setting the length of ALL password input fields to be exactly the same length as the maximum length password. This is particularly important if your max password length is short, like 20-30 characters.<br />
<br />
=== Password Complexity ===<br />
<br />
Applications should enforce password complexity rules to discourage easy to guess passwords. Password mechanisms should allow virtually any character the user can type to be part of their password, including the space character. Passwords should, obviously, be case sensitive in order to increase their complexity. Occasionally, we find systems where passwords aren't case sensitive, frequently due to legacy system issues like old mainframes that didn't have case sensitive passwords.<br />
<br />
The password change mechanism should require a minimum level of complexity that makes sense for the application and its user population. For example:<br />
<br />
*Password must meet at least 3 out of the following 4 complexity rules<br />
**at least 1 uppercase character (A-Z) <br />
**at least 1 lowercase character (a-z) <br />
**at least 1 digit (0-9) <br />
**at least 1 [[Password special characters|special character (punctuation)]] &mdash; do not forget to treat space as special characters too<br />
*at least 10 characters <br />
*at most 128 characters<br />
*not more than 2 identical characters in a row (e.g., 111 not allowed)<br />
<br />
As application's require more complex password policies, they need to be very clear about what these policies are.<br />
*The required policy needs to be explicitly stated on the password change page<br />
** be sure to list every special character you allow, so it's obvious to the user<br />
<br />
Recommendation:<br />
* Ideally, the application would indicate to the user as they type in their new password how much of the complexity policy their new password meets<br />
**In fact, the submit button should be grayed out until the new password meets the complexity policy and the 2nd copy of the new password matches the 1st. This will make it far easier for the user to understand and comply with your complexity policy.<br />
<br />
Regardless of how the UI behaves, when a user submits their password change request:<br />
*If the new password doesn't comply with the complexity policy, the error message should describe EVERY complexity rule that the new password does not comply with, not just the 1st rule it doesn't comply with<br />
<br />
Changing passwords should be EASY, not a hunt in the dark.<br />
<br />
== Implement Secure Password Recovery Mechanism ==<br />
<br />
It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see [[Forgot Password Cheat Sheet]] for details on this feature.<br />
<br />
== Store Passwords in a Secure Fashion ==<br />
<br />
It is critical for a application to store a password using the right cryptographic technique. Please see [[Password Storage Cheat Sheet]] for details on this feature.<br />
<br />
== Transmit Passwords Only Over TLS or Other Strong Transport ==<br />
<br />
See: [[Transport Layer Protection Cheat Sheet]]<br />
<br />
The login page and all subsequent authenticated pages must be exclusively accessed over TLS or other strong transport. The initial login page, referred to as the "login landing page", must be served over TLS or other strong transport. Failure to utilize TLS or other strong transport 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 or other strong transport for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session.<br />
<br />
== Require Re-authentication for Sensitive Features ==<br />
<br />
In order to mitigate CSRF and session hijacking, it's important to require the current credentials for an account before updating sensitive account information such as the user's password, user's email, or before sensitive transactions, such as shipping a purchase to a new address. Without this countermeasure, an attacker may be able to execute sensitive transactions through a CSRF or XSS attack without needing to know the user's current credentials. Additionally, an attacker may get temporary physical access to a user's browser or steal their session ID to take over the user's session.<br />
<br />
== Utilize Multi-Factor Authentication ==<br />
<br />
Multi-factor authentication (MFA) is using more than one authentication factor to logon or process a transaction:<br />
<br />
*Something you know (account details or passwords) <br />
*Something you have (tokens or mobile phones) <br />
*Something you are (biometrics)<br />
<br />
Authentication schemes such as One Time Passwords (OTP) implemented using a hardware token can also be key in fighting attacks such as CSRF and client-side malware. A number of hardware tokens suitable for MFA are available in the market that allow good integration with web applications. See: [http://en.wikipedia.org/wiki/Security_token].<br />
<br />
=== TLS Client Authentication ===<br />
<br />
TLS Client Authentication, also known as two-way TLS authentication, consists of both, browser and server, sending their respective TLS certificates during the TLS handshake process. Just as you can validate the authenticity of a server by using the certificate and asking a well known Certificate Authority (CA) if the certificate is valid, the server can authenticate the user by receiving a certificate from the client and validating against a third party CA or its own CA. To do this, the server must provide the user with a certificate generated specifically for him, assigning values to the subject so that these can be used to determine what user the certificate should validate. The user installs the certificate on a browser and now uses it for the website.<br />
<br />
It is a good idea to do this when:<br />
<br />
*It is acceptable (or even preferred) that the user only has access to the website from only a single computer/browser.<br />
*The user is not easily scared by the process of installing TLS certificates on his browser or there will be someone, probably from IT support, that will do this for the user.<br />
*The website requires an extra step of security.<br />
*It is also a good thing to use when the website is for an intranet of a company or organization.<br />
<br />
It is generally not a good idea to use this method for widely and publicly available websites that will have an average user. For example, it wouldn't be a good idea to implement this for a website like Facebook. While this technique can prevent the user from having to type a password (thus protecting against an average keylogger from stealing it), it is still considered a good idea to consider using both a password and SSL client authentication combined.<br />
<br />
For more information, see: [https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake Client-authenticated TLS handshake]<br />
<br />
== Authentication and Error Messages ==<br />
<br />
Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration. An application should respond (both HTTP and HTML) in a generic manner.<br />
<br />
==== Authentication Responses ====<br />
<br />
An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should also give no indication to the status of an existing account.<br />
<br />
==== Incorrect Response Examples ====<br />
<br />
*"Login for User foo: invalid password" <br />
*"Login failed, invalid user ID" <br />
*"Login failed; account disabled" <br />
*"Login failed; this user is not active"<br />
<br />
==== Correct Response Example ====<br />
<br />
*"Login failed; Invalid userID or password"<br />
<br />
The correct response does not indicate if the user ID or password is the incorrect parameter and hence inferring a valid user ID. <br />
<br />
==== Error Codes and URLs ====<br />
<br />
The application may return a different HTTP Error code depending on the authentication attempt response. It may respond with a 200 for a positive result and a 403 for a negative result. Even though a generic error page is shown to a user, the HTTP response code may differ which can leak information about whether the account is valid or not.<br />
<br />
== Prevent Brute-Force Attacks ==<br />
<br />
If an attacker is able to guess passwords without the account becoming disabled due to failed authentication attempts, the attacker has an opportunity to continue with a brute force attack until the account is compromised. Automating brute-force/password guessing attacks on web applications is a trivial challenge. Password lockout mechanisms should be employed that lock out an account if more than a preset number of unsuccessful login attempts are made. Password lockout mechanisms have a logical weakness. An attacker that undertakes a large number of authentication attempts on known account names can produce a result that locks out entire blocks of user accounts. Given that the intent of a password lockout system is to protect from brute-force attacks, a sensible strategy is to lockout accounts for a period of time (e.g., 20 minutes). This significantly slows down attackers, while allowing the accounts to reopen automatically for legitimate users.<br />
<br />
Also, multi-factor authentication is a very powerful deterrent when trying to prevent brute force attacks since the credentials are a moving target. When multi-factor is implemented and active, account lockout may no longer be necessary.<br />
<br />
= Use of authentication protocols that require no password =<br />
<br />
While authentication through a user/password combination and using multi-factor authentication is considered generally secure, there are use cases where it isn't considered the best option or even safe. An example of this are third party applications that desire connecting to the web application, either from a mobile device, another website, desktop or other situations. When this happens, it is NOT considered safe to allow the third party application to store the user/password combo, since then it extends the attack surface into their hands, where it isn't in your control. For this, and other use cases, there are several authentication protocols that can protect you from exposing your users' data to attackers.<br />
<br />
== OAuth ==<br />
<br />
Open Authorization (OAuth) is a protocol that allows an application to authenticate against a server as a user, without requiring passwords or any third party server that acts as an identity provider. It uses a token generated by the server, and provides how the authorization flows most occur, so that a client, such as a mobile application, can tell the server what user is using the service. <br />
<br />
The recommendation is to use and implement OAuth 1.0a or OAuth 2.0, since the very first version (OAuth1.0) has been found to be vulnerable to session fixation.<br />
<br />
OAuth 2.0 relies on HTTPS for security and is currently used and implemented by API's from companies such as Facebook, Google, Twitter and Microsoft. OAuth1.0a is more difficult to use because it requires the use of cryptographic libraries for digital signatures, however does not rely on HTTPS for security and can therefore be more suited for higher risk transactions.<br />
<br />
== OpenId ==<br />
<br />
OpenId is an HTTP-based protocol that uses identity providers to validate that a user is who he says he is. It is a very simple protocol which allows a service provider initiated way for single sign-on (SSO). This allows the user to re-use a single identity given to a trusted OpenId identity provider and be the same user in multiple websites, without the need to provide any website the password, except for the OpenId identity provider.<br />
<br />
Due to its simplicity and that it provides protection of passwords, OpenId has been well adopted. Some of the well known identity providers for OpenId are Stack Exchange, Google, Facebook and Yahoo!<br />
<br />
For non-enterprise environment, OpenId is considered a secure and often better choice, as long as the identity provider is of trust.<br />
<br />
== SAML ==<br />
<br />
Security Assertion Markup Language (SAML) is often considered to compete with OpenId. The most recommended version is 2.0, since it is very feature complete and provides a strong security. Like with OpenId, SAML uses identity providers, but unlike it, it is XML-based and provides more flexibility. SAML is based on browser redirects which send XML data. Unlike SAML, it isn't only initiated by a service provider, but it can also be initiated from the identity provider. This allows the user to navigate through different portals while still being authenticated without having to do anything, making the process transparent.<br />
<br />
While OpenId has taken most of the consumer market, SAML is often the choice for enterprise applications. The reason for this is often that there are few OpenId identity providers which are considered of enterprise class (meaning that the way they validate the user identity doesn't have high standards required for enterprise identity). It is more common to see SAML being used inside of intranet websites, sometimes even using a server from the intranet as the identity provider.<br />
<br />
In the past few years, applications like SAP ERP and SharePoint (SharePoint by using Active Directory Federation Services 2.0) have decided to use SAML 2.0 authentication as an often preferred method for single sign-on implementations whenever enterprise federation is required for web services and web applications.<br />
<br />
'''See also: [[SAML Security Cheat Sheet]]'''<br />
<br />
== FIDO ==<br />
The Fast Identity Online (FIDO) Alliance has created two protocols to facilitate online authentication : the Universal Authentication Framework (UAF) protocol and the Universal Second Factor (U2F) protocol. While UAF focuses on passwordless authentication, U2F allows the addition of a second factor to existing password-based authentication. Both protocols are based on a public key cryptography challenge-response model. <br />
<br />
UAF takes advantage of existing security technologies present on devices for authentication including fingerprint sensors, cameras(face biometrics), microphones(voice biometrics), Trusted Execution Environments(TEEs), Secure Elements(SEs) and others. The protocol is designed to plug-in these device capabilities into a common authentication framework. UAF works with both native applications and web applications.<br />
<br />
U2F augments password-based authentication using a hardware token (typically USB) that stores cryptographic authentication keys and uses them for signing. The user can use the same token as a second factor for multiple applications. U2F works with web applications. It provides '''protection against phishing''' by using the URL of the website to lookup the stored authentication key.<br />
<br />
= Session Management General Guidelines =<br />
<br />
Session management is directly related to authentication. The '''Session Management General Guidelines''' previously available on this OWASP Authentication Cheat Sheet have been integrated into the [[Session Management Cheat Sheet]].<br />
<br />
= Password Managers =<br />
<br />
Password managers are programs, browser plugins or web services that automate management of large number of different credentials, including memorizing and filling-in, generating random passwords on different sites etc. The web application can help password managers by:<br />
<br />
* using standard HTML forms for username and password input,<br />
* not disabling copy and paste on HTML form fields,<br />
* allowing very long passwords,<br />
* not using multi-stage login schemes (username on first screen, then password),<br />
* not using highly scripted (JavaScript) authentication schemes.<br />
<br />
= Authors and Primary Editors =<br />
<br />
Eoin Keary eoinkeary[at]owasp.org <br />
<br />
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=SAML_Security_Cheat_Sheet&diff=195983SAML Security Cheat Sheet2015-06-09T20:48:12Z<p>Pawel Krawczyk: /* Validate Protocol Usage */ further SAML validation recommendations</p>
<hr />
<div>The Web Browser SSO Profile with Redirect/POST bindings is the most common SSO implementation. The checklist will focus primarily on this profile.<br />
<br />
=Validate Message Confidentiality and Integrity=<br />
<br />
* [[Transport Layer Protection Cheat Sheet|TLS 1.2]] is the most common solution to guarantee message confidentiality and integrity. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security (section 4)] for additional information. This step will help counter the following attacks:<br />
** Eavesdropping 7.1.1.1<br />
** Theft of User Authentication Information 7.1.1.2<br />
** Theft of the Bearer Token 7.1.1.3<br />
** Message Deletion 7.1.1.6<br />
** Message Modification 7.1.1.7<br />
** Man-in-the-middle 7.1.1.8<br />
*A digitally signed message with a certified key is the most common solution to guarantee message integrity and authentication. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security (section 4)] for additional information. This step will help counter the following attacks:<br />
**Man-in-the-middle 6.4.2<br />
**Forged Assertion 6.4.3<br />
<br />
=Validate Protocol Usage=<br />
<br />
This is a common area for security gaps - see [http://www.ai-lab.it/armando/pub/fmse9-armando.pdf Google SSO vulnerability] (AVANTSSAR 2008) for a real life example. Their SSO profile was vulnerable to a Man-in-the-middle attack from a malicious SP (Service Provider). The SSO Web Browser Profile is most susceptible to attacks from trusted partners. This particular security flaw was exposed because the SAML Response did not contain all of the required data elements necessary for a secure message exchange. Following the [http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profile] usage requirements for AuthnRequest (4.1.4.1) and Response (4.1.4.2) will help counter this attack. The AVANTSSAR team suggested the following data elements should be required:<br />
<br />
* '''AuthnRequest(ID, SP);''' An AuthnRequest must contain and ID and SP. Where ID is a string uniquely identifying the request and an SP identifies the Service Provider that initiated the request. Furthermore, the request ID attribute must be returned in the response (InResponseTo="<requestId>"). InResponseTo helps guarantee authenticity of the response from the trusted IdP. This was one of the missing attributes that left Google's SSO vulnerable.<br />
* '''Response(ID, SP, IdP, {AA} K -1/IdP);''' A Response must contain all these elements. Where ID is a string uniquely identifying the response. SP identifies the recipient of the response. IdP identifies the identity provider authorizing the response. {AA} K -1/IdP is the assertion digitally signed with the private key of the IdP.<br />
* '''AuthAssert(ID, C, IdP, SP);''' An authentication assertion must exist within the Response. It must contain an ID, a client (C), an identity provider (IdP), and a service provider (SP) identifier.<br />
<br />
Further vulnerabilities in SAML implementations were described in 2012 ([https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91-8-23-12.pdf On Breaking SAML: Be Whoever You Want to Be]). The following recommendations were proposed in response ([http://arxiv.org/pdf/1401.7483v1.pdf Secure SAML validation to prevent XML signature wrapping attacks]):<br />
<br />
* Always perform schema validation on the XML document prior to using it for any security-related purposes.<br />
** Always use local, trusted copies of schemas for validation.<br />
** Never allow automatic download of schemas from third party locations.<br />
** If possible, inspect schemas and perform schema hardening, to disable possible wildcard type or relaxed processing statements.<br />
* Securely validate the digital signature.<br />
** If you only expect only one signing key, use StaticKeySelector. Obtain the key directly from the identity provider, store it in local file and ignore any KeyInfo elements in the document.<br />
** If you expect more than one signing key, use X509KeySelector (the JKS variant). Obtain these keys directly form the identity providers, store them in local JKS and ignore any KeyInfo elements in the document.<br />
** If you expect a heterogenous signed documents (many certificates from many identity providers, multilevel validation paths), implement full trust establishment model based on PKIX and trusted root certificates.<br />
* Avoid signature-wrapping attacks.<br />
** Never used getElementsByTagName to select security related elements in an XML document without prior validation.<br />
**Always use absolute XPath expressions to select elements, unless a hardened schema is used for validation.<br />
<br />
=Validate Protocol Processing Rules=<br />
<br />
This is another common area for security gaps simply because of the vast number of steps to assert. Processing a SAML response is an expensive operation but all steps must be validated.<br />
*Validate AuthnRequest processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf SAML Core] (3.4.1.4) for all AuthnRequest processing rules. This step will help counter the following attacks:<br />
** Man-in-the-middle (6.4.2)<br />
* Validate Response processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profiles] (4.1.4.3) for all Response processing rules. This step will help counter the following attacks:<br />
** Stolen Assertion (6.4.1)<br />
** Man-in-the-middle (6.4.2)<br />
** Forged Assertion (6.4.3)<br />
** Browser State Exposure (6.4.4)<br />
<br />
=Validate Binding Implementation=<br />
<br />
*For an HTTP Redirect Binding refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf SAML Binding] (3.4). To view an encoding example, you may want to reference RequestUtil.java found within [https://developers.google.com/google-apps/sso/saml_reference_implementation_web Google's reference implementation].<br />
* For an HTTP POST Binding refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf SAML Binding] (3.5). The caching considerations are also very important. If a SAML protocol message gets cached, it can subsequently be used as a Stolen Assertion (6.4.1) or Replay (6.4.5) attack.<br />
<br />
=Validate Security Countermeasures=<br />
<br />
Revisit each security threat that exists within the [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security] document and assert you have applied the appropriate countermeasures for threats that may exist for your particular implementation. Additional countermeasures considererd should include:<br />
*Prefer IP Filtering when appropriate. For example, this countermeasure could have prevented Google's initial security flaw if Google provided each trusted partner with a separate endpoint and setup an IP filter for each endpoint. This step will help counter the following attacks:<br />
**Stolen Assertion (6.4.1)<br />
**Man-in-the-middle (6.4.2)<br />
*Prefer short lifetimes on the SAML Response. This step will help counter the following attacks:<br />
**Stolen Assertion (6.4.1)<br />
**Browser State Exposure (6.4.4)<br />
*Prefer OneTimeUse on the SAML Response. This step will help counter the following attacks:<br />
**Browser State Exposure (6.4.4)<br />
**Replay (6.4.5)<br />
<br />
Need an architectural diagram? The [http://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf SAML technical overview] contains the most complete diagrams. For the Web Browser SSO Profile with Redirect/POST bindings refer to the section 4.1.3. In fact, of all the SAML documentation, the technical overview is the most valuable from a high-level perspective.<br />
<br />
= Authors and Primary Editors =<br />
<br />
* [http://bradbroulik.blogspot.dk/2010/01/bulletproof-sso-with-saml-20.html Brad Broulik]<br />
* [https://ipsec.pl/ Paweł Krawczyk]<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=SAML_Security_Cheat_Sheet&diff=195982SAML Security Cheat Sheet2015-06-09T20:33:55Z<p>Pawel Krawczyk: /* Validate Protocol Processing Rules */ typo</p>
<hr />
<div>The Web Browser SSO Profile with Redirect/POST bindings is the most common SSO implementation. The checklist will focus primarily on this profile.<br />
<br />
=Validate Message Confidentiality and Integrity=<br />
<br />
* [[Transport Layer Protection Cheat Sheet|TLS 1.2]] is the most common solution to guarantee message confidentiality and integrity. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security (section 4)] for additional information. This step will help counter the following attacks:<br />
** Eavesdropping 7.1.1.1<br />
** Theft of User Authentication Information 7.1.1.2<br />
** Theft of the Bearer Token 7.1.1.3<br />
** Message Deletion 7.1.1.6<br />
** Message Modification 7.1.1.7<br />
** Man-in-the-middle 7.1.1.8<br />
*A digitally signed message with a certified key is the most common solution to guarantee message integrity and authentication. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security (section 4)] for additional information. This step will help counter the following attacks:<br />
**Man-in-the-middle 6.4.2<br />
**Forged Assertion 6.4.3<br />
<br />
=Validate Protocol Usage=<br />
<br />
This is a common area for security gaps - see [http://www.ai-lab.it/armando/pub/fmse9-armando.pdf Google SSO vulnerability] (AVANTSSAR 2008) for a real life example. Their SSO profile was vulnerable to a Man-in-the-middle attack from a malicious SP (Service Provider). The SSO Web Browser Profile is most susceptible to attacks from trusted partners. This particular security flaw was exposed because the SAML Response did not contain all of the required data elements necessary for a secure message exchange. Following the [http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profile] usage requirements for AuthnRequest (4.1.4.1) and Response (4.1.4.2) will help counter this attack. The AVANTSSAR team suggested the following data elements should be required:<br />
<br />
* '''AuthnRequest(ID, SP);''' An AuthnRequest must contain and ID and SP. Where ID is a string uniquely identifying the request and an SP identifies the Service Provider that initiated the request. Furthermore, the request ID attribute must be returned in the response (InResponseTo="<requestId>"). InResponseTo helps guarantee authenticity of the response from the trusted IdP. This was one of the missing attributes that left Google's SSO vulnerable.<br />
* '''Response(ID, SP, IdP, {AA} K -1/IdP);''' A Response must contain all these elements. Where ID is a string uniquely identifying the response. SP identifies the recipient of the response. IdP identifies the identity provider authorizing the response. {AA} K -1/IdP is the assertion digitally signed with the private key of the IdP.<br />
* '''AuthAssert(ID, C, IdP, SP);''' An authentication assertion must exist within the Response. It must contain an ID, a client (C), an identity provider (IdP), and a service provider (SP) identifier.<br />
<br />
=Validate Protocol Processing Rules=<br />
<br />
This is another common area for security gaps simply because of the vast number of steps to assert. Processing a SAML response is an expensive operation but all steps must be validated.<br />
*Validate AuthnRequest processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf SAML Core] (3.4.1.4) for all AuthnRequest processing rules. This step will help counter the following attacks:<br />
** Man-in-the-middle (6.4.2)<br />
* Validate Response processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profiles] (4.1.4.3) for all Response processing rules. This step will help counter the following attacks:<br />
** Stolen Assertion (6.4.1)<br />
** Man-in-the-middle (6.4.2)<br />
** Forged Assertion (6.4.3)<br />
** Browser State Exposure (6.4.4)<br />
<br />
=Validate Binding Implementation=<br />
<br />
*For an HTTP Redirect Binding refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf SAML Binding] (3.4). To view an encoding example, you may want to reference RequestUtil.java found within [https://developers.google.com/google-apps/sso/saml_reference_implementation_web Google's reference implementation].<br />
* For an HTTP POST Binding refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf SAML Binding] (3.5). The caching considerations are also very important. If a SAML protocol message gets cached, it can subsequently be used as a Stolen Assertion (6.4.1) or Replay (6.4.5) attack.<br />
<br />
=Validate Security Countermeasures=<br />
<br />
Revisit each security threat that exists within the [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security] document and assert you have applied the appropriate countermeasures for threats that may exist for your particular implementation. Additional countermeasures considererd should include:<br />
*Prefer IP Filtering when appropriate. For example, this countermeasure could have prevented Google's initial security flaw if Google provided each trusted partner with a separate endpoint and setup an IP filter for each endpoint. This step will help counter the following attacks:<br />
**Stolen Assertion (6.4.1)<br />
**Man-in-the-middle (6.4.2)<br />
*Prefer short lifetimes on the SAML Response. This step will help counter the following attacks:<br />
**Stolen Assertion (6.4.1)<br />
**Browser State Exposure (6.4.4)<br />
*Prefer OneTimeUse on the SAML Response. This step will help counter the following attacks:<br />
**Browser State Exposure (6.4.4)<br />
**Replay (6.4.5)<br />
<br />
Need an architectural diagram? The [http://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf SAML technical overview] contains the most complete diagrams. For the Web Browser SSO Profile with Redirect/POST bindings refer to the section 4.1.3. In fact, of all the SAML documentation, the technical overview is the most valuable from a high-level perspective.<br />
<br />
= Authors and Primary Editors =<br />
<br />
* [http://bradbroulik.blogspot.dk/2010/01/bulletproof-sso-with-saml-20.html Brad Broulik]<br />
* [https://ipsec.pl/ Paweł Krawczyk]<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=SAML_Security_Cheat_Sheet&diff=195981SAML Security Cheat Sheet2015-06-09T20:33:35Z<p>Pawel Krawczyk: /* Validate Protocol Usage */ typo</p>
<hr />
<div>The Web Browser SSO Profile with Redirect/POST bindings is the most common SSO implementation. The checklist will focus primarily on this profile.<br />
<br />
=Validate Message Confidentiality and Integrity=<br />
<br />
* [[Transport Layer Protection Cheat Sheet|TLS 1.2]] is the most common solution to guarantee message confidentiality and integrity. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security (section 4)] for additional information. This step will help counter the following attacks:<br />
** Eavesdropping 7.1.1.1<br />
** Theft of User Authentication Information 7.1.1.2<br />
** Theft of the Bearer Token 7.1.1.3<br />
** Message Deletion 7.1.1.6<br />
** Message Modification 7.1.1.7<br />
** Man-in-the-middle 7.1.1.8<br />
*A digitally signed message with a certified key is the most common solution to guarantee message integrity and authentication. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security (section 4)] for additional information. This step will help counter the following attacks:<br />
**Man-in-the-middle 6.4.2<br />
**Forged Assertion 6.4.3<br />
<br />
=Validate Protocol Usage=<br />
<br />
This is a common area for security gaps - see [http://www.ai-lab.it/armando/pub/fmse9-armando.pdf Google SSO vulnerability] (AVANTSSAR 2008) for a real life example. Their SSO profile was vulnerable to a Man-in-the-middle attack from a malicious SP (Service Provider). The SSO Web Browser Profile is most susceptible to attacks from trusted partners. This particular security flaw was exposed because the SAML Response did not contain all of the required data elements necessary for a secure message exchange. Following the [http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profile] usage requirements for AuthnRequest (4.1.4.1) and Response (4.1.4.2) will help counter this attack. The AVANTSSAR team suggested the following data elements should be required:<br />
<br />
* '''AuthnRequest(ID, SP);''' An AuthnRequest must contain and ID and SP. Where ID is a string uniquely identifying the request and an SP identifies the Service Provider that initiated the request. Furthermore, the request ID attribute must be returned in the response (InResponseTo="<requestId>"). InResponseTo helps guarantee authenticity of the response from the trusted IdP. This was one of the missing attributes that left Google's SSO vulnerable.<br />
* '''Response(ID, SP, IdP, {AA} K -1/IdP);''' A Response must contain all these elements. Where ID is a string uniquely identifying the response. SP identifies the recipient of the response. IdP identifies the identity provider authorizing the response. {AA} K -1/IdP is the assertion digitally signed with the private key of the IdP.<br />
* '''AuthAssert(ID, C, IdP, SP);''' An authentication assertion must exist within the Response. It must contain an ID, a client (C), an identity provider (IdP), and a service provider (SP) identifier.<br />
<br />
=Validate Protocol Processing Rules=<br />
<br />
*This is another common area for security gaps simply because of the vast number of steps to assert. Processing a SAML response is an expensive operation but all steps must be validated.<br />
Validate AuthnRequest processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf SAML Core] (3.4.1.4) for all AuthnRequest processing rules. This step will help counter the following attacks:<br />
** Man-in-the-middle (6.4.2)<br />
* Validate Response processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profiles] (4.1.4.3) for all Response processing rules. This step will help counter the following attacks:<br />
** Stolen Assertion (6.4.1)<br />
** Man-in-the-middle (6.4.2)<br />
** Forged Assertion (6.4.3)<br />
** Browser State Exposure (6.4.4)<br />
<br />
=Validate Binding Implementation=<br />
<br />
*For an HTTP Redirect Binding refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf SAML Binding] (3.4). To view an encoding example, you may want to reference RequestUtil.java found within [https://developers.google.com/google-apps/sso/saml_reference_implementation_web Google's reference implementation].<br />
* For an HTTP POST Binding refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf SAML Binding] (3.5). The caching considerations are also very important. If a SAML protocol message gets cached, it can subsequently be used as a Stolen Assertion (6.4.1) or Replay (6.4.5) attack.<br />
<br />
=Validate Security Countermeasures=<br />
<br />
Revisit each security threat that exists within the [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security] document and assert you have applied the appropriate countermeasures for threats that may exist for your particular implementation. Additional countermeasures considererd should include:<br />
*Prefer IP Filtering when appropriate. For example, this countermeasure could have prevented Google's initial security flaw if Google provided each trusted partner with a separate endpoint and setup an IP filter for each endpoint. This step will help counter the following attacks:<br />
**Stolen Assertion (6.4.1)<br />
**Man-in-the-middle (6.4.2)<br />
*Prefer short lifetimes on the SAML Response. This step will help counter the following attacks:<br />
**Stolen Assertion (6.4.1)<br />
**Browser State Exposure (6.4.4)<br />
*Prefer OneTimeUse on the SAML Response. This step will help counter the following attacks:<br />
**Browser State Exposure (6.4.4)<br />
**Replay (6.4.5)<br />
<br />
Need an architectural diagram? The [http://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf SAML technical overview] contains the most complete diagrams. For the Web Browser SSO Profile with Redirect/POST bindings refer to the section 4.1.3. In fact, of all the SAML documentation, the technical overview is the most valuable from a high-level perspective.<br />
<br />
= Authors and Primary Editors =<br />
<br />
* [http://bradbroulik.blogspot.dk/2010/01/bulletproof-sso-with-saml-20.html Brad Broulik]<br />
* [https://ipsec.pl/ Paweł Krawczyk]<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=SAML_Security_Cheat_Sheet&diff=195980SAML Security Cheat Sheet2015-06-09T20:33:10Z<p>Pawel Krawczyk: add initial version based on Brad Broulik article (used with author's written permission, wikified and updated)</p>
<hr />
<div>The Web Browser SSO Profile with Redirect/POST bindings is the most common SSO implementation. The checklist will focus primarily on this profile.<br />
<br />
=Validate Message Confidentiality and Integrity=<br />
<br />
* [[Transport Layer Protection Cheat Sheet|TLS 1.2]] is the most common solution to guarantee message confidentiality and integrity. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security (section 4)] for additional information. This step will help counter the following attacks:<br />
** Eavesdropping 7.1.1.1<br />
** Theft of User Authentication Information 7.1.1.2<br />
** Theft of the Bearer Token 7.1.1.3<br />
** Message Deletion 7.1.1.6<br />
** Message Modification 7.1.1.7<br />
** Man-in-the-middle 7.1.1.8<br />
*A digitally signed message with a certified key is the most common solution to guarantee message integrity and authentication. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security (section 4)] for additional information. This step will help counter the following attacks:<br />
**Man-in-the-middle 6.4.2<br />
**Forged Assertion 6.4.3<br />
<br />
=Validate Protocol Usage=<br />
<br />
This is a common area for security gaps - see [http://www.ai-lab.it/armando/pub/fmse9-armando.pdf Google SSO vulnerability] (AVANTSSAR 2008) for a real life example. Their SSO profile was vulnerable to a Man-in-the-middle attack from a malicious SP (Service Provider). The SSO Web Browser Profile is most susceptible to attacks from trusted partners. This particular security flaw was exposed because the SAML Response did not contain all of the required data elements necessary for a secure message exchange. Following the [http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profile] usage requirements for AuthnRequest (4.1.4.1) and Response (4.1.4.2) will help counter this attack. The AVANTSSAR team suggested the following data elements should be required:<br />
<br />
* '''AuthnRequest(ID, SP);''' An AuthnRequest must contain and ID and SP. Where ID is a string uniquely identifying the request and an SP identifies the Service Provider that initiated the request. Furthermore, the request ID attribute must be returned in the response (InResponseTo="<requestId>"). InResponseTo helps guarantee authenticity of the response from the trusted IdP. This was one of the missing attributes that left Google's SSO vulnerable.<br />
* '''Response(ID, SP, IdP, {AA} K -1/IdP);''' A Response must contain all these elements. Where ID is a string uniquely identifying the response. SP identifies the recipient of the response. IdP identifies the identity provider authorizing the response. {AA} K -1/IdP is the assertion digitally signed with the private key of the IdP.<br />
* '''AuthAssert(ID, C, IdP, SP);''' An authentication assertion must exist within the Response. It must contain an ID, a client (C), an identity provider (IdP), and a service provider (SP) identifier.<br />
<br />
=Validate Protocol Processing Rules=<br />
<br />
*This is another common area for security gaps simply because of the vast number of steps to assert. Processing a SAML response is an expensive operation but all steps must be validated.<br />
Validate AuthnRequest processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf SAML Core] (3.4.1.4) for all AuthnRequest processing rules. This step will help counter the following attacks:<br />
** Man-in-the-middle (6.4.2)<br />
* Validate Response processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profiles] (4.1.4.3) for all Response processing rules. This step will help counter the following attacks:<br />
** Stolen Assertion (6.4.1)<br />
** Man-in-the-middle (6.4.2)<br />
** Forged Assertion (6.4.3)<br />
** Browser State Exposure (6.4.4)<br />
<br />
=Validate Binding Implementation=<br />
<br />
*For an HTTP Redirect Binding refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf SAML Binding] (3.4). To view an encoding example, you may want to reference RequestUtil.java found within [https://developers.google.com/google-apps/sso/saml_reference_implementation_web Google's reference implementation].<br />
* For an HTTP POST Binding refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf SAML Binding] (3.5). The caching considerations are also very important. If a SAML protocol message gets cached, it can subsequently be used as a Stolen Assertion (6.4.1) or Replay (6.4.5) attack.<br />
<br />
=Validate Security Countermeasures=<br />
<br />
Revisit each security threat that exists within the [http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security] document and assert you have applied the appropriate countermeasures for threats that may exist for your particular implementation. Additional countermeasures considererd should include:<br />
*Prefer IP Filtering when appropriate. For example, this countermeasure could have prevented Google's initial security flaw if Google provided each trusted partner with a separate endpoint and setup an IP filter for each endpoint. This step will help counter the following attacks:<br />
**Stolen Assertion (6.4.1)<br />
**Man-in-the-middle (6.4.2)<br />
*Prefer short lifetimes on the SAML Response. This step will help counter the following attacks:<br />
**Stolen Assertion (6.4.1)<br />
**Browser State Exposure (6.4.4)<br />
*Prefer OneTimeUse on the SAML Response. This step will help counter the following attacks:<br />
**Browser State Exposure (6.4.4)<br />
**Replay (6.4.5)<br />
<br />
Need an architectural diagram? The [http://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf SAML technical overview] contains the most complete diagrams. For the Web Browser SSO Profile with Redirect/POST bindings refer to the section 4.1.3. In fact, of all the SAML documentation, the technical overview is the most valuable from a high-level perspective.<br />
<br />
= Authors and Primary Editors =<br />
<br />
* [http://bradbroulik.blogspot.dk/2010/01/bulletproof-sso-with-saml-20.html Brad Broulik]<br />
* [https://ipsec.pl/ Paweł Krawczyk]<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Content_Security_Policy_Cheat_Sheet&diff=195979Content Security Policy Cheat Sheet2015-06-09T20:19:00Z<p>Pawel Krawczyk: /* Removing unsafe-inline */ add more examples of refactoring inline code</p>
<hr />
<div>Content Security Policy (CSP) is an important standard by the W3C that is aimed to prevent a broad range of content injection attacks such as cross-site scripting (XSS). <br />
<br />
= Introduction =<br />
<br />
Content Security Policy (CSP) is an effective "defense in depth" technique to be used against content injection attacks. It is a declarative policy that informs the user agent what are valid sources to load from.<br />
<br />
Since, it was introduced in Firefox version 4 by Mozilla, it has been adopted as a standard, and grown in adoption and capabilities.<br />
<br />
This document is meant to provide guidance on how to utilize CSP under a variety of situations to address a variety of concerns.<br />
<br />
= References =<br />
<br />
Specifications of the CSP standard can be found the following locations:<br />
* Latest Revision - https://w3c.github.io/webappsec/specs/content-security-policy/<br />
* Latest Version (CSP2) - http://www.w3.org/TR/CSP2/<br />
* CSP 1.0 - http://www.w3.org/TR/2012/CR-CSP-20121115/<br />
<br />
= CSP Basics =<br />
<br />
CSP consists of a series of directives. CSP has also evolved over two major revisions. Most browsers support 1.0, and adoption of CSP2 has been incremental.<br />
<br />
== HTTP Headers ==<br />
<br />
The following are headers for CSP.<br />
<br />
* '''Content-Security-Policy''' : W3C Spec standard header. Supported by Firefox 23+, Chrome 25+ and Opera 19+<br />
* '''Content-Security-Policy-Report-Only''' : W3C Spec standard header. Supported by Firefox 23+, Chrome 25+ and Opera 19+, whereby the policy is non-blocking ("fail open") and a report is sent to the URL designated by the '''report-uri''' directive. This is often used as a precursor to utilizing CSP in blocking mode ("fail closed")<br />
* '''DO NOT''' use X-Content-Security-Policy or X-WebKit-CSP. Their implementations are obsolete (since Firefox 23, Chrome 25), limited, inconsistent, and incredibly buggy.<br />
<br />
== Directives == <br />
<br />
The following is a listing of directives, and a brief description.<br />
<br />
=== CSP 1.0 Spec ===<br />
* '''connect-src''' (d) - restricts which URLs the protected resource can load using script interfaces. (e.g. send() method of an XMLHttpRequest object) <br />
* '''font-src''' (d) - restricts from where the protected resource can load fonts<br />
* '''img-src''' (d) - restricts from where the protected resource can load images<br />
* '''media-src''' (d) - restricts from where the protected resource can load video, audio, and associated text tracks<br />
* '''object-src''' (d) - restricts from where the protected resource can load plugins<br />
* '''script-src''' (d) - restricts which scripts the protected resource can execute. Additional restrictions against, inline scripts, and eval. Additional directives in CSP2 for hash and nonce support<br />
* '''style-src''' (d) - restricts which styles the user may applies to the protected resource. Additional restrictions against inline and eval.<br />
* '''default-src''' - Covers any directive with ''(d)''<br />
* '''frame-src''' - restricts from where the protected resource can embed frames. Note, deprecated in CSP2<br />
* '''report-uri''' - specifies a URL to which the user agent sends reports about policy violation<br />
* '''sandbox''' - specifies an HTML sandbox policy that the user agent applies to the protected resource. Optional in 1.0<br />
<br />
=== New in CSP2 ===<br />
* '''form-action''' - retricts which URLs can be used as the action of HTML form elements<br />
* '''frame-ancestors''' - indicates whether the user agent should allow embedding the resource using a frame, iframe, object, embed or applet element, or equivalent functionality in non-HTML resources<br />
* '''plugin-types''' - restricts the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded<br />
* '''base-uri''' - restricts the URLs that can be used to specify the document base URL<br />
* '''child-src''' (d) - governs the creation of nested browsing contexts as well as Worker execution contexts<br />
<br />
= CSP Sample Policies =<br />
<br />
== Basic CSP Policy ==<br />
<br />
This policy will only allow resources from the originating domain for all the default level directives, and will not allow inline scripts/styles to execute. If your application and function with these restrictions, it drastically reduces your attack surface having this policy in place, and will work with most modern browsers.<br />
<br />
The most basic policy assumes:<br />
* all resources are hosted by the same domain of the document<br />
* there are no inlines or evals for scripts and style resources<br />
<br />
Content-Security-Policy: default-src 'self' <br />
<br />
To tighten further, one can do the following:<br />
<br />
Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';<br />
<br />
This policy allows images, scripts, AJAX, and CSS from the same origin, and does not allow any other resources to load (eg. object, frame, media, etc). (see http://content-security-policy.com/)<br />
<br />
== Mixed Content Policy ==<br />
<br />
In order to prevent mixed content (resources being loaded over http, from a document loaded over https), one can use the value "https:" as a directive value.<br />
<br />
For instance:<br />
<br />
Content-Security-Policy: default-src https:; connect-src https:; font-src https: data:; frame-src https:; <br />
img-src https: data:; media-src https:; object-src https:; script-src 'unsafe-inline' 'unsafe-eval' https:; <br />
style-src 'unsafe-inline' https:;<br />
<br />
This is what was used at Twitter, Oct 2014. The policy prevents mixed content, allows for scheme "data:" in font-src and img-src, allows for unsafe-inline and unsafe-eval for script-src, and unsafe-inline for style-src. (see: https://twittercommunity.com/t/blocking-mixed-content-with-content-security-policy/26375)<br />
<br />
Mixed Content has two categories: Active and Passive. Passive content consists of "resources which cannot directly interact with or modify other resources on a page: images, fonts, audio, and video for example", whereas active content is "content which can in some way directly manipulate the resource with which a user is interacting." (http://www.w3.org/TR/2014/WD-mixed-content-20140722)<br />
<br />
Content-Security-Policy: img-src https: data:; font-src https: data:; media-src https:;<br />
<br />
This is an example to block only passive mixed content.<br />
<br />
Content-Security-Policy: script-src https:; style-src https:; object-src https:; connect-src https:; frame-src https:; <br />
<br />
This is an example to block only active mixed content.<br />
<br />
== Preventing Clickjacking ==<br />
<br />
The established way of preventing clickjacking involves the use of the header <code>X-Frame-Options</code> (see: [[Clickjacking_Defense_Cheat_Sheet]]). However, CSP 2.0 has a new directive <code>frame-ancestors</code>.<br />
<br />
To prevent all framing of your content use:<br />
<br />
Content-Security-Policy: frame-ancestors 'none'<br />
<br />
To allow for your site only, use:<br />
<br />
Content-Security-Policy: frame-ancestors 'self'<br />
<br />
To allow for trusted domain (my-trusty-site.com), do the following:<br />
<br />
Content-Security-Policy: frame-ancestors my-trusty-site.com <br />
<br />
A word about support. Not supported in all browsers yet, Chrome 40+ and FF 35+ support, but will also default to X-Frame-Options if it exists. Spec says, CSP should take precedence. https://w3c.github.io/webappsec/specs/content-security-policy/#frame-ancestors-and-frame-options<br />
<br />
Also, keep in mind the following (from the [https://w3c.github.io/webappsec/specs/content-security-policy/#frame-ancestors-and-frame-options CSP Spec]):<br />
<br />
The frame-ancestors directive MUST be ignored when monitoring a policy, and when a contained in a policy defined via a meta element.<br />
<br />
In otherwords, this will not work when CSP is in a <meta> tag, and will not work when using Content-Security-Policy-Report-Only.<br />
<br />
When a report is generated, the blocked-uri will only have a value if it is the same origin as the page.<br />
<br />
= Refactoring inline code =<br />
By default CSP disables any unsigned JavaScript code placed inline in the HTML source, such as this:<br />
<br />
<script>var foo = "314"<script><br />
<br />
The inline code can be enabled by '''specifying its SHA256 hash''' in the CSP header:<br />
<br />
Content-Security-Policy: script-src 'sha256-gPMJwWBMWDx0Cm7ZygJKZIU2vZpiYvzUQjl5Rh37hKs='<br />
<br />
This particular script's hash can be calculated using the following command:<br />
<br />
echo -n 'var foo = "314"' | openssl sha256 -binary | openssl base64<br />
<br />
Some browsers (e.g. Chrome) will also display the hash of the script in JavaScript console warning when blocking an unsigned script.<br />
<br />
The inline code can be also simply moved to a separate JavaScript file:<br />
<br />
<script>var foo = "314"<script><br />
<br />
becomes:<br />
<br />
<script src="app.js"></script><br />
<br />
with `app.js` containing the `var foo = "314"` code.<br />
<br />
The inline code restriction also applies to '''inline event handlers''', so that the following construct will be blocked under CSP:<br />
<br />
<button id="button1" onclick="doSomething()"><br />
<br />
This should be replaced by `addEventListener' calls:<br />
<br />
document.getElementById("button1").addEventListener('click', doSomething);<br />
<br />
Variable assignment in inline scripts. Rather than do this:<br />
<br />
<script>var foo = "314";<script><br />
<br />
Leverage HTML5's custom data attributes by setting the value as follows:<br />
<br />
<body data-foo="314”><br />
...<br />
</body><br />
<br />
And access the value by doing:<br />
<br />
var itemID = document.body.getAttribute("data-foo”);<br />
<br />
= Authors and Primary Editors =<br />
<br />
* Neil Mattatall - neil[at]owasp.org<br />
* Denis Mello - ddtaxe<br />
* Boris Chen<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Certificate_and_Public_Key_Pinning&diff=193599Certificate and Public Key Pinning2015-04-17T20:49:29Z<p>Pawel Krawczyk: /* HTTP pinning */ RFC 7469</p>
<hr />
<div><br />
[[Certificate and Public Key Pinning]] is a technical guide to implementing certificate and public key pinning as discussed at the ''[https://www.owasp.org/index.php/Virginia Virginia chapter's]'' presentation [[Media:Securing-Wireless-Channels-in-the-Mobile-Space.ppt|Securing Wireless Channels in the Mobile Space]]. This guide is focused on providing clear, simple, actionable guidance for securing the channel in a hostile environment where actors could be malicious and the conference of trust a liability. Additional presentation material included [[Media:pubkey-pin-supplement.pdf|supplement with code excerpts]], [[Media:pubkey-pin-android.zip|Android sample program]], [[Media:pubkey-pin-ios.zip|iOS sample program]], [[Media:pubkey-pin-dotnet.zip|.Net sample program]], and [[Media:pubkey-pin-openssl.zip|OpenSSL sample program]].<br />
<br />
A cheat sheet is available at [[Pinning_Cheat_Sheet|Pinning Cheat Sheet]].<br />
<br />
== Introduction == <br />
<br />
Secure channels are a cornerstone to users and employees working remotely and on the go. Users and developers expect end-to-end security when sending and receiving data - especially sensitive data on channels protected by VPN, SSL, or TLS. While organizations which control DNS and CA have likely reduced risk to trivial levels under most threat models, users and developers subjugated to other's DNS and a public CA hierarchy are exposed to non-trivial amounts of risk. In fact, history has shown those relying on outside services have suffered chronic breaches in their secure channels.<br />
<br />
The pandemic abuse of trust has resulted in users, developers and applications making security related decisions on untrusted input. The situation is somewhat of a paradox: entities such as DNS and CAs are trusted and supposed to supply trusted input; yet their input cannot be trusted. Relying on untrusted input for security related decisions is not only bad karma, it violates a number of secure coding principals (see, for example, OWASP's [[Injection Theory]] and [[Data Validation]]).<br />
<br />
Pinning effectively removes the "conference of trust". An application which pins a certificate or public key no longer needs to depend on others - such as DNS or CAs - when making security decisions relating to a peer's identity. For those familiar with SSH, you should realize that public key pinning is nearly identical to SSH's <tt>StrictHostKeyChecking</tt> option. SSH had it right the entire time, and the rest of the world is beginning to realize the virtues of directly identifying a host or service by its public key.<br />
<br />
Others who actively engage in pinning include Google and its browser Chrome. Chrome was successful in detecting the DigiNotar compromise which uncovered suspected interception by the Iranian government on its citizens. The initial report of the compromise can be found at ''[https://productforums.google.com/d/topic/gmail/3J3r2JqFNTw/discussion Is This MITM Attack to Gmail's SSL?]''; and Google Security's immediate response at ''[https://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted-man-in-middle.html An update on attempted man-in-the-middle attacks]''.<br />
<br />
== What's the problem? ==<br />
<br />
Users, developers, and applications expect end-to-end security on their secure channels, but some secure channels are not meeting the expectation. Specifically, channels built using well known protocols such as VPN, SSL, and TLS can be vulnerable to a number of attacks.<br />
<br />
Examples of past failures are listed on the discussion tab for this article. This cheat sheet does not attempt to catalogue the failures in the industry, investigate the design flaws in the scaffolding, justify the lack of accountability or liability with the providers, explain the race to the bottom in services, or demystify the collusion between, for example, Browsers and CAs. For additional reading, please visit ''[http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf PKI is Broken]'' and ''[http://blog.cryptographyengineering.com/2012/02/how-to-fix-internet.html The Internet is Broken]''.<br />
<br />
=== Patient 0 ===<br />
<br />
The original problem was the ''Key Distribution Problem''. Insecure communications can be transformed into a secure communication problem with encryption. Encrypted communications can be transformed into an identity problem with signatures. The identity problem terminates at the key distribution problem. They are the same problem.<br />
<br />
=== The Cures ===<br />
<br />
There are three cures for the key distribution problem. First is to have first hand knowledge of your partner or peer (i.e., a peer, server or service). This could be solved with SneakerNet. Unfortunately, SneakerNet does not scale and cannot be used to solve the key distribution problem.<br />
<br />
The second is to rely on others, and it has two variants: (1) web of trust, and (2) hierarchy of trust. Web of Trust and Hierarchy of Trust solve the key distribution problem in a sterile environment. However, Web of Trust and Hierarchy of Trust each requires us to rely on others - or '''confer trust'''. In practice, trusting others is showing to be problematic.<br />
<br />
== What Is Pinning? ==<br />
<br />
Pinning is the process of associating a host with their ''expected'' X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a ''pinset'' (taking from [https://developers.google.com/events/io/sessions/gooio2012/107/ Jon Larimer and Kenny Root Google I/O talk]). In this case, the advertised identity must match one of the elements in the pinset.<br />
<br />
A host or service's certificate or public key can be added to an application at development time, or it can be added upon first encountering the certificate or public key. The former - adding at development time - is preferred since ''preloading'' the certificate or public key ''out of band'' usually means the attacker cannot taint the pin. If the certificate or public key is added upon first encounter, you will be using ''key continuity''. Key continuity can fail if the attacker has a privileged position during the first first encounter.<br />
<br />
Pinning leverages knowledge of the pre-existing relationship between the user and an organization or service to help make better security related decisions. Because you already have information on the server or service, you don't need to rely on generalized mechanisms meant to solve the ''key distribution'' problem. That is, you don't need to turn to DNS for name/address mappings or CAs for bindings and status. Once exception is revocation and it is discussed below in [[#Pinning_Gaps|Pinning Gaps]].<br />
<br />
It is also worth mention that Pinning is not Stapling. Stapling sends both the certificate and OCSP responder information in the same request to avoid the additional fetches the client should perform during path validations.<br />
<br />
=== When Do You Pin? ===<br />
<br />
You should pin anytime you want to be relatively certain of the remote host's identity or when operating in a hostile environment. Since one or both are almost always true, you should probably pin all the time.<br />
<br />
A perfect case in point: during the two weeks or so of preparation for the presentation and cheat sheet, we've observed three relevant and related failures. First was [http://gaurangkp.wordpress.com/2013/01/09/nokia-https-mitm/ Nokia/Opera willfully breaking the secure channel]; second was [http://blog.malwarebytes.org/intelligence/2013/02/digital-certificates-and-malware-a-dangerous-mix/ DigiCert issuing a code signing certificate for malware]; and third was [http://krebsonsecurity.com/2013/02/security-firm-bit9-hacked-used-to-spread-malware/ Bit9's loss of its root signing key]. The environment is not only hostile, its toxic.<br />
<br />
=== When Do You Whitelist? ===<br />
<br />
If you are working for an organization which practices "egress filtering" as part of a Data Loss Prevention (DLP) strategy, you will likely encounter ''Interception Proxies''. I like to refer to these things as '''"good" bad guys''' (as opposed to '''"bad" bad guys''') since both break end-to-end security and we can't tell them apart. In this case, '''do not''' offer to whitelist the interception proxy since it defeats your security goals. Add the interception proxy's public key to your pinset after being '''instructed''' to do so by the folks in Risk Acceptance.<br />
<br />
Note: if you whitelist a certificate or public key for a different host (for example, to accommodate an interception proxy), you are no longer pinning the expected certificates and keys for the host. Security and integrity on the channel could suffer, and it surely breaks end-to-end security expectations of users and organizations.<br />
<br />
For more reading on interception proxies, the additional risk they bestow, and how they fail, see Dr. Matthew Green's ''[http://blog.cryptographyengineering.com/2012/03/how-do-interception-proxies-fail.html How do Interception Proxies fail?]'' and Jeff Jarmoc's BlackHat talk ''[https://www.blackhat.com/html/bh-eu-12/bh-eu-12-archives.html#jarmoc SSL/TLS Interception Proxies and Transitive Trust]''.<br />
<br />
=== How Do You Pin? ===<br />
<br />
The idea is to re-use the exiting protocols and infrastructure, but use them in a hardened manner. For re-use, a program would keep doing the things it used to do when establishing a secure connection.<br />
<br />
To harden the channel, the program would take advantage of the <tt>OnConnect</tt> callback offered by a library, framework or platform. In the callback, the program would verify the remote host's identity by validating its certificate or public key. While pinning does not have to occur in an <tt>OnConnect</tt> callback, its often most convenient because the underlying connection information is readily available.<br />
<br />
== What Should Be Pinned? ==<br />
<br />
The first thing to decide is what should be pinned. For this choice, you have two options: you can (1) pin the certificate; or (2) pin the public key. If you choose public keys, you have two additional choices: (a) pin the <tt>subjectPublicKeyInfo</tt>; or (b) pin one of the concrete types such as <tt>RSAPublicKey</tt> or <tt>DSAPublicKey</tt>.<br />
<br />
The three choices are explained below in more detail. I would encourage you to pin the <tt>subjectPublicKeyInfo</tt> because it has the public parameters (such as <tt>{e,n}</tt> for an RSA public key) '''and''' contextual information such as an algorithm and OID. The context will help you keep your bearings at times, and Figure 1 below shows the additional information available.<br />
<br />
=== Encodings/Formats ===<br />
<br />
For the purposes of this article, the objects are in X509-compatible presentation format (PKCS#1 defers to X509, both of which use ASN.1). If you have a PEM encoded object (for example, <tt>-----BEGIN CERTIFICATE-----</tt>, <tt>-----END CERTIFICATE-----</tt>), then convert the object to DER encoding. Conversion using OpenSSL is offered below in [[#Format_Conversions|Format Conversions]].<br />
<br />
A certificate is an object which binds an entity (such as a person or organization) to a public key via a signature. The certificate is DER encoded, and has associated data or attributes such as ''Subject'' (who is identified or bound), ''Issuer'' (who signed it), ''Validity'' (''NotBefore'' and ''NotAfter''), and a ''Public Key''.<br />
<br />
A certificate has a ''subjectPublicKeyInfo''. The subjectPublicKeyInfo is a key with additional information. The ASN.1 type includes an ''Algorithm ID'', a ''Version'', and an extensible format to hold a concrete public key. Figures 1 and 2 below show different views of the same RSA key, which is the subjectPublicKeyInfo. The key is for the site [https://www.random.org random.org], and it is used in the sample programs and listings below.<br />
<br />
{| align="center"<br />
| [[File:random-org-der-dump.png|thumb|375px|Figure 1: subjectPublicKeyInfo dumped with dumpans1]]<br />
| [[File:random-org-der-hex.png|thumb|375px|Figure 2: subjectPublicKeyInfo under a hex editor]]<br />
|}<br />
<br />
The concrete public key is an encoded public key. The key format will usually be specified elsewhere - for example, PKCS#1 in the case of RSA Public Keys. In the case of an RSA public key, the type is ''RSAPublicKey'' and the parameters <tt>{e,n}</tt> will be ASN.1 encoded. Figures 1 and 2 above clearly show the modulus (''n'' at line 28) and exponent (''e'' at line 289). For DSA, the concrete type is DSAPublicKey and the ASN.1 encoded parameters would be <tt>{p,q,g,y}</tt>.<br />
<br />
Final takeaways: (1) a certificate binds an entity to a public key; (2) a certificate has a subjectPublicKeyInfo; and (3) a subjectPublicKeyInfo has an concrete public key. For those who want to learn more, a more in-depth discussion from a programmer's perspective can be found at the Code Project's article ''[http://www.codeproject.com/Articles/25487/Cryptographic-Interoperability-Keys Cryptographic Interoperability: Keys]''.<br />
<br />
=== Certificate ===<br />
<br />
[[File:pin-cert.png|thumb|right|100px|Certificate]] The certificate is easiest to pin. You can fetch the certificate out of band for the website, have the IT folks email your company certificate to you, use <tt>openssl s_client</tt> to retrieve the certificate etc. When the certificate expires, you would update your application. Assuming your application has no bugs or security defects, the application would be updated every year or two.<br />
<br />
At runtime, you retrieve the website or server's certificate in the callback. Within the callback, you compare the retrieved certificate with the certificate embedded within the program. If the comparison fails, then fail the method or function. <br />
<br />
There is a downside to pinning a certificate. If the site rotates its certificate on a regular basis, then your application would need to be updated regularly. For example, Google rotates its certificates, so you will need to update your application about once a month (if it depended on Google services). Even though Google rotates its certificates, the underlying public keys (within the certificate) remain static.<br />
<br />
=== Public Key ===<br />
<br />
[[File:pin-pubkey.png|thumb|right|100px|Public Key]] Public key pinning is more flexible but a little trickier due to the extra steps necessary to extract the public key from a certificate. As with a certificate, the program checks the extracted public key with its embedded copy of the public key.<br />
<br />
There are two downsides two public key pinning. First, its harder to work with keys (versus certificates) since you usually must extract the key from the certificate. Extraction is a minor inconvenience in Java and .Net, buts its uncomfortable in Cocoa/CocoaTouch and OpenSSL. Second, the key is static and may violate key rotation policies.<br />
<br />
=== Hashing ===<br />
<br />
While the three choices above used DER encoding, its also acceptable to use a hash of the information (or other transforms). In fact, the original sample programs were written using digested certificates and public keys. The samples were changed to allow a programmer to inspect the objects with tools like <tt>dumpasn1</tt> and other ASN.1 decoders.<br />
<br />
Hashing also provides three additional benefits. First, hashing allows you to anonymize a certificate or public key. This might be important if you application is concerned about leaking information during decompilation and re-engineering.<br />
<br />
Second, a digested certificate fingerprint is often available as a native API for many libraries, so its convenient to use.<br />
<br />
Finally, an organization might want to supply a reserve (or back-up) identity in case the primary identity is compromised. Hashing ensures your adversaries do not see the reserved certificate or public key in advance of its use. In fact, Google's IETF draft ''websec-key-pinning'' uses the technique.<br />
<br />
== What About X509? ==<br />
<br />
PKI{X} and the Internet form an intersection. What Internet users expect and what they receive from CAs could vary wildly. For example, an Internet user has security goals, while a CA has revenue goals and legal goals. Many are surprised to learn that the user is often required to perform host identity verification even though the CA issued the certificate (the details are buried in CA warranties on their certificates and their Certification Practice Statement (CPS)).<br />
<br />
There are a number of PKI profiles available. For the Internet, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)", also known as [http://tools.ietf.org/rfc/rfc5280.txt RFC 5280], is of interest. Since a certificate is specified in the ITU's X509 standard, there are lots of mandatory and optional fields available for validation from both bodies. Because of the disjoint goals among groups, the next section provides guidance.<br />
<br />
=== Mandatory Checks ===<br />
<br />
All X509 verifications must include:<br />
<br />
* A path validation check. The check verifies all the signatures on certificates in the chain are valid under a given PKI. The check begins at the server or service's certificate (the leaf), and proceeds back to a trusted root certificate (the root).<br />
<br />
* A validity check, or the <tt>notBefore</tt> and <tt>notAfter</tt> fields. The <tt>notAfter</tt> field is especially important since a CA will not warrant the certificate after the date, and it does not have to provide CRL/OCSP updates after the date.<br />
<br />
* Revocation status. As with <tt>notAfter</tt>, revocation is important because the CA will not warrant a certificate once it is listed as revoked. The IETF approved way of checking a certificate's revocation is OCSP and specified in [http://tools.ietf.org/rfc/rfc2560.txt RFC 2560].<br />
<br />
=== Optional Checks ===<br />
<br />
<nowiki>[Mulling over what else to present, and the best way to present it. Subject name? DNS lookups? Key Usage? Algorithms? Geolocation based on IP? Check back soon.]</nowiki><br />
In the model which pre-dated PKIX RFC-5280, X.509v1 there was strong binding of the certificate Subject name to the X.500 Directory. With the update to X.509v3, the Directory is still the standard for authentication of caCertificate attributes, versus accepting a self signed root. Geo-location is important, the fake certificate for Google was given a location of Florida, instead of Mountain View, CA. The binding of the certificate to the Directory can anchor the root caCertificate, in effect "pin" it, to a valid entity that can have demonstrable attributes such as location. This is detailed in RFC-1255. Additional fields specified, such as the subject alternative field, for example a RFC-822 email address, or DNS name, can be located in the DNS, but the actual heavy lifting is done by the X.500 Directory, which is used currently as a cross-certificate trust conduit at the Federal Bridge between major communities of interest, that are not Internet focused. While those cross-certificates are valuable in validation between trust communities, a self-signed root, still needs to be either pinned, curated in trust bundle such as in web browser software secure storage or represented by a federated community. The Directory can play a role to fill in gaps to validate caCertificates, either locally, or nationally under an administrative domain such as c=US. By divorcing the subject from the Directory entry, problems begin to arise in which pinning plays a key role to ensure that client and server have the same reference points.<br />
<br />
=== Public Key Checks ===<br />
<br />
''Quod vide'' (''q.v.''). Verifying the identity of a host with knowledge of its associated/expected public key is pinning.<br />
<br />
== Examples of Pinning ==<br />
<br />
This section demonstrates certificate and public key pinning in Android Java, iOS, .Net, and OpenSSL. All programs attempt to connect to [https://www.random.org random.org] and fetch bytes (Dr. Mads Haahr participates in AOSP's pinning program, so the site should have a static key). The programs enjoy a pre-existing relationship with the site (more correctly, ''a priori'' knowledge), so they include a copy of the site's public key and pin the identity on the key.<br />
<br />
Parameter validation, return value checking, and error checking have been omitted in the code below, but is present in the sample programs. So the sample code is ready for copy/paste. By far, the most uncomfortable languages are C-based: iOS and OpenSSL.<br />
<br />
===HTTP pinning===<br />
[http://www.rfc-editor.org/rfc/rfc7469.txt RFC 7469] introduced a new HTTP header that allows SSL servers to declare hashes of their certificates with time scope in which these certificates should not be changed. For example:<br />
<br />
<code><br />
Public-Key-Pins: max-age=2592000;<br />
pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";<br />
pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";<br />
report-uri="http://example.com/pkp-report"<br />
</code><br />
<br />
=== Android ===<br />
<br />
Pinning in Android is accomplished through a custom <tt>X509TrustManager</tt>. <tt>X509TrustManager</tt> should perform the customary X509 checks in addition to performing the pin.<br />
<br />
Download: [[Media:pubkey-pin-android.zip|Android sample program]]<br />
<br />
<pre>public final class PubKeyManager implements X509TrustManager<br />
{<br />
private static String PUB_KEY = "30820122300d06092a864886f70d0101" +<br />
"0105000382010f003082010a0282010100b35ea8adaf4cb6db86068a836f3c85" +<br />
"5a545b1f0cc8afb19e38213bac4d55c3f2f19df6dee82ead67f70a990131b6bc" +<br />
"ac1a9116acc883862f00593199df19ce027c8eaaae8e3121f7f329219464e657" +<br />
"2cbf66e8e229eac2992dd795c4f23df0fe72b6ceef457eba0b9029619e0395b8" +<br />
"609851849dd6214589a2ceba4f7a7dcceb7ab2a6b60c27c69317bd7ab2135f50" +<br />
"c6317e5dbfb9d1e55936e4109b7b911450c746fe0d5d07165b6b23ada7700b00" +<br />
"33238c858ad179a82459c4718019c111b4ef7be53e5972e06ca68a112406da38" +<br />
"cf60d2f4fda4d1cd52f1da9fd6104d91a34455cd7b328b02525320a35253147b" +<br />
"e0b7a5bc860966dc84f10d723ce7eed5430203010001";<br />
<br />
public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException<br />
{<br />
if (chain == null) {<br />
throw new IllegalArgumentException("checkServerTrusted: X509Certificate array is null");<br />
}<br />
<br />
if (!(chain.length > 0)) {<br />
throw new IllegalArgumentException("checkServerTrusted: X509Certificate is empty");<br />
}<br />
<br />
if (!(null != authType && authType.equalsIgnoreCase("RSA"))) {<br />
throw new CertificateException("checkServerTrusted: AuthType is not RSA");<br />
}<br />
<br />
// Perform customary SSL/TLS checks<br />
try {<br />
TrustManagerFactory tmf = TrustManagerFactory.getInstance("X509");<br />
tmf.init((KeyStore) null);<br />
<br />
for (TrustManager trustManager : tmf.getTrustManagers()) {<br />
((X509TrustManager) trustManager).checkServerTrusted(chain, authType);<br />
}<br />
} catch (Exception e) {<br />
throw new CertificateException(e);<br />
}<br />
<br />
// Hack ahead: BigInteger and toString(). We know a DER encoded Public Key begins<br />
// with 0x30 (ASN.1 SEQUENCE and CONSTRUCTED), so there is no leading 0x00 to drop.<br />
RSAPublicKey pubkey = (RSAPublicKey) chain[0].getPublicKey();<br />
String encoded = new BigInteger(1 /* positive */, pubkey.getEncoded()).toString(16);<br />
<br />
// Pin it!<br />
final boolean expected = PUB_KEY.equalsIgnoreCase(encoded);<br />
if (!expected) {<br />
throw new CertificateException("checkServerTrusted: Expected public key: "<br />
+ PUB_KEY + ", got public key:" + encoded);<br />
}<br />
}<br />
}<br />
}</pre><br />
<br />
<tt>PubKeyManager</tt> would be used in code similar to below.<br />
<br />
<pre>TrustManager tm[] = { new PubKeyManager() };<br />
<br />
SSLContext context = SSLContext.getInstance("TLS");<br />
context.init(null, tm, null);<br />
<br />
URL url = new URL( "https://www.random.org/integers/?" +<br />
"num=16&min=0&max=255&col=16&base=10&format=plain&rnd=new");<br />
<br />
HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();<br />
connection.setSSLSocketFactory(context.getSocketFactory());<br />
<br />
InputStreamReader instream = new InputStreamReader(connection.getInputStream());<br />
StreamTokenizer tokenizer = new StreamTokenizer(instream);<br />
...</pre><br />
<br />
=== iOS ===<br />
<br />
iOS pinning is performed through a <tt>NSURLConnectionDelegate</tt>. The delegate must implement <tt>connection:canAuthenticateAgainstProtectionSpace:</tt> and <tt>connection:didReceiveAuthenticationChallenge:</tt>. Within <tt>connection:didReceiveAuthenticationChallenge:</tt>, the delegate must call <tt>SecTrustEvaluate</tt> to perform customary X509 checks.<br />
<br />
Download: [[Media:pubkey-pin-ios.zip|iOS sample program]].<br />
<br />
<pre>-(IBAction)fetchButtonTapped:(id)sender<br />
{<br />
NSString* requestString = @"https://www.random.org/integers/?<br />
num=16&min=0&max=255&col=16&base=16&format=plain&rnd=new";<br />
NSURL* requestUrl = [NSURL URLWithString:requestString];<br />
<br />
NSURLRequest* request = [NSURLRequest requestWithURL:requestUrl<br />
cachePolicy:NSURLRequestReloadIgnoringLocalCacheData<br />
timeoutInterval:10.0f];<br />
<br />
NSURLConnection* connection = [[NSURLConnection alloc] initWithRequest:request delegate:self];<br />
}<br />
<br />
-(BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:<br />
(NSURLProtectionSpace*)space<br />
{<br />
return [[space authenticationMethod] isEqualToString: NSURLAuthenticationMethodServerTrust];<br />
}<br />
<br />
- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:<br />
(NSURLAuthenticationChallenge *)challenge<br />
{<br />
if ([[[challenge protectionSpace] authenticationMethod] isEqualToString: NSURLAuthenticationMethodServerTrust])<br />
{<br />
do<br />
{<br />
SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust];<br />
if(nil == serverTrust)<br />
break; /* failed */<br />
<br />
OSStatus status = SecTrustEvaluate(serverTrust, NULL);<br />
if(!(errSecSuccess == status))<br />
break; /* failed */<br />
<br />
SecCertificateRef serverCertificate = SecTrustGetCertificateAtIndex(serverTrust, 0);<br />
if(nil == serverCertificate)<br />
break; /* failed */<br />
<br />
CFDataRef serverCertificateData = SecCertificateCopyData(serverCertificate);<br />
[(id)serverCertificateData autorelease];<br />
if(nil == serverCertificateData)<br />
break; /* failed */<br />
<br />
const UInt8* const data = CFDataGetBytePtr(serverCertificateData);<br />
const CFIndex size = CFDataGetLength(serverCertificateData);<br />
NSData* cert1 = [NSData dataWithBytes:data length:(NSUInteger)size];<br />
<br />
NSString *file = [[NSBundle mainBundle] pathForResource:@"random-org" ofType:@"der"];<br />
NSData* cert2 = [NSData dataWithContentsOfFile:file];<br />
<br />
if(nil == cert1 || nil == cert2)<br />
break; /* failed */<br />
<br />
const BOOL equal = [cert1 isEqualToData:cert2];<br />
if(!equal)<br />
break; /* failed */<br />
<br />
// The only good exit point<br />
return [[challenge sender] useCredential: [NSURLCredential credentialForTrust: serverTrust]<br />
forAuthenticationChallenge: challenge];<br />
} while(0);<br />
<br />
// Bad dog<br />
return [[challenge sender] cancelAuthenticationChallenge: challenge];<br />
}</pre><br />
<br />
=== .Net ===<br />
<br />
.Net pinning can be achieved by using <tt>ServicePointManager</tt> as shown below.<br />
<br />
Download: [[Media:pubkey-pin-dotnet.zip|.Net sample program]].<br />
<br />
<pre>// Encoded RSAPublicKey<br />
private static String PUB_KEY = "30818902818100C4A06B7B52F8D17DC1CCB47362" +<br />
"C64AB799AAE19E245A7559E9CEEC7D8AA4DF07CB0B21FDFD763C63A313A668FE9D764E" +<br />
"D913C51A676788DB62AF624F422C2F112C1316922AA5D37823CD9F43D1FC54513D14B2" +<br />
"9E36991F08A042C42EAAEEE5FE8E2CB10167174A359CEBF6FACC2C9CA933AD403137EE" +<br />
"2C3F4CBED9460129C72B0203010001";<br />
<br />
public static void Main(string[] args)<br />
{<br />
ServicePointManager.ServerCertificateValidationCallback = PinPublicKey;<br />
WebRequest wr = WebRequest.Create("https://encrypted.google.com/");<br />
wr.GetResponse();<br />
}<br />
<br />
public static bool PinPublicKey(object sender, X509Certificate certificate, X509Chain chain,<br />
SslPolicyErrors sslPolicyErrors)<br />
{<br />
if (null == certificate)<br />
return false;<br />
<br />
String pk = certificate.GetPublicKeyString();<br />
if (pk.Equals(PUB_KEY))<br />
return true;<br />
<br />
// Bad dog<br />
return false;<br />
}</pre><br />
<br />
=== OpenSSL ===<br />
<br />
Pinning can occur at one of two places with OpenSSL. First is the user supplied <tt>verify_callback</tt>. Second is after the connection is established via <tt>SSL_get_peer_certificate</tt>. Either method will allow you to access the peer's certificate.<br />
<br />
Though OpenSSL performs the X509 checks, you must fail the connection and tear down the socket on error. By design, a server that does not supply a certificate will result in <tt>X509_V_OK</tt> with a '''NULL''' certificate. To check the result of the customary verification: (1) you must call <tt>SSL_get_verify_result</tt> and verify the return code is <tt>X509_V_OK</tt>; and (2) you must call <tt>SSL_get_peer_certificate</tt> and verify the certificate is '''non-NULL'''.<br />
<br />
Download: [[Media:pubkey-pin-openssl.zip|OpenSSL sample program]].<br />
<br />
<pre>int pkp_pin_peer_pubkey(SSL* ssl)<br />
{<br />
if(NULL == ssl) return FALSE;<br />
<br />
X509* cert = NULL;<br />
FILE* fp = NULL;<br />
<br />
/* Scratch */<br />
int len1 = 0, len2 = 0;<br />
unsigned char *buff1 = NULL, *buff2 = NULL;<br />
<br />
/* Result is returned to caller */<br />
int ret = 0, result = FALSE;<br />
<br />
do<br />
{<br />
/* http://www.openssl.org/docs/ssl/SSL_get_peer_certificate.html */<br />
cert = SSL_get_peer_certificate(ssl);<br />
if(!(cert != NULL))<br />
break; /* failed */<br />
<br />
/* Begin Gyrations to get the subjectPublicKeyInfo */<br />
/* Thanks to Viktor Dukhovni on the OpenSSL mailing list */<br />
<br />
/* http://groups.google.com/group/mailing.openssl.users/browse_thread/thread/d61858dae102c6c7 */<br />
len1 = i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert), NULL);<br />
if(!(len1 > 0))<br />
break; /* failed */<br />
<br />
/* scratch */<br />
unsigned char* temp = NULL;<br />
<br />
/* http://www.openssl.org/docs/crypto/buffer.html */<br />
buff1 = temp = OPENSSL_malloc(len1);<br />
if(!(buff1 != NULL))<br />
break; /* failed */<br />
<br />
/* http://www.openssl.org/docs/crypto/d2i_X509.html */<br />
len2 = i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert), &temp);<br />
<br />
/* These checks are verifying we got back the same values as when we sized the buffer. */<br />
/* Its pretty weak since they should always be the same. But it gives us something to test. */<br />
if(!((len1 == len2) && (temp != NULL) && ((temp - buff1) == len1)))<br />
break; /* failed */<br />
<br />
/* End Gyrations */<br />
<br />
/* See the warning above!!! */<br />
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/fopen.html */<br />
fp = fopen("random-org.der", "rx");<br />
if(NULL ==fp) {<br />
fp = fopen("random-org.der", "r");<br />
<br />
if(!(NULL != fp))<br />
break; /* failed */<br />
<br />
/* Seek to eof to determine the file's size */<br />
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/fseek.html */<br />
ret = fseek(fp, 0, SEEK_END);<br />
if(!(0 == ret))<br />
break; /* failed */<br />
<br />
/* Fetch the file's size */<br />
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/ftell.html */<br />
long size = ftell(fp);<br />
<br />
/* Arbitrary size, but should be relatively small (less than 1K or 2K) */<br />
if(!(size != -1 && size > 0 && size < 2048))<br />
break; /* failed */<br />
<br />
/* Rewind to beginning to perform the read */<br />
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/fseek.html */<br />
ret = fseek(fp, 0, SEEK_SET);<br />
if(!(0 == ret))<br />
break; /* failed */<br />
<br />
/* Re-use buff2 and len2 */<br />
buff2 = NULL; len2 = (int)size;<br />
<br />
/* http://www.openssl.org/docs/crypto/buffer.html */<br />
buff2 = OPENSSL_malloc(len2);<br />
if(!(buff2 != NULL))<br />
break; /* failed */<br />
<br />
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/fread.html */<br />
/* Returns number of elements read, which should be 1 */<br />
ret = (int)fread(buff2, (size_t)len2, 1, fp);<br />
if(!(ret == 1))<br />
break; /* failed */<br />
<br />
/* Re-use size. MIN and MAX macro below... */<br />
size = len1 < len2 ? len1 : len2;<br />
<br />
/*************************/<br />
/***** PAYDIRT *****/<br />
/*************************/<br />
if(len1 != (int)size || len2 != (int)size || 0 != memcmp(buff1, buff2, (size_t)size))<br />
break; /* failed */<br />
<br />
/* The one good exit point */<br />
result = TRUE;<br />
<br />
} while(0);<br />
<br />
if(fp != NULL)<br />
fclose(fp);<br />
<br />
/* http://www.openssl.org/docs/crypto/buffer.html */<br />
if(NULL != buff2)<br />
OPENSSL_free(buff2);<br />
<br />
/* http://www.openssl.org/docs/crypto/buffer.html */<br />
if(NULL != buff1)<br />
OPENSSL_free(buff1);<br />
<br />
/* http://www.openssl.org/docs/crypto/X509_new.html */<br />
if(NULL != cert)<br />
X509_free(cert);<br />
<br />
return result;<br />
}</pre><br />
<br />
== Pinning Alternatives ==<br />
<br />
Not all applications use split key cryptography. Fortunately, there are protocols which allow you to set up a secure channel based on knowledge of passwords and pre-shared secrets (rather than putting the secret on the wire in a basic authentication scheme). Two are listed below - SRP and PSK. SRP and PSK have [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 88 cipher suites assigned to them by IANA for TLS], so there's no shortage of choices.<br />
<br />
{| align="center"<br />
| [[File:pin-iana-assigned.png|thumb|450px|Figure 3: IANA reserved cipher suites for SRP and PSK]]<br />
|}<br />
<br />
=== SRP ===<br />
<br />
Secure Remote Password (SRP) is a Password Authenticated Key Exchange (PAKE) by Thomas Wu based upon Diffie-Hellman. The protocol is standardized in [https://tools.ietf.org/rfc/rfc5054.txt RFC 5054] and available in the OpenSSL library (among others). In the SRP scheme, the server uses a verifier which consists of a <tt>{salt, hash(password)}</tt> pair. The user has the password and receives the salt from the server. With lots of hand waving, both parties select per-instance random values (nonces) and execute the protocol using ''g<sup>{(salt + password)|verifier} + nonces</sup>'' rather than traditional Diffie-Hellman using ''g<sup>ab</sup>''.<br />
<br />
[[File:homer-p-np.jpg|thumb|right|150px|P=NP!!!]]Diffie-Hellman based schemes are part of a family of problems based on Discrete Logs (DL), which are logarithms over a finite field. DL schemes are appealing because they are known to be hard (unless ''P=NP'', which would cause computational number theorists to have a cow).<br />
<br />
<br />
=== PSK ===<br />
<br />
PSK is Pre-Shared Key and specified in [https://tools.ietf.org/rfc/rfc4279.txt RFC 4279] and [https://tools.ietf.org/rfc/rfc4764.txt RFC 4764]. The shared secret is used as a pre-master secret in TLS-PSK for SSL/TLS; or used to key a block cipher in EAP-PSK. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11.<br />
<br />
== Miscellaneous ==<br />
<br />
This sections covers administrivia and miscellaneous items related to pinning.<br />
<br />
=== Ephemeral Keys ===<br />
<br />
Ephemeral keys are temporary keys used for one instance of a protocol execution and then thrown away. An ephemeral key has the benefit of providing forward secrecy, meaning a compromise of the site or service's long term (static) signing key does not facilitate decrypting past messages because the key was temporary and discarded (once the session terminated).<br />
<br />
Ephemeral keys do not affect pinning because the Ephemeral key is delivered in a separate <tt>ServerKeyExchange</tt> message. In addition, the ephemeral key is a key and not a certificate, so it does not change the construction of the certificate chain. That is, the certificate of interest will still be located at <tt>certificates[0]</tt>.<br />
<br />
=== Pinning Gaps ===<br />
<br />
There are two gaps when pinning due to reuse of the existing infrastructure and protocols. First, an explicit challenge is '''not''' sent by the program to the peer server based on the server's public information. So the program never knows if the peer can actually decrypt messages. However, the shortcoming is usually academic in practice since an adversary will receive messages it can't decrypt.<br />
<br />
Second is revocation. Clients don't usually engage in revocation checking, so it could be possible to use a known bad certificate or key in a pinset. Even if revocation is active, Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) can be defeated in a hostile environment. An application can take steps to remediate, with the primary means being freshness. That is, an application should be updated and distributed immediately when a critical security parameter changes.<br />
<br />
=== No Relationship ^@$! ===<br />
<br />
If you don't have a pre-existing relationship, all is not lost. First, you can pin a host or server's certificate or public key the first time you encounter it. If the bad guy was not active when you encountered the certificate or public key, he or she will not be successful with future funny business.<br />
<br />
Second, bad certificates are being spotted quicker in the field due to projects like [http://www.chromium.org Chromium] and [https://addons.mozilla.org/en-us/firefox/addon/certificate-patrol/ Certificate Patrol], and initiatives like the EFF's [https://www.eff.org/observatory SSL Observatory].<br />
<br />
Third, help is on its way, and there are a number of futures that will assist with the endeavors:<br />
<br />
* Public Key Pinning (http://www.ietf.org/id/draft-ietf-websec-key-pinning-09.txt) – an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time.<br />
* DNS-based Authentication of Named Entities (DANE) (https://datatracker.ietf.org/doc/rfc6698/) - uses Secure DNS to associate Certificates with Domain Names For S/MIME, SMTP with TLS, DNSSEC and TLSA records.<br />
* Sovereign Keys (http://www.eff.org/sovereign-keys) - operates by providing an optional and secure way of associating domain names with public keys via DNSSEC. PKI (hierarchical) is still used. Semi-centralized with append only logging.<br />
* Convergence (http://convergence.io) – different [geographical] views of a site and its associated data (certificates and public keys). Web of Trust is used. Semi-centralized.<br />
<br />
While Sovereign Keys and Convergence still require us to confer trust to outside parties, the parties involved do not serve share holders or covet revenue streams. Their interests are industry transparency and user security.<br />
<br />
=== More Information? ===<br />
<br />
Pinning is an ''old new thing'' that has been shaken, stirred, and repackaged. While "pinning" and "pinsets" are relatively new terms for old things, Jon Larimer and Kenny Root spent time on the subject at Google I/O 2012 with their talk ''[https://developers.google.com/events/io/sessions/gooio2012/107/ Security and Privacy in Android Apps]''.<br />
<br />
=== Format Conversions ===<br />
<br />
As a convenience to readers, the following with convert between PEM and DER format using OpenSSL.<br />
<br />
<pre># Public key, X509<br />
$ openssl genrsa -out rsa-openssl.pem 3072<br />
$ openssl rsa -in rsa-openssl.pem -pubout -outform DER -out rsa-openssl.der</pre><br />
<br />
<pre># Private key, PKCS#8<br />
$ openssl genrsa -out rsa-openssl.pem 3072<br />
$ openssl pkcs8 -nocrypt -in rsa-openssl.pem -inform PEM -topk8 -outform DER -out rsa-openssl.der</pre><br />
<br />
== References ==<br />
<br />
* OWASP [[Injection_Theory|Injection Theory]]<br />
* OWASP [[Data_Validation|Data Validation]]<br />
* OWASP [[Transport_Layer_Protection_Cheat_Sheet|Transport Layer Protection Cheat Sheet]]<br />
* IETF [http://www.ietf.org/id/draft-ietf-websec-key-pinning-09.txt Public Key Pinning]<br />
* IETF [http://www.ietf.org/rfc/rfc5054.txt RFC 5054 (SRP)]<br />
* IETF [http://www.ietf.org/rfc/rfc4764.txt RFC 4764 (EAP-PSK)]<br />
* IETF [http://www.ietf.org/rfc/rfc1421.txt RFC 1421 (PEM Encoding)]<br />
* IETF [http://www.ietf.org/rfc/rfc5280.txt RFC 5280 (Internet X.509, PKIX)]<br />
* IETF [http://www.ietf.org/rfc/rfc4648.txt RFC 4648 (Base16, Base32, and Base64 Encodings)]<br />
* IETF [http://www.ietf.org/rfc/rfc3279.txt RFC 3279 (PKI, X509 Algorithms and CRL Profiles)]<br />
* IETF [http://www.ietf.org/rfc/rfc4055.txt RFC 4055 (PKI, X509 Additional Algorithms and CRL Profiles)]<br />
* IETF [http://www.ietf.org/rfc/rfc2246.txt RFC 2246 (TLS 1.0)]<br />
* IETF [http://www.ietf.org/rfc/rfc4346.txt RFC 4346 (TLS 1.1)]<br />
* IETF [http://www.ietf.org/rfc/rfc5246.txt RFC 5246 (TLS 1.2)]<br />
* IETF [http://www.ietf.org/rfc/rfc6698.txt RFC 6698, Draft (DANE)]<br />
* EFF [http://www.eff.org/sovereign-keys Sovereign Keys]<br />
* Thoughtcrime Labs [http://convergence.io/ Convergence]<br />
* RSA Laboratories [http://www.rsa.com/rsalabs/node.asp?id=2125 PKCS#1, RSA Encryption Standard]<br />
* RSA Laboratories [http://www.rsa.com/rsalabs/node.asp?id=2128 PKCS#6, Extended-Certificate Syntax Standard]<br />
* ITU [http://www.itu.int/rec/T-REC-X.690-200811-I/en Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)]<br />
* TOR Project [https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion Detecting Certificate Authority Compromises and Web Browser Collusion]<br />
* Code Project [http://www.codeproject.com/Articles/25487/Cryptographic-Interoperability-Keys Cryptographic Interoperability: Keys]<br />
* Google I/O [https://developers.google.com/events/io/sessions/gooio2012/107/ Security and Privacy in Android Apps]<br />
* Trevor Perrin [https://crypto.stanford.edu/RealWorldCrypto/slides/perrin.pdf Transparency, Trust Agility, Pinning (Recent Developments in Server Authentication)]<br />
* Dr. Peter Gutmann's [http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf PKI is Broken]<br />
* Dr. Matthew Green's [http://blog.cryptographyengineering.com/2012/02/how-to-fix-internet.html The Internet is Broken]<br />
* Dr. Matthew Green's [http://blog.cryptographyengineering.com/2012/03/how-do-interception-proxies-fail.html How do Interception Proxies fail?]<br />
<br />
= Authors and Primary Editors =<br />
<br />
* Jeffrey Walton - jeffrey, owasp.org<br />
* JohnSteven - john, owasp.org<br />
* Jim Manico - jim, owasp.org<br />
* Kevin Wall - kevin, owasp.org<br />
<br />
[[Category:Control]]</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Test_Upload_of_Malicious_Files_(OTG-BUSLOGIC-009)&diff=192174Test Upload of Malicious Files (OTG-BUSLOGIC-009)2015-03-25T15:40:10Z<p>Pawel Krawczyk: /* How to Test */ EICAR anti-malware test file</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
== Summary ==<br />
<br />
Many application’s business processes allow for the upload of data/information. We regularly check the validity and security of text but accepting files can introduce even more risk. To reduce the risk we may only accept certain file extensions, but attackers are able to encapsulate malicious code into inert file types. Testing for malicious files verifies that the application/system is able to correctly protect against attackers uploading malicious files. <br />
<br />
<br />
Vulnerabilities related to the uploading of malicious files is unique in that these “malicious” files can easily be rejected through including business logic that will scan files during the upload process and reject those perceived as malicious. Additionally, this is different from uploading unexpected files in that while the file type may be accepted the file may still be malicious to the system.<br />
<br />
<br />
Finally, "malicious" means different things to different systems, for example Malicious files that may exploit SQL server vulnerabilities may not be considered a "malicious" to a main frame flat file environment. <br />
<br />
<br />
The application may allow the upload of malicious files that include exploits or shellcode without submitting them to malicious file scanning. Malicious files could be detected and stopped at various points of the application architecture such as: IPS/IDS, application server anti-virus software or anti-virus scanning by application as files are uploaded (perhaps offloading the scanning using SCAP).<br />
<br />
<br />
== Example ==<br />
<br />
Suppose a picture sharing application allows users to upload their .gif or .jpg graphic files to the web site. What if an attacker is able to upload a PHP shell, or exe file, or virus? The attacker may then upload the file that may be saved on the system and the virus may spread itself or through remote processes exes or shell code can be executed. <br />
<br />
<br />
== How to Test==<br />
<br />
Generic Testing Method<br />
<br />
• Review the project documentation and use exploratory testing looking at the application/system to identify what constitutes and "malicious" file in your environment. <br />
<br />
• Develop or acquire a known “malicious” file. An [http://www.eicar.org/85-0-Download.html EICAR anti-malware test file] can be used as harmless, but widely detected by antivirus software.<br />
<br />
• Try to upload the malicious file to the application/system and verify that it is correctly rejected. <br />
<br />
• If multiple files can be uploaded at once, there must be tests in place to verify that each file is properly evaluated. <br />
<br />
<br />
Specific Testing Method 1<br />
<br />
• Using the Metasploit payload generation functionality generates a shellcode as a Windows executable using the Metasploit "msfpayload" command.<br />
<br />
• Submit the executable via the application’s upload functionality and see if it is accepted or properly rejected.<br />
<br />
<br />
Specific Testing Method 2<br />
<br />
• Develop or create a file that should fail the application malware detection process. There are many available on the Internet such as ducklin.htm or ducklin-html.htm. <br />
<br />
• Submit the executable via the application’s upload functionality and see if it is accepted or properly rejected.<br />
<br />
<br />
Specific Testing Method 3<br />
<br />
• Set up the intercepting proxy to capture the “valid” request for an accepted file.<br />
<br />
• Send an “invalid” request through with a valid/acceptable file extension and see if the request is accepted or properly rejected.<br />
<br />
== Related Test Cases ==<br />
<br />
[[Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)| Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]] <br />
<br />
[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)| Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]] <br />
<br />
<br />
== Tools ==<br />
<br />
• Metasploit's payload generation functionality <br />
<br />
• Intercepting proxy<br />
<br />
<br />
== References == <br />
<br />
OWASP - Unrestricted File Upload - https://www.owasp.org/index.php/Unrestricted_File_Upload<br />
<br />
Why File Upload Forms are a Major Security Threat - http://www.acunetix.com/websitesecurity/upload-forms-threat/<br />
<br />
File upload security best practices: Block a malicious file upload - http://www.computerweekly.com/answer/File-upload-security-best-practices-Block-a-malicious-file-upload<br />
<br />
Overview of Malicious File Upload Attacks - http://securitymecca.com/article/overview-of-malicious-file-upload-attacks/<br />
<br />
Stop people uploading malicious PHP files via forms - http://stackoverflow.com/questions/602539/stop-people-uploading-malicious-php-files-via-forms<br />
<br />
How to Tell if a File is Malicious - http://www.techsupportalert.com/content/how-tell-if-file-malicious.htm<br />
<br />
CWE-434: Unrestricted Upload of File with Dangerous Type - http://cwe.mitre.org/data/definitions/434.html<br />
<br />
Implementing Secure File Upload - http://infosecauditor.wordpress.com/tag/malicious-file-upload/<br />
<br />
Watchful File Upload - http://palizine.plynt.com/issues/2011Apr/file-upload/<br />
<br />
Matasploit Generating Payloads - http://www.offensive-security.com/metasploit-unleashed/Generating_Payloads<br />
<br />
Project Shellcode – Shellcode Tutorial 9: Generating Shellcode Using Metasploit<br />
http://www.projectshellcode.com/?q=node/29<br />
<br />
Anti-Malware Test file - http://www.eicar.org/86-0-Intended-use.html<br />
<br />
<br />
== Remediation ==<br />
<br />
While safeguards such as black or white listing of file extensions, using “Content-Type” from the header, or using a file type recognizer may not always be protections against this type of vulnerability. Every application that accepts files from users must have a mechanism to verify that the uploaded file does not contain malicious code. Uploaded files should never be stored where the users or attackers can directly access them.</div>Pawel Krawczykhttps://wiki.owasp.org/index.php?title=Category:OWASP_Speakers_Project&diff=189214Category:OWASP Speakers Project2015-02-09T13:40:29Z<p>Pawel Krawczyk: Pawel Krawczyk</p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Speakers Project==<br />
<br />
OWASP Speakers Project is...<br />
<br />
==Introduction==<br />
<br />
This program helps local chapters or application security conferences to find OWASP related speakers to have OWASP presenters on site.<br />
<br />
<br />
<br />
==Description==<br />
<br />
This program allows two parties to find each other:<br />
*Local chapters or application security events that want to attract an OWASP speaker.<br />
*OWASP speakers to entertain OWASP presentations and that want to see the world.<br />
<br />
For sponsorship, see the [[:Category:OWASP_on_the_Move_Project|OWASP on the Move Project]] page<br />
<br />
<br />
==Licensing==<br />
OWASP XXX is free to use. It is 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.<br />
<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
== What is OWASP Speakers Project? ==<br />
<br />
OWASP Speakers Project provides:<br />
*OWASP related speakers for local chapter and conferences.<br />
<br />
== Presentation ==<br />
<br />
== Project Leader ==<br />
[mailto:Martin.knoblock@owasp.org Martin Knobloch]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
<br />
<br />
== News and Events ==<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| 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]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
<br />
= Available Speakers =<br />
If you want to (re)do an OWASP related presentation, propose them here with your availability boundaries (timing/geographical) <br />
<br />
*Add your name, contact and bio information to become available as OWASP Speaker!<br />
{| class="prettytable"<br />
|-<br />
! Name <br />
! Introduction <br />
! Available Area <br />
! Bios<br />
|-<br />
| [mailto:Robert(at)ZakonGroup.com Robert H'obbes' Zakon] <br />
| Presenter on Web Application Security, OWASP Top 10, PHP Security, and assorted other topics. Training sessions taught at events such as [http://www.zakongroup.com/technology/services-training.shtml OWASP, ACSAC, and CCS]. Based in New Hampshire, and available for travel worldwide. Fluent in English, and able to converse in Portuguese. A developer and consultant for the past decade, formerly a Principal Engineer with MITRE's InfoSec Group. <br />
| Global (USA/NH-based) <br />
| [http://www.zakon.org/robert/vitae.html BIO]<br />
|-<br />
| [mailto:jmcgovern@virtusa.com James McGovern] <br />
| Presenter on Enterprise Architecture and Web Application Security, SOA Web Services Security and Federated Identity. <br />
| Global (USA/CT-based) <br />
| [http://www.linkedin.com/in/jamesmcgovern BIO]<br />
|-<br />
| [mailto:chuck(at)McCulloughAssociates.com Chuck McCullough] <br />
| Chuck provides training sessions to developers on the Top 10. Chuck welcomes speaking opportunities to any group. Chuck is available in the Texas area and at various other locations in the USA. <br />
| USA/Texas <br />
| [http://www.linkedin.com/in/chuckmccullough BIO]<br />
|-<br />
| Marc Curphey <br />
| Marc will happily speak about the WebAppSec industry, SDLC etc. around Europe. You can see him in action at [http://video.hitb.org/2006.html HITB with John Viega] (big download) <br />
| Europe <br />
| [http://www.linkedin.com/in/curphey BIO]<br />
|-<br />
| [mailto:tomb@proactiverisk.com Tom Brennan] <br />
| Tom is based in Northern New Jersey and leads the NYC Metro Chapters of OWASP Foundation since 2004. Tom served the community for (7) years as a member of the Global Board of Directors (2007-2014) and as a active project contributor. Tom is available for events worldwide to educate audiences about the OWASP Foundation core mission, how it works and various projects related to software security. He has a background as a Builder, Breaker and Defender [https://www.owasp.org/index.php/User:Brennan BIO]<br />
| Global <br />
| [http://www.linkedin.com/in/tombrennan BIO]<br />
|-<br />
| [mailto:thesp0nge@owasp.org Paolo Perego] <br />
| Paolo is available to talk about [http://www.owasp.org/index.php/Category:OWASP_Orizon_Project Orizon project], safe coding and code review issues around Europe in the near October-December. <br />
| Europe <br />
| [http://www.linkedin.com/in/thesp0nge BIO]<br />
|-<br />
| [mailto:marc.m.morana@gmail.org Marco Morana] <br />
| Marco is available to talk about [http://iac.dtic.mil/iatac/download/security.pdf Software Security Frameworks]and Secure Code Reviews [https://www.cmpevents.com/CSI33/a.asp?option=G&V=3&id=443342 see 07 CSI conference as reference] in USA around November-December and in Europe around January-February <br />
| Europe <br />
| [http://www.linkedin.com/pub/2/a7a/59b BIO]<br />
|-<br />
|-<br />
| [mailto:amro@owasp.org Amro Alolaqi] <br />
| Amro is leading the OWASP Saudi Arabia and UAE chapters, futhermore a contributor for the OWASP Testing Guide v4, OWASP Zed Attack Proxy (ZAP) and OWASP Web Application Security Testing Cheat Sheet. He is a frequent speaker at various industry conferences and events; topics of interest include Web App Critical Vulnerabilities, OWASP Zed Attack Proxy (ZAP), OWASP Testing Guide, Web Application Security Testing and Threat Modeling.<br />
| Global (Middle East-based)<br />
| [https://www.owasp.org/index.php/User:Amro_Ahmed BIO]<br />
|-<br />
| [mailto:sebastien.gioria@owasp.fr Sébastien Gioria] <br />
| Sebastien is available to talk about WebAppSec, educational purpose on AppSec in French or at least in english around France/Europe/Canada from middle of March 08. You can find some Talk on the [http://www.owasp.fr Owasp France Chapter] <br />
| France/Europe/Canada <br />
| [http://www.linkedin.com/in/gioria BIO]<br />
|-<br />
| [mailto:mordecai.kraushar@owasp.org Mordecai Kraushar] <br />
| Mordecai is available to talk about different topics within the Web application security space. Discussions typically involve either the Broken Web Application project or the Vicnum project, [http://www.owasp.org/index.php/Category:OWASP_Vicnum_Project], a flexible vulnerable web application that can be used in many scenarios including 'capture the flag' exercises. <br />
| Global <br />
| [http://www.linkedin.com/in/mkraushar BIO]<br />
|-<br />
| [mailto:michael.coates@owasp.org Michael Coates] <br />
| Michael is available to talk on a variety of web application security topics. Talks are interactive and include live demos and code examples. Michael has spoken at multiple OWASP conferences and University security courses on topics such as Introduction to Application Security, Automated Defense Systems in Applications, Real Time Detection and Prevention of Application Worms, and security risks in SSL/TLS. <br />
| USA/San Francisco & Virtual Presentations<br />
| [http://www.linkedin.com/in/mcoates BIO]<br />
|-<br />
| [mailto:tobias.gondrom@owasp.org Tobias Gondrom] <br />
| Tobias is on the London chapter board (and previously Germany chapter lead) and currently member of the OWASP Global Industry committee. He is available to talk on a variety of web application and information security and risk management topics. He gives two different types of presentations - preferred in Asia or Europe: <br>- CISO level: information security, risk management from Secure SDLCs, maturity models, standards and security strategy, to change management and managing application security in large organisations and the OWASP CISO Guide. <br>- Deep technical talks: new security standards and research, involving his work in web security research and as the chair of the web security working group at the IETF. Tobias has spoken at multiple OWASP AppSec and other security conferences, given university guest lectures and full training days on topics like CISO training, browser security, web security, new technologies for channel protection with SSL/TLS, electronic signatures, ...<br />
| Asia and Europe <br>(dual based in both regions)<br />
| [http://uk.linkedin.com/in/gondrom BIO]<br />
|-<br />
| [mailto:dan.cornell@owasp.org Dan Cornell] <br />
| Dan Cornell has over twelve years of experience architecting, developing and securing web-based software systems. He speaks on a variety of software development and software security topics such as Vulnerability Management, Software Security Remediation, and Code Review/Static Analysis. Dan is based in San Antonio, TX and available to fly/drive as needed to the site. <br />
| USA/San Antonio <br />
| [http://www.denimgroup.com/about_team_dan.html BIO]<br />
|-<br />
| [mailto:John.Steven@owasp.org John Steven] <br />
| John speaks on a variety of topics including "How to build your own application security group", "Threat Modeling", "Code Review and Static analysis", as well as other topics. John has spoken at and given tutorials for multiple OWASP conferences. John frequents New York, Boston, Washington DC, and Charlotte, but is available for travel elsewhere. <br />
| Washington, DC/USA <br />
| [http://www.cigital.com/about/team/management.php#jsteven BIO]<br />
|-<br />
| [mailto:blake@owasp.org Blake Cornell] <br />
| Blake is available to speak regarding topics including Security v. HIPPA, Penetration Testing Methodologies, Fuzzing and Blended Threats such as attacking VoIP with the OWASP Top 10. Blake lives in the NY Metro area and is available for speaking at regional, national and world wide events. <br />
| New York, NY/USA <br />
| [http://www.linkedin.com/in/blakecornell BIO]<br />
|-<br />
| [mailto:Nick.Coblentz@gmail.com Nick Coblentz] <br />
| Nick regularly performs research related to secure software development. He is available to present on topics such as the [http://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model Software Assurance Maturity Model (SAMM)], the [http://nickcoblentz.blogspot.com/2009/06/samm-inteview-template-version-10.html SAMM Interview Template], [http://nickcoblentz.blogspot.com/2009/05/issa-journal-web-application-security.html Building Web Application Security Portfolios], and [http://nickcoblentz.blogspot.com/2009/11/owasp-presentation-on-dec-10-microsoft.html The Microsoft SDL for Agile Development]. Please email Nick if you see articles on his [http://nickcoblentz.blogspot.com/ blog] that you would like him to present. <br />
| USA/Kansas, Oklahoma, Missouri <br />
| [http://www.linkedin.com/in/ncoblentz BIO]<br />
|-<br />
| [mailto:johnccr@yahoo.com Juan Carlos Calderon] <br />
| Juan has being part of the Appliction Security industry for 9 years, currently performs research on application and information security arena. He is available to present "Preparing an strategy for application vulnerability detection", "Owasp Spanish and Internationalization" and "Análisis y efectos del cibercrimen en Mexico"(Analysis and effects of cibercrime in México). He is also open to talk about other topics related to OWASP materials and tools, send him a note to verify the coverage. <br />
| Aguascalientes/México <br />
| [http://www.linkedin.com/in/juancarloscalderon BIO]<br />
|-<br />
| [mailto:edward@owasp.org Edward Bonver] <br />
| Edward has over a decade of experience in the software security field. He currently works for Symantec's Product Security Team, where he brings all aspects of secure software development to product teams across the company. He is a frequent speaker at various industry conferences and OWASP events; topics of interest include Threat Modeling and Security Testing.<br />
| Global(USA/Los Angeles-based)<br />
| [http://www.linkedin.com/in/bonver BIO]<br />
|-<br />
| [mailto:ludovic.petit@owasp.org Ludovic Petit] <br />
| Chapter Leader OWASP France and OWASP Global Connections Committee Member, [https://www.owasp.org/index.php/User:Ludovic_Petit '''Ludovic'''] is living in Paris and is willing to talk about Web Application Security topics with a Corporate dimension, including about Legal and Law Enforcement, the OWASP Foundation approach, and explain why WebApp Security is also linked to Legal and Regulatory aspects, so Corporate responsibility, to protect your business.<br />
| France, Europe and elsewhere, according to my availabilities and if you pay yourself the travel and accommodation expenses.<br />
| [http://www.linkedin.com/in/lpetit BIO]<br />
|-<br />
| [mailto:magno.logan@owasp.org Magno Logan] <br />
| OWASP Paraiba Chapter Leader and OWASP Portuguese Language Project Member. Magno (Logan) Rodrigues has an MBA in Information Security and studied Computer Forensics for one year in New York. He has done many talks about OWASP and it's main projects at national and international events such as [http://www.ensol.org.br/ ENSOL], [http://gts.nic.br/ GTS] and [https://www.owasp.org/index.php/AppSecLatam2011 App Sec Latam 2011]. Topics of interest include: OWASP Top 10, WebGoat, Java Security, E-commerce Security and Computer Forensics.<br />
<br />
| Latin America<br />
| [https://www.owasp.org/index.php/User:Magno_Logan BIO]<br />
|-<br />
| [mailto:wagner.elias@owasp.org Wagner Elias] <br />
| Wagner founded the Brazil chapter is currently Curitiba-Brazil Chapter Leader and available to talk on a variety of web application security topics. Talks are interactive and include live demos and code examples. Wagner has spoken at various conferences in Brazil.<br />
<br />
Topics of interest: Mobile Security; SDL Process and Implementation; Code Review and Application Test<br />
<br />
| Brazil<br />
| [https://www.owasp.org/index.php/User:wagner.elias BIO]<br />
|-<br />
| [mailto:ramiro.pulgar@owasp.org Ramiro Pulgar] <br />
| Chapter Leader OWASP Ecuador. [https://www.owasp.org/index.php/User:Ramiro_Pulgar '''milovisho'''] OWASP Ecuador Chapter Leader <br />
| Ecuador, Latin America, Global<br />
| [http://ec.linkedin.com/in/ramiropulgar BIO]<br />
|-<br />
| [mailto:john.vargas@owasp.org John Vargas] <br />
| Chapter Leader OWASP Perú. [https://www.owasp.org/index.php/User:Jvargas '''John Vargas'''] OWASP Perú Chapter Leader <br />
| Perú, Latin America, Global<br />
| [http://pe.linkedin.com/in/jvargasp BIO]<br />
|-<br />
|[mailto:Ahmed.neil@owasp.org Ahmed M Neil] <br />
|Neil is available to speak regarding topics including Digital forensics,Wep Application threats and security, Medical Information System Security, Wep application Penetration Testing,Always like to discuss OWASP Top 10. I am in Mansoura, Egypt now and available for speaking at regional,and world wide events. <br />
[https://www.owasp.org/index.php/User:Ahmed_M_Neil '''Ahmed Neil'''] OWASP Mansoura Chapter Leader <br />
| Africa,Global<br />
| [http://www.linkedin.com/pub/ahmed-m-neil/38/590/73 BIO]<br />
|-<br />
|[mailto:pawel.krawczyk@owasp.org Pawel Krawczyk] <br />
|Former chapter leader of OWASP Poland, speaking on hundreds of conferences and OWASP meetings. Topics: application security management, large scale vulnerability assessment, developing secure coding standards in agile environments,<br />
|Europe, Global<br />
|[https://uk.linkedin.com/in/pawelkrawczyk/ BIO]<br />
|}<br />
<br />
= Road Map and Getting Involved =<br />
If you want to (re)do an OWASP related presentation, propose them here with your availability boundaries (timing/geographical) <br />
<br />
*Add your name, contact and bio information to become available as OWASP Speaker!<br />
<br />
=Project About=<br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]</div>Pawel Krawczyk