Open Mobile Menu

Blog

Evolving Steps to Protect Web Applications

Views: 2062

Written By: Adam Caudill September 07, 2016

The world of application security is constantly evolving, and there are some exciting efforts underway now. This article discusses some of the more important changes that are happening, and what you need to do to be ready for them.

TLS 1.3

The next version of TLS (the evolution of SSL – Secure Sockets Layer) is well underway, and is expected to be completed before the end of 2016. Draft support is already available in development builds of Chrome and Firefox, and NSS for server use. This is a significant update to the protocol, and addresses a number of issues that have long plagued SSL/TLS. The changes are significant enough, that it was originally going to be called TLS 2.0.

Over the last couple years, great progress has been made in moving away from SSL v3 and adding support for TLS – client support for TLS 1.2 is now nearly ubiquitous (older versions of Android and Java being the primary exceptions) and nearly 80% of servers now support TLS 1.2 according to SSL Pulse. Much of this progress has been a result of major flaws found in older versions of the protocol, such as POODLE, Logjam,  and DROWN.

TLS 1.3 supports a smaller number of cipher suites, all of which are AEAD – this construct results in a number of potential issues being eliminated, such as Lucky Thirteen. While the total number of cipher suites is significantly reduced, support is added for ChaCha20-Poly1305 – a suite that provides much better performance for mobile devices, and new ECC signature and key exchange algorithms based on Curve 25519 and 448-Goldilocks. Also removed are static RSA and Diffie-Hellman (DH) key exchanges. Overall, TLS 1.3 is a major step forward for the security of the protocol.

The biggest risk for web applications is version intolerance – as browsers and other clients add support for TLS 1.3, they will begin sending a new version number to servers. When this happens, some servers fail in various ways – some send a fatal alert, others just disconnect the client, which is obviously a less than ideal user experience. According to the last data published from SSL Pulse, 3.2% of tested servers fail with TLS 1.3. As we approach the release of TLS 1.3, it’s important to test for version intolerance, and update software to ensure that TLS 1.3 clients are able to connect properly.

HTTP Public Key Pinning

HPKP was standardized in April of 2015, though is still rarely used – even though it’s a very powerful tool to prevent interception of sensitive data. HKPK is a header that the server sends, which instructs the browser to require a certain certificate be presented – if a different certificate is presented, the browser will reject it.

This prevents issues with a Certificate Authority (CA) issuing a certificate for your domain (that you didn’t request) – as happened with the Diginotar hack, or the various flaws that have been found with CAs that allow a malicious user to receive a certificate for a domain that they don’t control. There have been a number of cases in recent months where the ability to acquire certificates for domains that a user doesn’t control has been demonstrated, making it clear that this is a very real issue. As a bonus, one of the optional fields is a URL that reports can be sent to, so you can track when an illegitimate certificate is used.

There is a risk to using this though – and there has been a debate about when to suggest using this, because of how significant that risk is. If there’s a typo in the Public-Key-Pins header, it can result in the website being rendered unusable – as the browser rejects the legitimate certificate, locking users out of the site. Should this happen, users will be unable to access the website until the pin expires – seeing as one to two months is the recommended expiration, that could be an extremely serious issue.

To mitigate some of these risks, HPKP allows you to pin multiple keys – this allows you to pin a primary and backup certificate, in case of a private key compromise or to add a new certificate well before the current certificate expires. It is also possible to pin your Certificate Authority’s certificate instead of the certificate for your server; this prevents browsers from accepting a certificate from another CA, but doesn’t help you in case your CA is compromised.

Thankfully, there’s a variant called Public-Key-Pins-Report-Only which submits violations of the rule to a specified server, but doesn’t actually block the connection. When implementing HPKP, it’s recommended to start with the Report-Only variant to make sure that everything is working properly before switching to the blocking version.

SameSite Cookie Attribute

At this point, many people are familiar with the Secure and HttpOnly cookie attributes that control how they are used and accessed – there’s a new option coming soon called “SameSite” which controls when cookies are sent by the browser. There are two options that can be used, Strict or Lax, both of which are valuable and add useful restrictions to prevent cookies from being sent when they shouldn’t be. This is one of the rare security improvements that can eliminate an entire class of attacks with a simple change.

SameSite=Strict

Adding “SameSite=Strict” to a cookie results in the cookie only being sent when the referring page is in the same scope as the cookie – even clicking a link from another will prevent the cookie from being sent. The result of this, is that it effectively eliminates Cross-Site Request Forgery (CSRF) – as the cookie wouldn’t be sent by the browser for a request originating from another site. The down side, if the website is designed to use “Remember Me” style functionality – after clicking a link to the site, the browser won’t send the cookie, and thus the user will appear to be logged out.

SameSite=Lax

Adding “SameSite=Lax” on the other hand, allows some cross origin use – links from another site will still send the cookie, but POST requests, iframes, and the like will not. If a website is designed so that sensitive operations are all performed by POST requests, this can provide CSRF protection, while still providing a positive user experience.

This is an evolving standard (developed by Google & Mozilla), though it’s currently supported in Chrome and Opera, and work to add support to Firefox is in progress. It should also be noted, until the vast majority of users are using a browser that supports this attribute, traditional anti-CSRF techniques should still be used.

Adam Caudill

Adam Caudill is a Senior Application Security Consultant. He is an expert in application security, with a specialty in applied cryptography; speaking regularly at industry events on topics from data protection to attack techniques. Adam has more than 15 years of experience in information technology, with responsibilities including systems administration, full-stack software development, architecture & system design, security code review, development and implementation of secure development standards, and penetration testing. He utilizes a combination of manual and automated techniques; often building or extending custom automated tools when existing solutions fall short.


Adam is a frequent contributor to open source projects, and maintains a number of security-related projects; from a tool to aid PCI auditors, to cryptography-related tools and libraries. His free time is spent writing about security and development, or working on new research. His writing and research has been cited by many media outlets and publications around the world, from CNN to Wired and countless others.


Expertise

  • Web Application Security Assessment and Penetration Testing
  • Mobile Application Security Assessment and Penetration Testing (iOS & Android)
  • Cryptographic Design & Implementation Review
  • Application Security Code Review
  • Secure Application Development Practices
  • Application Development (C#, Ruby)
  • Security Training
  • Technical Writing and Presentation

Professional and Industry Affiliations

  • Open Web Application Security Project (OWASP), Member
  • BSides Knoxville Conference, Founder
  • Underhanded Crypto Contest, Founder

read more articles by Adam Caudill