OWASP - User contributions [en]

Talk:Choosing and Using Security Questions Cheat Sheet

2018-07-08T13:47:47Z

Douglasheld: /* Security questions: dubious value */ added my sig

The "Choosing and Using" part of the title read quite awkwardly the first couple times i saw this link. Consider renaming this cheat sheet to just "Security Questions Cheat Sheet". [[User:Gabe Friedmann|Gabe Friedmann]] 17:24, 15 October 2012 (UTC)

== Security questions: dubious value ==

Security Questions should go the way of the dodo. What is the point of subverting a strong password with more easily guessed security questions? If SQ were stronger, they would form a better primary login factor. But, they are not.
[[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 08:47, 8 July 2018 (CDT)

Talk:Choosing and Using Security Questions Cheat Sheet

2018-07-08T13:47:30Z

Douglasheld: /* Security questions: dubious value */ new section

Talk:Credential Stuffing Prevention Cheat Sheet

2018-07-08T13:45:02Z

Douglasheld: add bad passwords check

The prerequisites to Credential Stuffing are to have a likely list of usernames or a particular username you would like to attack. Also, a list of most common passwords or an algorithm to try random passwords without repeating a password for a particular username.

Some mitigations that aren't mentioned here are:

1. Try to reduce the ease of obtaining a list of authorized users
* Make no different response from a login attempt to an existing vs. nonexistent account
* this includes making no distinction to the response when an existing account is locked out

2. Reject commonly used or already breached passwords. If your users propose these, force them to use a better password. See https://haveibeenpwned.com/Passwords

3. Consider lockout mechanisms additionally from an identified source, and also to an identified target. So for instance, lock out an account after X failed login attempts; but also perhaps lock or throttle logins on an entire tenancy or an entire region if the failed logins per time break above a threshold value. Under a credential stuffing attack, if you were to return 50% of login requests with 503 Unavailable, then a legitimate user has a 50% chance of getting in on the first try, while the attacker's goal will be stretched to twice of its former effort estimate.

4. Captchas can be a very useful throttling technique.

5. If your application is sensitive to performance, consider segregating your operational environment between login activities and logged in activities. This way, users already logged in successfully can continue to use the application at full performance, while the segregated area dedicated to logins may have to start rejecting requests when it is under attack. Also, segregated resources allow you to more easily incorporate performance-hitting security features like harder working password hashes, or delayed responses by sleeping threads a while to confound various timing attacks.

[[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 08:40, 8 July 2018 (CDT)

Talk:Credential Stuffing Prevention Cheat Sheet

2018-07-08T13:42:13Z

Douglasheld: formatting

The prerequisites to Credential Stuffing are to have a likely list of usernames or a particular username you would like to attack. Also, a list of most common passwords or an algorithm to try random passwords without repeating a password for a particular username.

Some mitigations that aren't mentioned here are:

1. Try to reduce the ease of obtaining a list of authorized users
* Make no different response from a login attempt to an existing vs. nonexistent account
* this includes making no distinction to the response when an existing account is locked out

2. Consider lockout mechanisms additionally from an identified source, and also to an identified target. So for instance, lock out an account after X failed login attempts; but also perhaps lock or throttle logins on an entire tenancy or an entire region if the failed logins per time break above a threshold value. Under a credential stuffing attack, if you were to return 50% of login requests with 503 Unavailable, then a legitimate user has a 50% chance of getting in on the first try, while the attacker's goal will be stretched to twice of its former effort estimate.

3. Captchas can be a very useful throttling technique.

4. If your application is sensitive to performance, consider segregating your operational environment between login activities and logged in activities. This way, users already logged in successfully can continue to use the application at full performance, while the segregated area dedicated to logins may have to start rejecting requests when it is under attack. Also, segregated resources allow you to more easily incorporate performance-hitting security features like harder working password hashes, or delayed responses by sleeping threads a while to confound various timing attacks.

[[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 08:40, 8 July 2018 (CDT)

Talk:Credential Stuffing Prevention Cheat Sheet

2018-07-08T13:40:53Z

Douglasheld: Some further ideas not expressed in the article

The prerequisites to Credential Stuffing are to have a likely list of usernames or a particular username you would like to attack. Also, a list of most common passwords or an algorithm to try random passwords without repeating a password for a particular username.

Some mitigations that aren't mentioned here are:
1. Try to reduce the ease of obtaining a list of authorized users
- Make no different response from a login attempt to an existing vs. nonexistent account
-- this includes making no distinction to the response when an existing account is locked out
2. Consider lockout mechanisms additionally from an identified source, and also to an identified target. So for instance, lock out an account after X failed login attempts; but also perhaps lock or throttle logins on an entire tenancy or an entire region if the failed logins per time break above a threshold value. Under a credential stuffing attack, if you were to return 50% of login requests with 503 Unavailable, then a legitimate user has a 50% chance of getting in on the first try, while the attacker's goal will be stretched to twice of its former effort estimate.
3. Captchas can be a very useful throttling technique.
4. If your application is sensitive to performance, consider segregating your operational environment between login activities and logged in activities. This way, users already logged in successfully can continue to use the application at full performance, while the segregated area dedicated to logins may have to start rejecting requests when it is under attack. Also, segregated resources allow you to more easily incorporate performance-hitting security features like harder working password hashes, or delayed responses by sleeping threads a while to confound various timing attacks.
[[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 08:40, 8 July 2018 (CDT)

Membership/members

2016-10-24T14:11:41Z

Douglasheld: /* Join The Mission */ whitespace formatting

='''Join The Mission'''=

 
The professional association of OWASP Foundation is a not-for-profit 501c3 charitable organization not associated with any commercial product or service. OWASP is an open source project dedicated to finding and fighting the causes of insecure software to be successful we need your support. OWASP individuals, supporting educational and commercial organization form an application security community that works together to create articles, methodologies, documentation, tools, and technologies (“OWASP Materials”)
 
 
With your annual donation of $50usd Individual OR $5000usd Corporate your donation enables the ongoing support of OWASP [http://www.owasp.org/index.php/Category:OWASP_Project projects], [https://lists.owasp.org/mailman/listinfo mailing lists], [http://www.owasp.org/index.php/Category:OWASP_AppSec_Conference conferences], [http://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Shows podcasts]. [http://www.owasp.org/index.php/Funds_available_for_OWASP_Projects grants] and [https://www.owasp.org/index.php/Global_Committee_Pages global steering activities].
 
 
For more detailed information on the value of Membership [https://www.owasp.org/index.php/Membership Click Here!] 
 
<center>
[https://www.owasp.org/index.php/Membership https://www.owasp.org/images/9/9d/Register_now.gif]
</center>

Membership/members

2016-10-24T14:11:09Z

Douglasheld: Removed section with all of the bad information

='''Join The Mission'''=

 
The professional association of OWASP Foundation is a not-for-profit 501c3 charitable organization not associated with any commercial product or service. OWASP is an open source project dedicated to finding and fighting the causes of insecure software to be successful we need your support. OWASP individuals, supporting educational and commercial organization form an application security community that works together to create articles, methodologies, documentation, tools, and technologies (“OWASP Materials”)
 
With your annual donation of $50usd Individual OR $5000usd Corporate your donation enables the ongoing support of OWASP [http://www.owasp.org/index.php/Category:OWASP_Project projects], [https://lists.owasp.org/mailman/listinfo mailing lists], [http://www.owasp.org/index.php/Category:OWASP_AppSec_Conference conferences], [http://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Shows podcasts]. [http://www.owasp.org/index.php/Funds_available_for_OWASP_Projects grants] and [https://www.owasp.org/index.php/Global_Committee_Pages global steering activities].
 
 
For more detailed information on the value of Membership [https://www.owasp.org/index.php/Membership Click Here!] 
 
 
<center>
[https://www.owasp.org/index.php/Membership https://www.owasp.org/images/9/9d/Register_now.gif]
</center>

Talk:Membership/members

2016-10-24T13:53:34Z

Douglasheld: /* Page is completely inaccurate */ new section

No members are listed. Are there really no paid-up-to-date individual members, or is something wrong with the page? -[[User:Mchalmers|Matt]] 01:12, 28 July 2008 (EDT)

== Page is completely inaccurate ==

The page has not been updated since 2011. Membership appears to be kept now in Salesforce.com although there is also a public Google Sheets document referenced elsewhere.

The links in this page are essentially dead. I am going to delete the whole page.

Talk:Certificate and Public Key Pinning

2016-07-13T15:07:21Z

Douglasheld: /* Best practices when running traffic through a CDN */ new section

== June 21 2016 Comments ==

Hi Jeffrey and John,

I am from PKI project team at Symantec, and am reading your OWASP guide about certificate pinning and have a question on this point: what to pin?

https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

In certificate paragraph, it implies that it should be the server’s certificate, not its issuer.

"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. “

The sample code, e.g. Android, however, all use an ICA [from [[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 10:05, 13 July 2016 (CDT): "Intermediate Certificate Authority"] to pin. I believe pinning ICA is a good balance of flexibility. Is the guide intention to suggest pinning of CA or the server host’s certificate? Thanks,

Ming

== Past Failures ==

This section is 'further reading' for those interested in surveying the landscape.

* Governments Want/Require Interception
** Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL, cryptome.org/ssl-mitm.pdf
** http://www.dailymail.co.uk/indiahome/indianews/article-2126277/No-secrets-Blackberry-Security-services-intercept-data-government-gets-way-messenger-service.html
* Governments Engage in Interception
** http://www.thetechherald.com/articles/Tunisian-government-harvesting-usernames-and-passwords/12429/
* Vendors Provide Interception Taps
** http://www.cisco.com/web/about/security/intelligence/LI-3GPP.html
* Governments Use Interception Taps
** https://www.eff.org/nsa-spying
* Mobile Interception is Patented
** Lawful interception for targets in a proxy mobile internet protocol network, http://www.google.com/patents/EP2332309A1
* Handset manufactures add trusted roots
** http://gaurangkp.wordpress.com/tag/nokias-man-in-the-middle-attack/
* Carriers can add trusted roots
** No reference yet, but http://www.theregister.co.uk/2011/12/15/carrier_iq_privacy_latest/
* CAs can become compromised
** http://isc.sans.edu/diary.html?storyid=11500
* Researchers created Rogue CAs
** http://www.win.tue.nl/hashclash/rogue-ca/
* Researchers collided certificates on existing CA certificates
** http://www.win.tue.nl/~bdeweger/CollidingCertificates/ddl-full.pdf
* DNS can become compromised
** http://forums.theregister.co.uk/forum/2/2011/09/05/dns_hijack_service_updated/
* Physical plant can become compromised
** http://www.pcworld.com/article/119851/paris_hilton_victim_of_tmobiles_web_flaws.html
* Its easy to set up an AP or Base Station (Chris Paget's IMSI Catcher)
** http://www.wired.com/threatlevel/2010/07/intercepting-cell-phone-calls/
* Can't trust some CAs – they will sell you out and issue subordinate CAs for money
** http://www.net-security.org/secworld.php?id=12369
** http://www.zdnet.com/trustwave-sold-root-certificate-for-surveillance-3040095011/
* Can't trust some browsers – they will sell you out and elide their responsibility
** https://bugzilla.mozilla.org/show_bug.cgi?id=724929
* Can't trust some browsers – they include questionable certificates out of the box
** https://bugzilla.mozilla.org/show_bug.cgi?id=542689
* Can't override some browser's CA list
** http://my.opera.com/community/forums/topic.dml?id=1580452
* Can't override OS's CA list (burned into ROM)
** http://support.google.com/android/bin/answer.py?hl=en&answer=1649774
* CRL/OCSP does not work as expected/intended
** http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern-browsers.html
** https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion
* User will break it too (not just bad guys)
** http://www.esecurityplanet.com/mobile-security/hacker-bypasses-apples-ios-in-app-purchases.html
** http://www.h-online.com/security/news/item/Apps-for-Windows-8-easily-hacked-1767839.html
* Interception proxies add additional risk
** http://blog.cryptographyengineering.com/2012/03/how-do-interception-proxies-fail.html
* HTTPS is broken
** http://www.thoughtcrime.org/software/sslstrip/
* PKI is broken
** www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
* The Internet is Broken :)
** http://blog.cryptographyengineering.com/2012/02/how-to-fix-internet.html

== Operational considerations ==

We use certificate pinning very commonly in my organization (yay for us) but we recently hit a problem when we were routinely changing a certificate on a service. The development team for one of the client applications and implemented pinning, but they had not considered what would happen when the certificate changed.

The majority of our clients support 2 pinned certificates at a time, so when we want to change the server cert the process is

1) Configure the new server cert in the client alongside the old one
2) Replace the old cert on the server
3) Configure the old cert from the client

This way we can do the cert rotation usually with no downtime for the client.

The team in question did not do this, which meant they had to have a few minutes of downtime (this is important as we have a demanding SLA) and also it meant that we had to do the change out of office hours to minimize the impact.

So, my suggestion is that we expand this page to include a section on "Operational considerations" that outlines the recommended approach.

Thoughts?

If no-one objects, I will add the new section in a couple of days.

[[User:Michael Goodwin|Michael Goodwin]] ([[User talk:Michael Goodwin|talk]]) 06:20, 2 April 2015 (CDT)

(I am not sure how to reply to your question so I will do it inline. Let me know the appropriate method).

I absolutely agree that this is a needed section. We have had certificate pinning in for two years and it has been extremely difficult because the teams don't fully grasp the operational implications. Our strategy has been to include the old cert and the new cert. Since our app is a consumer app, I have also lobbied extremely hard to get a 'Your app is out of date and needs to be upgraded' but have not got traction. As a result, every time the certificate changes it's a world of pain since we don't have an effective way to let users know they need to update.

I have many, many thoughts on the operations side and would love to contribute.
[[User:SteveA|SteveA]]

== Android example contains code that breaks apps ==

The Android code example contains a section where it checks that the authtype equals "RSA". F5 recently changed their default authtypes to RSA-DHE. This meant that when we upgraded our F5's in production, all of our Android mobile apps broke. Obviously a big issue.

What is the compelling reason for this line of code:

if (!(null != authType && authType.equalsIgnoreCase("RSA"))) {
throw new CertificateException("checkServerTrusted: AuthType is not RSA");
}

== iOS sample is bad ==

the iOS sample doesn't need to be an entire program; it should be a minimal Objective-C fragment that demonstrates best practices in loading the keys or key fingerprints from a configuration file.

This Objective-C sample diverges pretty badly from the other language examples, which are short and sweet.
[[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 10:34, 17 June 2015 (CDT)

== TODO ==

A flaw in many pinning implementations was pointed out in [https://www.cigital.com/blog/ineffective-certificate-pinning-implementations/]
Does the OWASP sample code address this? Probably worth an explicit mention in the doc somewhere. I don't have time to tackle this now.
--[[User:TimMorgan|TimMorgan]] ([[User talk:TimMorgan|talk]]) 13:06, 10 March 2016 (CST)

== Best practices when running traffic through a CDN ==

In the modern day customers are allowing CDN vendors to route their HTTPS content and this means the CDN vendors are entrusted with decrypting their traffic.
I think this really throws a lot of conventional security wisdom out the window - and it would be nice if a certificate pinning best practice were established and documented here.
[[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 10:07, 13 July 2016 (CDT)

Talk:Certificate and Public Key Pinning

2016-07-13T15:05:27Z

Douglasheld: defined ICA

User talk:Jmanico

2016-06-29T09:06:34Z

Douglasheld: /* You deleted HTTP Response Splitting */ new section

= Jim's Suggestions for 2015 Strategic Plans =
__TOC__{{TOC hidden}}
== Build a scalable OWASP training program that spreads security training around the world ==
* Focus on building free and open source training materials for all to use
* Take existing wiki, powerpoint from talks, powerpoints from trainers who have open sourced content, key OWASP training-centric projects (webgoat, security Shepard, etc) and merge, clean up and professionalize the content into an OWASP branded series of trainings.
* Produce professional OWASP branded training videos and CBT
* Focus conference training program on using open source as opposed to proprietary/commercial content
* As a commercial ILT trainer I have a big conflict of interest over this topic

== Strengthen OWASP chapters and increase Chapter’s abilities to spread message of OWASP through locally organized and run events. ==
* Even something as simple as a chapter meeting is an "event" so anything to help make even chapter meetings better serves this goal
* Better plan to help chapters use funds
* Alert all chapters of existing chapter funds, on a monthly basis, on their public lists. Link to "How to use it to spread the message"
* Help pollenate cross-chapter meetings (Jerry Hoff)
* FUND SMALLER CHAPTERS IN A VERY SIGNIFICANT WAY

== Mature the OWASP Projects Platform: Provide the OWASP projects community a mature project platform to encourage senior developers to participate in the various and many OWASP projects. ==
* Consider hiring senior developer/developers to mature code centric OWASP programs like ESAPI, OWASP Java Encoder, etc.
* Consider funding security initiatives reviewing various open source projects and software frameworks in common use
* Connect leads of popular open source frameworks to OWASP community members willing to provide free appsec services, products, etc.
* Build a new website that is developer centric, pointing to key developers/secure coding projects and materials and other resources

== You deleted HTTP Response Splitting ==

Hi Jim, why did you delete the HTTP Response Splitting page? There is no descriptive information in the "move log".
[[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 04:06, 29 June 2016 (CDT)

HTTP Response Splitting

2016-05-03T15:07:06Z

Douglasheld: corrected the example

{{Template:Attack}}

Last revision: '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

 
[[Category:OWASP ASDR Project]]

==Description==
HTTP response splitting occurs when:

* Data enters a web application through an untrusted source, most frequently an HTTP request.
* The data is included in an HTTP response header sent to a web user without being validated for malicious characters.

HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header.

To mount a successful exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header AND the underlying platform must be vulnerable to the injection of such characters. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allow them to create additional responses entirely under their control.

The example below uses a Java example, but this issue has been fixed in virtually all modern Java EE application servers. If you are concerned about this risk, you should test on the platform of concern to see if the underlying platform allows for CR or LF characters to be injected into headers. We suspect that, in general, this vulnerability has been fixed in most modern application servers, regardless of what language the code has been written in.

==Examples==
The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response.

<pre>
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
</pre>

Assuming a string consisting of standard alpha-numeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form:

<pre>
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
</pre>

However, because the value of the cookie is formed of unvalidated user input, the response will only maintain this form if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Wiley Hacker\r\nContent-Length:45\r\n\r\n...", then the HTTP response would be split into an imposter response followed by the original response, which is now ignored:

<pre>
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
Content-Length: 999

<html>malicious content...</html> (to 999th character in this example)
Original content starting with character 1000, which is now ignored by the web browser...
</pre>

The ability of the attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: [[Cross-User Defacement]], [[Cache Poisoning]], [[Cross-site Scripting (XSS)]] and [[Page Hijacking]].

==Related [[Threat Agents]]==
* [[internal software developer]]

==Related [[Attacks]]==
* [[Cross-User Defacement]]
* [[Cache Poisoning]]
* [[Cross-site Scripting (XSS)]]
* [[Page Hijacking]]

==Related [[Vulnerabilities]]==
* [[:Category:Input Validation Vulnerability]]

==Related [[Controls]]==
* [[:Category:Input Validation]]

==References==
* http://www.infosecwriters.com/text_resources/pdf/HTTP_Response.pdf - HTTP Response Spliting
* http://www.securiteam.com/securityreviews/5WP0E2KFGK.html - Introdution to HTTP Response Spliting

[[Category:FIXME|link not working

* Watchfire Whitepaper: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics Whitepaper[http://download.watchfire.com/ttl/wp/HTTPResponseSplitting.pdf?file=HTTPResponseSplitting.pdf&authToken=1214447561_257e36e250a83a8e5942584866d295ee]

]]

==Credit==

{{Template:Fortify}}

[[Category: Protocol Manipulation]]
[[Category: Attack]]

__NOTOC__

CRLF Injection

2016-05-03T14:57:09Z

Douglasheld:

{{Template:Vulnerability}}

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

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==
The term CRLF refers to '''C'''arriage '''R'''eturn (ASCII 13, \r) '''L'''ine '''F'''eed (ASCII 10, \n). They're used to note the termination of a line, however, dealt with differently in today’s popular Operating Systems. For example: in Windows both a CR and LF are required to note the end of a line, whereas in Linux/UNIX a LF is only required. In the HTTP protocol, the CR-LF sequence is always used to terminate a line.

A CRLF Injection attack occurs when a user manages to submit a CRLF into an application. This is most commonly done by modifying an HTTP parameter or URL.

==Risk Factors==
TBD

==Examples==
Depending on how the application is developed, this can be a minor problem or a fairly serious security flaw. Let's look at the latter because this is after all a security related post.

Let's assume a file is used at some point to read/write data to a log of some sort. If an attacker managed to place a CRLF then can then inject some sort of read programmatic method to the file. This could result in the contents being written to screen on the next attempt to use this file.

Another example is the "response splitting" attacks, where CRLFs are injected into an application and included in the response. The extra CRLFs are interpreted by proxies, caches, and maybe browsers as the end of a packet, causing mayhem.

==Related [[Attacks]]==

* [[HTTP Response Splitting]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Control 1]]
* [[Control 2]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
TBD

[[Category:FIXME|add links

In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>

Availability Vulnerability

Authorization Vulnerability

Authentication Vulnerability

Concurrency Vulnerability

Configuration Vulnerability

Cryptographic Vulnerability

Encoding Vulnerability

Error Handling Vulnerability

Input Validation Vulnerability

Logging and Auditing Vulnerability

Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Implementation]]

CRLF Injection

2016-05-03T14:55:51Z

Douglasheld:

{{Template:Vulnerability}}

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

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==
The term CRLF refers to '''C'''arriage '''R'''eturn (ASCII 13, \r) '''L'''ine '''F'''eed (ASCII 10, \n). They're used to note the termination of a line, however, dealt with differently in today’s popular Operating Systems. For example: in Windows both a CR and LF are required to note the end of a line, whereas in Linux/UNIX a LF is only required.

A CRLF Injection attack occurs when a user manages to submit a CRLF into an application. This is most commonly done by modifying an HTTP parameter or URL.

==Risk Factors==
TBD

==Examples==
Depending on how the application is developed, this can be a minor problem or a fairly serious security flaw. Let's look at the latter because this is after all a security related post.

Let's assume a file is used at some point to read/write data to a log of some sort. If an attacker managed to place a CRLF then can then inject some sort of read programmatic method to the file. This could result in the contents being written to screen on the next attempt to use this file.

Another example is the "response splitting" attacks, where CRLFs are injected into an application and included in the response. The extra CRLFs are interpreted by proxies, caches, and maybe browsers as the end of a packet, causing mayhem.

==Related [[Attacks]]==

* [[HTTP Response Splitting]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Control 1]]
* [[Control 2]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
TBD

[[Category:FIXME|add links

In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>

Availability Vulnerability

Authorization Vulnerability

Authentication Vulnerability

Concurrency Vulnerability

Configuration Vulnerability

Cryptographic Vulnerability

Encoding Vulnerability

Error Handling Vulnerability

Input Validation Vulnerability

Logging and Auditing Vulnerability

Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Implementation]]

Talk:Certificate and Public Key Pinning

2015-06-17T15:34:02Z

Douglasheld: /* iOS sample is bad */

== Past Failures ==

This section is 'further reading' for those interested in surveying the landscape.

* Governments Want/Require Interception
** Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL, cryptome.org/ssl-mitm.pdf
** http://www.dailymail.co.uk/indiahome/indianews/article-2126277/No-secrets-Blackberry-Security-services-intercept-data-government-gets-way-messenger-service.html
* Governments Engage in Interception
** http://www.thetechherald.com/articles/Tunisian-government-harvesting-usernames-and-passwords/12429/
* Vendors Provide Interception Taps
** http://www.cisco.com/web/about/security/intelligence/LI-3GPP.html
* Governments Use Interception Taps
** https://www.eff.org/nsa-spying
* Mobile Interception is Patented
** Lawful interception for targets in a proxy mobile internet protocol network, http://www.google.com/patents/EP2332309A1
* Handset manufactures add trusted roots
** http://gaurangkp.wordpress.com/tag/nokias-man-in-the-middle-attack/
* Carriers can add trusted roots
** No reference yet, but http://www.theregister.co.uk/2011/12/15/carrier_iq_privacy_latest/
* CAs can become compromised
** http://isc.sans.edu/diary.html?storyid=11500
* Researchers created Rogue CAs
** http://www.win.tue.nl/hashclash/rogue-ca/
* Researchers collided certificates on existing CA certificates
** http://www.win.tue.nl/~bdeweger/CollidingCertificates/ddl-full.pdf
* DNS can become compromised
** http://forums.theregister.co.uk/forum/2/2011/09/05/dns_hijack_service_updated/
* Physical plant can become compromised
** http://www.pcworld.com/article/119851/paris_hilton_victim_of_tmobiles_web_flaws.html
* Its easy to set up an AP or Base Station (Chris Paget's IMSI Catcher)
** http://www.wired.com/threatlevel/2010/07/intercepting-cell-phone-calls/
* Can't trust some CAs – they will sell you out and issue subordinate CAs for money
** http://www.net-security.org/secworld.php?id=12369
** http://www.zdnet.com/trustwave-sold-root-certificate-for-surveillance-3040095011/
* Can't trust some browsers – they will sell you out and elide their responsibility
** https://bugzilla.mozilla.org/show_bug.cgi?id=724929
* Can't trust some browsers – they include questionable certificates out of the box
** https://bugzilla.mozilla.org/show_bug.cgi?id=542689
* Can't override some browser's CA list
** http://my.opera.com/community/forums/topic.dml?id=1580452
* Can't override OS's CA list (burned into ROM)
** http://support.google.com/android/bin/answer.py?hl=en&answer=1649774
* CRL/OCSP does not work as expected/intended
** http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern-browsers.html
** https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion
* User will break it too (not just bad guys)
** http://www.esecurityplanet.com/mobile-security/hacker-bypasses-apples-ios-in-app-purchases.html
** http://www.h-online.com/security/news/item/Apps-for-Windows-8-easily-hacked-1767839.html
* Interception proxies add additional risk
** http://blog.cryptographyengineering.com/2012/03/how-do-interception-proxies-fail.html
* HTTPS is broken
** http://www.thoughtcrime.org/software/sslstrip/
* PKI is broken
** www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
* The Internet is Broken :)
** http://blog.cryptographyengineering.com/2012/02/how-to-fix-internet.html

== Operational considerations ==

We use certificate pinning very commonly in my organization (yay for us) but we recently hit a problem when we were routinely changing a certificate on a service. The development team for one of the client applications and implemented pinning, but they had not considered what would happen when the certificate changed.

The majority of our clients support 2 pinned certificates at a time, so when we want to change the server cert the process is

1) Configure the new server cert in the client alongside the old one
2) Replace the old cert on the server
3) Configure the old cert from the client

This way we can do the cert rotation usually with no downtime for the client.

The team in question did not do this, which meant they had to have a few minutes of downtime (this is important as we have a demanding SLA) and also it meant that we had to do the change out of office hours to minimize the impact.

So, my suggestion is that we expand this page to include a section on "Operational considerations" that outlines the recommended approach.

Thoughts?

If no-one objects, I will add the new section in a couple of days.

[[User:Michael Goodwin|Michael Goodwin]] ([[User talk:Michael Goodwin|talk]]) 06:20, 2 April 2015 (CDT)

(I am not sure how to reply to your question so I will do it inline. Let me know the appropriate method).

I absolutely agree that this is a needed section. We have had certificate pinning in for two years and it has been extremely difficult because the teams don't fully grasp the operational implications. Our strategy has been to include the old cert and the new cert. Since our app is a consumer app, I have also lobbied extremely hard to get a 'Your app is out of date and needs to be upgraded' but have not got traction. As a result, every time the certificate changes it's a world of pain since we don't have an effective way to let users know they need to update.

I have many, many thoughts on the operations side and would love to contribute.
[[User:SteveA|SteveA]]

== Android example contains code that breaks apps ==

The Android code example contains a section where it checks that the authtype equals "RSA". F5 recently changed their default authtypes to RSA-DHE. This meant that when we upgraded our F5's in production, all of our Android mobile apps broke. Obviously a big issue.

What is the compelling reason for this line of code:

if (!(null != authType && authType.equalsIgnoreCase("RSA"))) {
throw new CertificateException("checkServerTrusted: AuthType is not RSA");
}

== iOS sample is bad ==

the iOS sample doesn't need to be an entire program; it should be a minimal Objective-C fragment that demonstrates best practices in loading the keys or key fingerprints from a configuration file.

This Objective-C sample diverges pretty badly from the other language examples, which are short and sweet.
[[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 10:34, 17 June 2015 (CDT)

Talk:Certificate and Public Key Pinning

2015-06-17T15:33:44Z

Douglasheld: /* iOS sample is bad */ new section

Certificate and Public Key Pinning

2015-06-17T15:24:12Z

Douglasheld: typo

[[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]].

A cheat sheet is available at [[Pinning_Cheat_Sheet|Pinning Cheat Sheet]].

== Introduction ==

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.

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]]).

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.

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]''.

== What's the problem? ==

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.

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]''.

=== Patient 0 ===

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.

=== The Cures ===

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.

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.

== What Is Pinning? ==

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.

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.

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. One exception is revocation and it is discussed below in [[#Pinning_Gaps|Pinning Gaps]].

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.

=== When Do You Pin? ===

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.

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.

=== When Do You Whitelist? ===

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.

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.

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]''.

=== How Do You Pin? ===

The idea is to re-use the existing 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.

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.

== What Should Be Pinned? ==

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>.

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.

=== Encodings/Formats ===

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]].

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''.

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.

{| align="center"
| [[File:random-org-der-dump.png|thumb|375px|Figure 1: subjectPublicKeyInfo dumped with dumpans1]]
| [[File:random-org-der-hex.png|thumb|375px|Figure 2: subjectPublicKeyInfo under a hex editor]]
|}

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>.

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]''.

=== Certificate ===

[[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.

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.

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.

=== Public Key ===

[[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.

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.

=== Hashing ===

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.

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.

Second, a digested certificate fingerprint is often available as a native API for many libraries, so its convenient to use.

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.

== What About X509? ==

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)).

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.

=== Mandatory Checks ===

All X509 verifications must include:

* 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).

* 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.

* 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].

=== Optional Checks ===

<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>
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.

=== Public Key Checks ===

''Quod vide'' (''q.v.''). Verifying the identity of a host with knowledge of its associated/expected public key is pinning.

== Examples of Pinning ==

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.

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.

===HTTP pinning===
[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:

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

Please note that [http://www.rfc-editor.org/rfc/rfc7469.txt RFC 7469] is controversial since it allows overrides for locally installed authorities. That is, it allows an adversary or other party who successfully phishes the user to override a known good pinset with non-authentic or fraudulent information. Second, the reporting mechanism is suppressed from broken pinsets, so a complying user agent will be complicit in the cover up after the fact. That is, the reporting of the broken pinset is called out as '''MUST NOT''' report [https://en.wikipedia.org/w/index.php?title=HTTP_Public_Key_Pinning [1]].

=== Android ===

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.

Download: [[Media:pubkey-pin-android.zip|Android sample program]]

<pre>public final class PubKeyManager implements X509TrustManager
{
private static String PUB_KEY = "30820122300d06092a864886f70d0101" +
"0105000382010f003082010a0282010100b35ea8adaf4cb6db86068a836f3c85" +
"5a545b1f0cc8afb19e38213bac4d55c3f2f19df6dee82ead67f70a990131b6bc" +
"ac1a9116acc883862f00593199df19ce027c8eaaae8e3121f7f329219464e657" +
"2cbf66e8e229eac2992dd795c4f23df0fe72b6ceef457eba0b9029619e0395b8" +
"609851849dd6214589a2ceba4f7a7dcceb7ab2a6b60c27c69317bd7ab2135f50" +
"c6317e5dbfb9d1e55936e4109b7b911450c746fe0d5d07165b6b23ada7700b00" +
"33238c858ad179a82459c4718019c111b4ef7be53e5972e06ca68a112406da38" +
"cf60d2f4fda4d1cd52f1da9fd6104d91a34455cd7b328b02525320a35253147b" +
"e0b7a5bc860966dc84f10d723ce7eed5430203010001";

public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException
{
if (chain == null) {
throw new IllegalArgumentException("checkServerTrusted: X509Certificate array is null");
}

if (!(chain.length > 0)) {
throw new IllegalArgumentException("checkServerTrusted: X509Certificate is empty");
}

if (!(null != authType && authType.equalsIgnoreCase("RSA"))) {
throw new CertificateException("checkServerTrusted: AuthType is not RSA");
}

// Perform customary SSL/TLS checks
try {
TrustManagerFactory tmf = TrustManagerFactory.getInstance("X509");
tmf.init((KeyStore) null);

for (TrustManager trustManager : tmf.getTrustManagers()) {
((X509TrustManager) trustManager).checkServerTrusted(chain, authType);
}
} catch (Exception e) {
throw new CertificateException(e);
}

// Hack ahead: BigInteger and toString(). We know a DER encoded Public Key begins
// with 0x30 (ASN.1 SEQUENCE and CONSTRUCTED), so there is no leading 0x00 to drop.
RSAPublicKey pubkey = (RSAPublicKey) chain[0].getPublicKey();
String encoded = new BigInteger(1 /* positive */, pubkey.getEncoded()).toString(16);

// Pin it!
final boolean expected = PUB_KEY.equalsIgnoreCase(encoded);
if (!expected) {
throw new CertificateException("checkServerTrusted: Expected public key: "
+ PUB_KEY + ", got public key:" + encoded);
}
}
}
}</pre>

<tt>PubKeyManager</tt> would be used in code similar to below.

<pre>TrustManager tm[] = { new PubKeyManager() };

SSLContext context = SSLContext.getInstance("TLS");
context.init(null, tm, null);

URL url = new URL( "https://www.random.org/integers/?" +
"num=16&min=0&max=255&col=16&base=10&format=plain&rnd=new");

HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();
connection.setSSLSocketFactory(context.getSocketFactory());

InputStreamReader instream = new InputStreamReader(connection.getInputStream());
StreamTokenizer tokenizer = new StreamTokenizer(instream);
...</pre>

=== iOS ===

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.

Download: [[Media:pubkey-pin-ios.zip|iOS sample program]].

<pre>-(IBAction)fetchButtonTapped:(id)sender
{
NSString* requestString = @"https://www.random.org/integers/?
num=16&min=0&max=255&col=16&base=16&format=plain&rnd=new";
NSURL* requestUrl = [NSURL URLWithString:requestString];

NSURLRequest* request = [NSURLRequest requestWithURL:requestUrl
cachePolicy:NSURLRequestReloadIgnoringLocalCacheData
timeoutInterval:10.0f];

NSURLConnection* connection = [[NSURLConnection alloc] initWithRequest:request delegate:self];
}

-(BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:
(NSURLProtectionSpace*)space
{
return [[space authenticationMethod] isEqualToString: NSURLAuthenticationMethodServerTrust];
}

- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:
(NSURLAuthenticationChallenge *)challenge
{
if ([[[challenge protectionSpace] authenticationMethod] isEqualToString: NSURLAuthenticationMethodServerTrust])
{
do
{
SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust];
if(nil == serverTrust)
break; /* failed */

OSStatus status = SecTrustEvaluate(serverTrust, NULL);
if(!(errSecSuccess == status))
break; /* failed */

SecCertificateRef serverCertificate = SecTrustGetCertificateAtIndex(serverTrust, 0);
if(nil == serverCertificate)
break; /* failed */

CFDataRef serverCertificateData = SecCertificateCopyData(serverCertificate);
[(id)serverCertificateData autorelease];
if(nil == serverCertificateData)
break; /* failed */

const UInt8* const data = CFDataGetBytePtr(serverCertificateData);
const CFIndex size = CFDataGetLength(serverCertificateData);
NSData* cert1 = [NSData dataWithBytes:data length:(NSUInteger)size];

NSString *file = [[NSBundle mainBundle] pathForResource:@"random-org" ofType:@"der"];
NSData* cert2 = [NSData dataWithContentsOfFile:file];

if(nil == cert1 || nil == cert2)
break; /* failed */

const BOOL equal = [cert1 isEqualToData:cert2];
if(!equal)
break; /* failed */

// The only good exit point
return [[challenge sender] useCredential: [NSURLCredential credentialForTrust: serverTrust]
forAuthenticationChallenge: challenge];
} while(0);

// Bad dog
return [[challenge sender] cancelAuthenticationChallenge: challenge];
}</pre>

=== .Net ===

.Net pinning can be achieved by using <tt>ServicePointManager</tt> as shown below.

Download: [[Media:pubkey-pin-dotnet.zip|.Net sample program]].

<pre>// Encoded RSAPublicKey
private static String PUB_KEY = "30818902818100C4A06B7B52F8D17DC1CCB47362" +
"C64AB799AAE19E245A7559E9CEEC7D8AA4DF07CB0B21FDFD763C63A313A668FE9D764E" +
"D913C51A676788DB62AF624F422C2F112C1316922AA5D37823CD9F43D1FC54513D14B2" +
"9E36991F08A042C42EAAEEE5FE8E2CB10167174A359CEBF6FACC2C9CA933AD403137EE" +
"2C3F4CBED9460129C72B0203010001";

public static void Main(string[] args)
{
ServicePointManager.ServerCertificateValidationCallback = PinPublicKey;
WebRequest wr = WebRequest.Create("https://encrypted.google.com/");
wr.GetResponse();
}

public static bool PinPublicKey(object sender, X509Certificate certificate, X509Chain chain,
SslPolicyErrors sslPolicyErrors)
{
if (null == certificate)
return false;

String pk = certificate.GetPublicKeyString();
if (pk.Equals(PUB_KEY))
return true;

// Bad dog
return false;
}</pre>

=== OpenSSL ===

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.

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'''.

Download: [[Media:pubkey-pin-openssl.zip|OpenSSL sample program]].

<pre>int pkp_pin_peer_pubkey(SSL* ssl)
{
if(NULL == ssl) return FALSE;

X509* cert = NULL;
FILE* fp = NULL;

/* Scratch */
int len1 = 0, len2 = 0;
unsigned char *buff1 = NULL, *buff2 = NULL;

/* Result is returned to caller */
int ret = 0, result = FALSE;

do
{
/* http://www.openssl.org/docs/ssl/SSL_get_peer_certificate.html */
cert = SSL_get_peer_certificate(ssl);
if(!(cert != NULL))
break; /* failed */

/* Begin Gyrations to get the subjectPublicKeyInfo */
/* Thanks to Viktor Dukhovni on the OpenSSL mailing list */

/* http://groups.google.com/group/mailing.openssl.users/browse_thread/thread/d61858dae102c6c7 */
len1 = i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert), NULL);
if(!(len1 > 0))
break; /* failed */

/* scratch */
unsigned char* temp = NULL;

/* http://www.openssl.org/docs/crypto/buffer.html */
buff1 = temp = OPENSSL_malloc(len1);
if(!(buff1 != NULL))
break; /* failed */

/* http://www.openssl.org/docs/crypto/d2i_X509.html */
len2 = i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert), &temp);

/* These checks are verifying we got back the same values as when we sized the buffer. */
/* Its pretty weak since they should always be the same. But it gives us something to test. */
if(!((len1 == len2) && (temp != NULL) && ((temp - buff1) == len1)))
break; /* failed */

/* End Gyrations */

/* See the warning above!!! */
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/fopen.html */
fp = fopen("random-org.der", "rx");
if(NULL ==fp) {
fp = fopen("random-org.der", "r");

if(!(NULL != fp))
break; /* failed */

/* Seek to eof to determine the file's size */
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/fseek.html */
ret = fseek(fp, 0, SEEK_END);
if(!(0 == ret))
break; /* failed */

/* Fetch the file's size */
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/ftell.html */
long size = ftell(fp);

/* Arbitrary size, but should be relatively small (less than 1K or 2K) */
if(!(size != -1 && size > 0 && size < 2048))
break; /* failed */

/* Rewind to beginning to perform the read */
/* http://pubs.opengroup.org/onlinepubs/009696699/functions/fseek.html */
ret = fseek(fp, 0, SEEK_SET);
if(!(0 == ret))
break; /* failed */

/* Re-use buff2 and len2 */
buff2 = NULL; len2 = (int)size;

/* http://www.openssl.org/docs/crypto/buffer.html */
buff2 = OPENSSL_malloc(len2);
if(!(buff2 != NULL))
break; /* failed */

/* http://pubs.opengroup.org/onlinepubs/009696699/functions/fread.html */
/* Returns number of elements read, which should be 1 */
ret = (int)fread(buff2, (size_t)len2, 1, fp);
if(!(ret == 1))
break; /* failed */

/* Re-use size. MIN and MAX macro below... */
size = len1 < len2 ? len1 : len2;

/*************************/
/***** PAYDIRT *****/
/*************************/
if(len1 != (int)size || len2 != (int)size || 0 != memcmp(buff1, buff2, (size_t)size))
break; /* failed */

/* The one good exit point */
result = TRUE;

} while(0);

if(fp != NULL)
fclose(fp);

/* http://www.openssl.org/docs/crypto/buffer.html */
if(NULL != buff2)
OPENSSL_free(buff2);

/* http://www.openssl.org/docs/crypto/buffer.html */
if(NULL != buff1)
OPENSSL_free(buff1);

/* http://www.openssl.org/docs/crypto/X509_new.html */
if(NULL != cert)
X509_free(cert);

return result;
}</pre>

== Pinning Alternatives ==

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.

{| align="center"
| [[File:pin-iana-assigned.png|thumb|450px|Figure 3: IANA reserved cipher suites for SRP and PSK]]
|}

=== SRP ===

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{(salt + password)|verifier} + nonces'' rather than traditional Diffie-Hellman using ''gab''.

[[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).

=== PSK ===

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.

== Miscellaneous ==

This sections covers administrivia and miscellaneous items related to pinning.

=== Ephemeral Keys ===

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).

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>.

=== Pinning Gaps ===

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.

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.

=== No Relationship ^@$! ===

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.

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].

Third, help is on its way, and there are a number of futures that will assist with the endeavors:

* 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.
* 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.
* 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.
* 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.

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.

=== More Information? ===

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]''.

=== Format Conversions ===

As a convenience to readers, the following with convert between PEM and DER format using OpenSSL.

<pre># Public key, X509
$ openssl genrsa -out rsa-openssl.pem 3072
$ openssl rsa -in rsa-openssl.pem -pubout -outform DER -out rsa-openssl.der</pre>

<pre># Private key, PKCS#8
$ openssl genrsa -out rsa-openssl.pem 3072
$ openssl pkcs8 -nocrypt -in rsa-openssl.pem -inform PEM -topk8 -outform DER -out rsa-openssl.der</pre>

== References ==

* OWASP [[Injection_Theory|Injection Theory]]
* OWASP [[Data_Validation|Data Validation]]
* OWASP [[Transport_Layer_Protection_Cheat_Sheet|Transport Layer Protection Cheat Sheet]]
* IETF [http://www.ietf.org/id/draft-ietf-websec-key-pinning-09.txt Public Key Pinning]
* IETF [http://www.ietf.org/rfc/rfc5054.txt RFC 5054 (SRP)]
* IETF [http://www.ietf.org/rfc/rfc4764.txt RFC 4764 (EAP-PSK)]
* IETF [http://www.ietf.org/rfc/rfc1421.txt RFC 1421 (PEM Encoding)]
* IETF [http://www.ietf.org/rfc/rfc5280.txt RFC 5280 (Internet X.509, PKIX)]
* IETF [http://www.ietf.org/rfc/rfc4648.txt RFC 4648 (Base16, Base32, and Base64 Encodings)]
* IETF [http://www.ietf.org/rfc/rfc3279.txt RFC 3279 (PKI, X509 Algorithms and CRL Profiles)]
* IETF [http://www.ietf.org/rfc/rfc4055.txt RFC 4055 (PKI, X509 Additional Algorithms and CRL Profiles)]
* IETF [http://www.ietf.org/rfc/rfc2246.txt RFC 2246 (TLS 1.0)]
* IETF [http://www.ietf.org/rfc/rfc4346.txt RFC 4346 (TLS 1.1)]
* IETF [http://www.ietf.org/rfc/rfc5246.txt RFC 5246 (TLS 1.2)]
* IETF [http://www.ietf.org/rfc/rfc6698.txt RFC 6698, Draft (DANE)]
* EFF [http://www.eff.org/sovereign-keys Sovereign Keys]
* Thoughtcrime Labs [http://convergence.io/ Convergence]
* RSA Laboratories [http://www.rsa.com/rsalabs/node.asp?id=2125 PKCS#1, RSA Encryption Standard]
* RSA Laboratories [http://www.rsa.com/rsalabs/node.asp?id=2128 PKCS#6, Extended-Certificate Syntax Standard]
* 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)]
* TOR Project [https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion Detecting Certificate Authority Compromises and Web Browser Collusion]
* Code Project [http://www.codeproject.com/Articles/25487/Cryptographic-Interoperability-Keys Cryptographic Interoperability: Keys]
* Google I/O [https://developers.google.com/events/io/sessions/gooio2012/107/ Security and Privacy in Android Apps]
* Trevor Perrin [https://crypto.stanford.edu/RealWorldCrypto/slides/perrin.pdf Transparency, Trust Agility, Pinning (Recent Developments in Server Authentication)]
* Dr. Peter Gutmann's [http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf PKI is Broken]
* Dr. Matthew Green's [http://blog.cryptographyengineering.com/2012/02/how-to-fix-internet.html The Internet is Broken]
* Dr. Matthew Green's [http://blog.cryptographyengineering.com/2012/03/how-do-interception-proxies-fail.html How do Interception Proxies fail?]

= Authors and Primary Editors =

* Jeffrey Walton - jeffrey, owasp.org
* JohnSteven - john, owasp.org
* Jim Manico - jim, owasp.org
* Kevin Wall - kevin, owasp.org

[[Category:Control]]

AppSecResearch2012/wp-content/presentations/Doug Held - A Buffer Overflow Story.pdf

2011-09-13T23:26:22Z

Douglasheld: Added author portrait

== '''A Buffer Overflow Story: From Responsible Disclosure to Closure''' ==
[[File:Douglas_held_20110508_R_centre.jpg‎]]
 Douglas Held Software Security Consultant Fortify Software doug.held@hp.com

== '''Link to the presentation:''' [[File:A Buffer Overflow Story.pdf]] ==

== '''Abstract:''' ==

The US National Institutes of Science and Technology has been holding a competition to choose a design for the Secure Hash Algorithm, version 3 ("SHA-3"). The primary goal is for the cryptographic community to weed out the less secure algorithms and choose from the remainder. Each submission includes a C reference implementation for demonstrating performance, a factor in the final choice.

Fortify Software undertook an automated code review of the SHA-3 round 1 contestants' reference implementations, including Ron Rivest's MD6.

Findings included bugs that could cause crashes, performance or security problems. After a follow up audit and contacting the developers with the findings, Fortify reported summary results on the Fortify blog and on Slashdot.org. According to the blog entry, "This just emphasizes what we already knew about C, even the most careful, security conscious developer messes up memory management."

The speaker will discuss specific findings, including some very unexpected outcomes, as well as wildly differing perspectives from the developer community. The story underscores the need to continue improving education and processes to further the goal of computing securely.

File:Douglas held 20110508 R centre.jpg

2011-09-13T23:22:03Z

Douglasheld: uploaded a new version of "File:Douglas held 20110508 R centre.jpg": Photographic portrait of Douglas Held (OWASP speaker)

Portrait of Douglas Held (OWASP speaker)

File:File-Douglas held 20110508 R centre.jpg

2011-09-13T23:16:59Z

Douglasheld: Photographic portrait of Douglas Held (OWASP speaker)

Photographic portrait of Douglas Held (OWASP speaker)

User:Douglasheld

2011-09-13T23:10:36Z

Douglasheld: Initial content

[[File:Douglas held 20110508 R centre.jpg]]

File:Douglas held 20110508 R centre.jpg

2011-09-13T23:09:28Z

Douglasheld: Portrait of Douglas Held (OWASP speaker)

Portrait of Douglas Held (OWASP speaker)

AppSecResearch2012/wp-content/presentations/Doug Held - A Buffer Overflow Story.pdf

2011-09-13T23:06:03Z

Douglasheld:

== '''A Buffer Overflow Story: From Responsible Disclosure to Closure''' ==

Douglas Held Software Security Consultant Fortify Software doug.held@hp.com

'''Link to the presentation:''' [[Image:A Buffer Overflow Story.pdf]]

'''Abstract:'''

The US National Institutes of Science and Technology has been holding a competition to choose a design for the Secure Hash Algorithm, version 3 ("SHA-3"). The primary goal is for the cryptographic community to weed out the less secure algorithms and choose from the remainder. Each submission includes a C reference implementation for demonstrating performance, a factor in the final choice.

Fortify Software undertook an automated code review of the SHA-3 round 1 contestants' reference implementations, including Ron Rivest's MD6.

Findings included bugs that could cause crashes, performance or security problems. After a follow up audit and contacting the developers with the findings, Fortify reported summary results on the Fortify blog and on Slashdot.org. According to the blog entry, "This just emphasizes what we already knew about C, even the most careful, security conscious developer messes up memory management."

The speaker will discuss specific findings, including some very unexpected outcomes, as well as wildly differing perspectives from the developer community. The story underscores the need to continue improving education and processes to further the goal of computing securely.

AppSecResearch2012/wp-content/presentations/Doug Held - A Buffer Overflow Story.pdf

2011-09-13T23:03:47Z

Douglasheld: /* A Buffer Overflow Story: From Responsible Disclosure to Closure */

== '''A Buffer Overflow Story: From Responsible Disclosure to Closure''' ==

Douglas Held Software Security Consultant Fortify Software doug.held@hp.com

'''Link to the presentation:''' [[Image:A Buffer Overflow Story.pdf]]

'''Abstract:'''

The US National Institutes of Science and Technology has been holding a competition to choose a design for the Secure Hash Algorithm, version 3 ("SHA-3"). The primary goal is for the cryptographic community to weed out the less secure algorithms and choose from the remainder. Each submission includes a C reference implementation for demonstrating performance, a factor in the final choice.

Fortify Software undertook an automated code review of the SHA-3 round 1 contestants' reference implementations, including Ron Rivest's MD6.

Findings included bugs that could cause crashes, performance or security problems. After a follow up audit and contacting the developers with the findings, Fortify reported summary results on the Fortify blog and on Slashdot.org. According to the blog entry, "This just emphasizes what we already knew about C, even the most careful, security conscious developer messes up memory management."

The speaker will discuss specific findings, including some very unexpected outcomes, as well as wildly differing perspectives from the developer community. The story underscores the need to continue improving education and processes to further the goal of computing securely.

AppSecResearch2012/wp-content/presentations/Doug Held - A Buffer Overflow Story.pdf

2011-09-13T23:02:25Z

Douglasheld: Initial content

== '''A Buffer Overflow Story: From Responsible Disclosure to Closure''' ==
Douglas Held
Software Security Consultant
Fortify Software
doug.held@hp.com

'''Link to the presentation:''' [[File:A_Buffer_Overflow_Story.pdf]]

'''Abstract:'''

The US National Institutes of Science and Technology has been holding a competition to choose a design for the Secure Hash Algorithm, version 3 ("SHA-3"). The primary goal is for the cryptographic community to weed out the less secure algorithms and choose from the remainder. Each submission includes a C reference implementation for demonstrating performance, a factor in the final choice.

Fortify Software undertook an automated code review of the SHA-3 round 1 contestants' reference implementations, including Ron Rivest's MD6.

Findings included bugs that could cause crashes, performance or security problems. After a follow up audit and contacting the developers with the findings, Fortify reported summary results on the Fortify blog and on Slashdot.org. According to the blog entry, "This just emphasizes what we already knew about C, even the most careful, security conscious developer messes up memory management."

The speaker will discuss specific findings, including some very unexpected outcomes, as well as wildly differing perspectives from the developer community. The story underscores the need to continue improving education and processes to further the goal of computing securely.

File:A Buffer Overflow Story.pdf

2011-09-13T22:54:34Z

Douglasheld: Douglas Held (Fortify Sofware) presentation to OWASP AppSec EU 2011

Douglas Held (Fortify Sofware) presentation to OWASP AppSec EU 2011

Talk:Securing tomcat

2009-04-03T18:06:06Z

Douglasheld: new section: File Permissions

== File permissions ==

Hmm, what does "Make sure tomcat user has read/write access to /tmp" mean?

Tomcat creates a directory "temp", not "tmp", and read/write on a directory doesn't actually allow reading or writing. I assume the intention is "chmod 700 temp"... would love if anyone can clarify.
[[User:Douglasheld|Douglasheld]] 18:06, 3 April 2009 (UTC)

== Newer Tomcat branches ==

This page is hopelessly outdated for anyone working with the Tomcat 6 branch. We need to figure out the best way to document security measures for the different supported branches.
[[User:Ken|Ken]] 10:25, 20 March 2009 (UTC)

I've not had call to use Tomcat 6, but in a few months I plan to start experimenting with the embedded version. I don't mind expanding the article to have a section on 6 (and keep the section on 5.5), but I can't contribute anything just yet. My preference would be a single article as it will cut down on duplication. In the meantime, any differences, areas to cover, new features, etc. that others could note down will help speed things up. [[User:Dledmonds|Darren]] 09:11, 26 March 2009 (UTC)