{"id":9824,"date":"2020-12-11T19:42:36","date_gmt":"2020-12-11T19:42:36","guid":{"rendered":"https:\/\/staging-site.42crunch.com\/?p=9824"},"modified":"2022-11-23T10:33:10","modified_gmt":"2022-11-23T10:33:10","slug":"webinar-questions-jwt-api-security","status":"publish","type":"post","link":"https:\/\/staging2022.42crunch.com\/webinar-questions-jwt-api-security\/","title":{"rendered":"Questions Answered: How to Best Leverage JWTs or API Security"},"content":{"rendered":"<div class=\"form-group horizontal\">\n<h2><strong>You had questions, and we&#8217;ve got answers!<\/strong><\/h2>\n<div>Thank you for all the questions submitted on our webinar: &#8220;<a href=\"https:\/\/staging2022.42crunch.com\/webinar-json-web-tokens-api-security\/\"><strong>How to Best Leverage JWTs or API Security<\/strong><\/a>&#8221; We were unable to get to your questions, so below are all the answers to the questions that were asked! If you&#8217;d like more information please feel free to <a href=\"https:\/\/staging2022.42crunch.com\/contact-us\/\">contact us<\/a>.<\/div>\n<\/div>\n<p>&nbsp;<\/p>\n<h5><strong>On slide 26 is the\u00a0 HS256 or RSA key used by the attacker to sign the token?<\/strong><\/h5>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-11505\" src=\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2020\/12\/slide26.jpg\" alt=\"\" width=\"1920\" height=\"1080\" srcset=\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2020\/12\/slide26.jpg 1920w, https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2020\/12\/slide26-300x169.jpg 300w, https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2020\/12\/slide26-1024x576.jpg 1024w, https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2020\/12\/slide26-768x432.jpg 768w, https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2020\/12\/slide26-1536x864.jpg 1536w\" sizes=\"(max-width: 1920px) 100vw, 1920px\" \/><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">This attack happens when you are using an asymmetric algorithm (RSA) and the attacker replaces it with a symmetric one (HMAC like HS256 in our example.)<\/span><\/p>\n<p><span style=\"font-weight: 400;\">In regular use (expected by the API implementation):<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Only the token issuer has the RSA private key and can sign the token<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Private RSA key required to validate the token is public, known to anyone who needs to validate the signature<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Attacker does not have the private RSA key and thus is not able to forge token signatures<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">To perform the attack, attacker:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Makes the token changes they want for their attack<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Change the algorithm (alg) field in the token header from asymmetric to a symmetric algorithm<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Sign the token using HMAC (symmetric) algorithm with the key that is the RSA (asymmetric) <\/span><i><span style=\"font-weight: 400;\">public <\/span><\/i><span style=\"font-weight: 400;\">key. The public key is often known because in the RSA context it is only used to verify signatures and never to create ones.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">The victim receives the API call with the forged token.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">If the victim just blindly verifies the token signature with the algorithm in the token header (which the attacker changed from RSA to HMAC!) and the same key that they have been using (the RSA public key) &#8211; that verification will succeed because HMAC is symmetric and thus the same key is supposed to be used both to sign data and to validate the signature.<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">See: <a href=\"https:\/\/www.nccgroup.com\/uk\/about-us\/newsroom-and-events\/blogs\/2019\/january\/jwt-attack-walk-through\/\">https:\/\/www.nccgroup.com\/uk\/about-us\/newsroom-and-events\/blogs\/2019\/january\/jwt-attack-walk-through\/<\/a><\/span><\/p>\n<p>&nbsp;<\/p>\n<h5><\/h5>\n<p><strong>Given its insecurity, why does the specification allow for no algorithm?\u00a0 In what use case would that be applicable?\u00a0 Just testing or is there a real-world use case for no alg?<\/strong><\/p>\n<p><span style=\"font-weight: 400;\">\u201cNone\u201d has been added to the JWT specification mainly for testing purposes and for situations in which there has been an explicit decision by the system\u2019s architects to not sign the tokens altogether.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Quoting JWT security best practices document:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u201c<\/span><span style=\"font-weight: 400;\">That said, if a JWT is cryptographically protected end-to-end by a transport layer, such as TLS using cryptographically current algorithms, there may be no need to apply another layer of cryptographic protections to the JWT. In such cases, the use of the &#8220;none&#8221; algorithm can be perfectly acceptable. The &#8220;none&#8221; algorithm should only be used when the JWT is cryptographically protected by other means. JWTs using &#8220;none&#8221; are often used in application contexts in which the content is optionally signed; then, the URL-safe claims representation and processing can be the same in both the signed and unsigned cases.<\/span><span style=\"font-weight: 400;\">\u201d<\/span><\/p>\n<p><span style=\"font-weight: 400;\">We, at 42Crunch, believe in zero trust approach toward any data coming from API clients. Tokens are especially sensitive because they serve as a foundation for authentication and authorization decisions. Thus, we believe that real-life scenarios should exclude \u201cNone\u201d, pick a proper algorithm and enforce its use. Most industry vendors follow a similar approach.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">You can read more here:\u00a0<\/span><a href=\"https:\/\/auth0.com\/blog\/critical-vulnerabilities-in-json-web-token-libraries\/\"><span style=\"font-weight: 400;\">https:\/\/auth0.com\/blog\/critical-vulnerabilities-in-json-web-token-libraries\/<\/span><\/a><\/p>\n<p>&nbsp;<\/p>\n<h5><\/h5>\n<h5><\/h5>\n<p><strong>What\u2019s the benefit for the attacker to change the algorithm? Wouldn&#8217;t changing the content break the signature anyway?<\/strong><\/p>\n<p><span style=\"font-weight: 400;\">The idea behind changing the algorithm is to enable attacker to forge the token signature:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Using \u201cNone\u201d algorithm allows to remove the signature requirement altogether<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Changing asymmetric algorithms to symmetric allows the attacker to use the known public key that the API implementation is using to verify the signature (that the attacker now creates!) and thus make the forged token valid.<\/span><\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h5><\/h5>\n<h5><\/h5>\n<p><strong>Of all the grant types, is the \u201cAuth code grant\u201d more relevant to API security and user metadata?\u00a0 What about implicit, client credentials and other types? Are they not suitable?<\/strong><\/p>\n<p><span style=\"font-weight: 400;\">We should probably do another webinar specifically on OAuth2 security best practices. The exact grant type to be used depends on the scenario, however, <\/span><span style=\"font-weight: 400;\">Implicit grant and Resource Owner Password Credentials grant are no longer considered secure and should not be used.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Other notable OAuth2 current security best practices are:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">PKCE is required for all OAuth clients using the authorization code flow<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Redirect URIs must be compared using exact string matching<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Bearer token usage omits the use of bearer tokens in the query string of URIs<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Refresh tokens for public clients must either be sender-constrained or one-time use<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">See current OAuth2.1 draft for details on the current OAuth security recommendations: <\/span><a href=\"https:\/\/tools.ietf.org\/html\/draft-ietf-oauth-v2-1-00\"><span style=\"font-weight: 400;\">https:\/\/tools.ietf.org\/html\/draft-ietf-oauth-v2-1-00<\/span><\/a><span style=\"font-weight: 400;\">\u00a0<\/span><\/p>\n<p>&nbsp;<\/p>\n<h5><\/h5>\n<h5><\/h5>\n<p><strong>Can you have specific validations per API so you know specifically what aud is allowed per API?<\/strong><\/p>\n<p><span style=\"font-weight: 400;\">Yes, 42Crunch allows to define audience and other JWT requirements on a per API level.<\/span><\/p>\n<p>&nbsp;<\/p>\n<h5><\/h5>\n<h5><\/h5>\n<p><strong>What is the deployment model for the 42Crunch firewall which protects against these JWT attacks? Does it deploy like a gateway or closer to the application?<\/strong><\/p>\n<p><span style=\"font-weight: 400;\">42Crunch firewall can be deployed both in a central gateway-style mode and as a sidecar proxy within the same pod as the microservice implementing the API.<\/span><\/p>\n<p>&nbsp;<\/p>\n<h5><\/h5>\n<h5><\/h5>\n<p><strong>At the last bit, these terms were used \u201cexchange OPAQUE TOKENS with a REAL JWT TOKEN\u201d \u201cdon\u2019t send FULL TOKENS\u201d \u2014- can you expand again what the differences with those tokens.<\/strong><\/p>\n<p><span style=\"font-weight: 400;\">Opaque token is an identifier that can be used to retrieve full information about the caller. The API implementation then does not decode the token but rather is using it to retrieve information from some sort of an internal database or service.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Real JWT \/ full tokens are the JWT tokens we covered in the webinar. This is an encoded JSON structure with the actual information about the caller. Anyone decoding that token can get information contained in the token. Thus, unencrypted JWT tokens containing sensitive information should not be used in situations when the token is available to client applications and thus potentially in the attacker&#8217;s hands.<\/span><\/p>\n<p>&nbsp;<\/p>\n<div class=\"form-group horizontal\"><\/div>\n<div class=\"form-group horizontal\">\n<div class=\"form-group horizontal\">\n<p>&nbsp;<\/p>\n<p>Try our <a href=\"https:\/\/42crunch.com\/tools\/free-audit\/\">security audit<\/a> for free. If you want to see the whole platform in action, <a href=\"https:\/\/42crunch.com\/request-demo\/\">request a demo now<\/a>!<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>You had questions, and we&#8217;ve got answers! Thank you for all the questions submitted on our webinar: &#8220;How to Best Leverage JWTs or API Security&#8221; We were unable to get to your questions, so below are all the answers to the questions that were asked! If you&#8217;d like more information please feel free to contact [&hellip;]<\/p>\n","protected":false},"author":13,"featured_media":11342,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"none","_seopress_titles_title":"How to Best Leverage JWTs for API Security - Q &amp; A","_seopress_titles_desc":"Questions and answers related to our recent API security webinar on &quot;How to Best Leverage JWTs for API Security&quot;.\r\n","_seopress_robots_index":"","site-sidebar-layout":"default","site-content-layout":"default","ast-site-content-layout":"","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"disabled","ast-hfb-above-header-display":"disabled","ast-hfb-below-header-display":"disabled","ast-hfb-mobile-header-display":"disabled","site-post-title":"disabled","ast-breadcrumbs-content":"disabled","ast-featured-img":"disabled","footer-sml-layout":"disabled","theme-transparent-header-meta":"default","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[6],"tags":[16,15,40],"class_list":["post-9824","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-api-security-training","tag-api-vulnerabilities","tag-jwt"],"_links":{"self":[{"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/posts\/9824"}],"collection":[{"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/comments?post=9824"}],"version-history":[{"count":0,"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/posts\/9824\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/media\/11342"}],"wp:attachment":[{"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/media?parent=9824"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/categories?post=9824"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/tags?post=9824"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}