Threat Analysis

Regardless of whether your application uses single sign-on systems, web services solutions, different data, or document formats (JSON, XML, PDF, ODF, OOXML), information rights management or cryptographic methods, the security aspects must be well planned.

Our individual threat analysis helps you design your application to be secure from the ground up and ensure secure operation. A threat analysis covers three essential steps in planning a secure application:

Optimal Protection Thanks to Profound Expertise
Benefit from the Hackmanit professionals’ many years of experience and avoid time-consuming and expensive future adjustments of your application. A threat analysis helps you to optimize the security of your application from the very beginning.

Choosing the right security technology is often a non-trivial task. New standards and technologies are continually being developed and extended, making it difficult to keep track of the available options. The appropriate technology choice also depends strongly on individual factors such as your scenario and your specific security requirements.

A threat analysis offers you the possibility to have your scenario analyzed by Hackmanit professionals. Threats are detected before they occur and you avoid having to spend time studying different technologies before you decide which one is right for your scenario. The great benefits of a threat analysis can be best illustrated with the following case studies.

• Case Study: Protection Against Cross-Site Scripting (XSS)

  

  Are you concerned with your web application's security? Do you want to protect your users as good as possible? Numerous attack classes are relevant: Starting with clickjacking and UI redressing, through SQL injection and cross-site request forgery (CSRF), to cross-site scripting (XSS). In the best case, you address these attack classes during your planning and implementation. For this purpose, it is essential to know each attack class's details and appropriate countermeasures.

  A concrete example of the non-trivial use of countermeasures is the X-XSS-Protection HTTP header. In the past, it was considered a useful measure to increase protection against XSS. Many recommendations can be found on the Internet to deliver this header with the value 1; mode=block. This value activates the XSS filter in Internet Explorer and Google Chrome. It ensures that the entire document is not displayed when an attack is detected. For example, this recommendation can be found in the well-known HTTP header scanner Mozilla Observatory (October 2020).

  Considering the new attack class "XS-Leaks", developers should no longer use this value for the X-XSS-Protection header. Attackers can use XS-Leaks to bypass other protection mechanisms such as CSRF tokens. As a result of this danger, browser manufacturers like Google have removed the XSS filter. From the developer's perspective, the recommendation is to set the HTTP header X-XSS-Protection to 0 to protect users in all other browsers.

  As part of a threat analysis, we can recommend these and other countermeasures for various attack classes - specifically customized for your application. Our experience helps you identify and avoid possible weak points before implementation without learning the details of each complex attack class yourself. These recommendations save you time and money without compromising the security of your application and your users.

• Case Study: Extension of Your Application With Single Sign-On

  

  Using your application requires users to log in. To lower the barriers for new users and to spare users another pair of credentials, you plan to extend your application to support single sign-on. Single sign-on is also useful if you operate multiple applications used by the same user group and want them to be a single account.

  The login is a security-critical process. You are now faced with the challenge of reviewing different single sign-on solutions and their security and deciding which protocol is the right one for your application.

  Many applications use the widespread standards SAML, OAuth, and OpenID Connect. Each of the standards offers different protocol variants and extensions for specific scenarios. Therefore, after the general decision for one of the standards, you will face further questions, among others:

  • Which protocol variant can I use in my scenario?
  • How can I use the standard in the most secure way for my application?
  • Are advanced security mechanisms, such as PKCE or proof-of-possession tokens, relevant for me? What do I have to keep in mind when using them?

  Helping you to decide on the right standard and answer specific questions related to your scenario, Hackmanit will prepare a detailed threat analysis for you. During the threat analysis, Hackmanit looks at your application, your use-case in which you deploy the application, and the security requirements you have defined in detail. The threat analysis saves you the lengthy process of learning several single sign-on standards. Besides, a threat analysis helps to avoid pitfalls in the design of your application. Thus, subsequent adjustments due to security gaps, which are often expensive and time-consuming, can be avoided.

• Case Study: Replacement of the OAuth Implicit Grant

  

  Your application is a Javascript-based web application - a so-called single page application (SPA). Your SPA uses OAuth to access user data via APIs. Your SPA receives the OAuth access token required for this purpose via the OAuth implicit grant, which transfers the access token as a part of the URL.

  From the beginning, the implicit grant was only intended as a "workaround" for SPAs, since the same-origin policy (SOP) prevented them from using the OAuth authorization code grant. Using cross-origin resource sharing (CORS), it is possible to define exceptions for the SOP so that your SPAs can now use the secure authorization code grant. Due to the numerous security disadvantages, developers should no longer use the OAuth implicit grant.

  Therefore, you are considering updating your application and replacing the OAuth implicit grant with the OAuth authorization code grant. In doing so, you are faced with a number of questions that can be answered by a threat analysis, including the following:

  • Why should the OAuth implicit grant not be used?
  • What are the benefits of using the authorization code grant?
  • What attacks are prevented by changing the grant?
  • Are there any security-related issues that need to be addressed when changing the grant?

  By switching to the authorization code grant, you prevent numerous attacks. For example, you significantly reduce the risk of attackers stealing the access token. You can find detailed information about the attacks on the OAuth implicit grant here.

  A threat analysis examines which attacks are to be considered in your use-case. You get details on threats that you prevent by changing the grant. The threat analysis also covers what you need to consider when using the authorization code grant and how you can secure your application optimally against attacks.

• Case Study: Support of a Second Identity Provider or Social Login

  

  You are successfully running an application that allows users to log in using single sign-on. Your application is well secured and penetration tests regularly verify its security. Currently, your application supports only a single identity provider for single sign-on, such as the social login "Google Sign-In".

  You are currently evaluating whether to support an additional identity provider in your application. This addition can be the case if you want to reach a new group of potential users or if you are forced to support a certain identity provider due to administrative regulations. For example, a publication in Apple's App Store requires the support of "Sign in with Apple", if your application offers a login via single sign-on.

  When adding a second identity provider, the security impact must be evaluted. In a threat analysis, we examine the addition to ensure that your application will continue to be well protected.

  The parallel support of multiple identity providers results in a new scenario for your application. It can be vulnerable to particular attacks that take advantage of the use of multiple identity providers. These attacks aim, for example, at mixing protocol variants with different identity providers and thus enable an attacker to access arbitrary user accounts and data. In addition to these special attacks, it is now necessary to check which protocol variants and security mechanisms each identity provider supports and how your application can optimally integrate the provider.

  A threat analysis examines which pitfalls you have to consider when extending your application and prevents new vulnerabilities from occurring. It saves you the time-consuming learning of complex attacks and countermeasures and helps to prevent a "rude awakening" during the next penetration test.

• Case Study: Secure Use of TLS
  

  

  Transport layer security (TLS) has become a valuable protection for almost every (web) application. Whenever someone visits your website via https, the TLS protocol is used in the background. In current browsers, the protocol has become mandatory; browsers automatically flag websites without TLS as insecure. Therefore you do not want to deploy your new application without TLS.

  The significant relevance and the diverse use of the TLS protocol have led to the continuous development of new extensions and cryptographic mechanisms. It is challenging to keep track of the available options and avoid possible pitfalls in the TLS configuration. During the development of your application, you will face many questions regarding the correct use of TLS, such as:

  • Which TLS versions are secure? Which cipher suites should my application support?
  • What measures can I take to improve the performance of TLS connections?
  • How can I protect against well-known TLS attacks such as DROWN, ROBOT, or BREACH?
  • Are there libraries or frameworks I should have in mind for my specific use case?

  Common tools can automatically check the TLS configurations of your finished application. This automatic analysis does not give you the same insights as a manual threat analysis performed before or during development. Automated tools are often incomprehensible and report vulnerabilities that are not always applicable to your tested application. For example, the BREACH attack is usually classified as a threat, although it is not relevant in many scenarios.

  In our individual threat analysis, by contrast, we examine which attacks and possible vulnerabilities apply to your application and how you can address them in the best possible way. You benefit from our experience as authors of numerous attacks on TLS (including DROWN, ROBOT, and Raccoon) and receive answers to your specific questions about your scenarios. We help you to select the cryptographic algorithms and security mechanisms that best protect your application and improve its performance. For example, you could use high-performance cryptographic methods, such as session tickets or the latest protocol version TLS 1.3.

With their research background, the Hackmanit professionals have state of the art knowledge in various IT security topics. Hackmanit offers you the possibility to support you with a threat analysis during your application’s planning and deployment. Hackmanit has proven its experience and expertise in past projects for various companies.

Due to confidentiality reasons, we can only provide you with a small selection of our references. Convince yourself with the publicly available analyses conducted in cooperation with Rhode und Schwarz Cybersecurity (formerly Sirrix AG) and the German Federal Office for Information Security (BSI).

• Interoperability between Messaging Services: Secure Implementation of Encryption, Bundesnetzagentur (Link, PDF)
• Secure implementation of a general crypto library, Federal Office for Information Security (German, PDF)
• Source code-based investigation of cryptographically relevant aspects of the OpenSSL library, Federal Office for Information Security (German, Link)

Are you unsure whether a threat analysis is the right procedure for you? We would be pleased to discuss individual options for evaluating your planned application’s security in a non-binding meeting.

Your Contact for Threat Analysis

Prof. Dr. Juraj Somorovsky
juraj.somorovsky@hackmanit.de