Common Settings

Include Patterns: org/apache/**,com/acme/** Exclude Patterns: com/acme/exp-project/**

Avoiding Security Risks with an Exclude Pattern

This section explains how to use Exclude Patterns to avoid the following security risks.

防止接触国际米兰nal Artifacts Using Exclude Patterns

Any proprietary artifacts you deploy to Artifactory are stored within local repositories so that they are available for secured and authorized internal use.

Anyone searching for one of your internal artifacts by name will extract it through Artifactory from the local repository.

However, consider what happens if a request for an internal artifact is inadvertently directedoutsideof the organization.

Two examples of how this could happen are:

• there is a simple typo in the requested artifact name
• the developer has requested a snapshot with a version number that does not exist.

In this case, since Artifactory does not find the requested artifact in a local repository, it continues to search through the remote repositories defined in the system. Artifactory will, in fact, search throughallthe remote repositories defined in your system before returning "Not found".

This presents a security risk since any request made on a remote repository may be loggedexposing all details of the query including the full artifact name which may include sensitive business information.

防止接触国际米兰nal Packages Using Exclude Patterns

Proxying a public remote repository that is not a trusted repository or is compromised can expose you to malicious artifacts. Sometimes these repositories allow anyone to deploy custom packages. For example, for npm, the public repository isnpmjs, and anyone can deploy any version of any package he/she is the owner of. If a package does not have an owner (no one has previously deployed a version of it) anyone can deploy it and claim it.

For example, let's assume you have a library called "almo-common-utils"它的源代码公开,如果instance, it is bundled as part of publicly accessible products or web applications, it’s written in Node and JFrog Artifactory has a set of remote (proxying the public repository), local (for sharing modules internally), and virtual repositories.

Consider the following:

• In a public repository, anyone can publish an unscoped library and call it whatever they want, i.e. "almo-common-utils"(unless there is a name conflict).
• There is no package named "almo-common-utils"in the public repository (because it’s an internal corporate library), so there is no name conflict.
• You have projects declaring adependencyon "almo-common-utils使用一个版本范围”。例如,一系列规范ifying the latest version compatible with a major version.

This presents a security risk, as an attacker can try to attack an unprotected organization by just having prior knowledge of the library "almo-common-utils\", the major version of the library in use (let’s say they know version 3 is used widely in the organization), and the content of the source code.

An attacker can clone and modify the source, embedding any malware inside, but still maintain compatibility with the original code, and upload it to the repository as "almo-common-utils:3.99.99". This will create a version update hijacking of an internal library, when "almo-common-utils:^3.0.0" is requested, the fake "almo-common-utils" from the repository is fetched.

To avoid exposing internal packages and internal packages version hijacking, we strongly recommend the following:

• Use exclude patterns on your remote repositories.Exclude the packages you do not want to search outside the organization in the remote repository. You can exclude by prefix (.npm/almo*/**), by scope (.npm/@almo/*) or by name (.npm/almo-encoder/**). By setting these exclude patterns on any public remote repository, you are effectively not merging those packages from the public repositories.
• Only create and publish scoped packages.Register an official organization for your company in the public repository to own a scope for your organization, and always publish only scoped packages. This also simplifies the exclude patterns, as you only need to exclude scoped packagesto exclude all the packages from being searched in remote repositories.
  
  Here is an example of blocking packages withthe scope "almo"from a remote repository.
  

Avoiding Performance Issues with an Include Pattern

In a typical scenario, Artifactory will reference large all-purpose repositories such asJCenteror Maven Central for resolving artifacts.

In addition, Artifactory may reference any number of additional repositories which may host a more specialized and specific set of of artifacts.

If Artifactory receives a request for a deterministic set of artifacts (e.g. a specific version of an artifact), then it searches through the different repositories according to its resolution order until the artifact is found.

However, if Artifactory receives a request for a non-deterministic set of artifacts ( e.g. all versions ofmaven-metadata.xml) then it must search throughallof the repositories it references until it can provide a complete response.

In most cases, the majority of artifacts downloaded by an organization will come from one of the large all-purpose repositories, but in non-deterministic requestsperformance is downgraded because Artifactory continues to search through all the specialized repositoriesbefore it can return a response.

Local and Remote Repositories

In addition to the settings above, Local and Remote repositories share the following settings in the type-specific section for relevant package types.