/ 
UR-0.47
River stage one • 2 direct dependents • 3 total dependents
⭐ Starred 3 GitHub stars
/ UR::Env
Security Advisories (12)
CVE-2018-14041 (2018-07-13)

In Bootstrap before 4.1.2, XSS is possible in the data-target property of scrollspy.

CVE-2018-14042 (2018-07-13)

In Bootstrap before 4.1.2, XSS is possible in the data-container property of tooltip.

CVE-2020-11022 (2020-04-29)

In jQuery versions greater than or equal to 1.2 and before 3.5.0, passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.

CVE-2020-11023 (2020-04-29)

In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.

CVE-2019-11358 (2019-04-20)

jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable __proto__ property, it could extend the native Object.prototype.

CVE-2015-9251 (2018-01-18)

jQuery before 3.0.0 is vulnerable to Cross-site Scripting (XSS) attacks when a cross-domain Ajax request is performed without the dataType option, causing text/javascript responses to be executed.

CVE-2011-4969 (2013-03-08)

Cross-site scripting (XSS) vulnerability in jQuery before 1.6.3, when using location.hash to select elements, allows remote attackers to inject arbitrary web script or HTML via a crafted tag.

CVE-2012-6708 (2018-01-18)

jQuery before 1.9.0 is vulnerable to Cross-site Scripting (XSS) attacks. The jQuery(strInput) function does not differentiate selectors from HTML in a reliable fashion. In vulnerable versions, jQuery determined whether the input was HTML by looking for the '<' character anywhere in the string, giving attackers more flexibility when attempting to construct a malicious payload. In fixed versions, jQuery only deems the input to be HTML if it explicitly starts with the '<' character, limiting exploitability only to attackers who can control the beginning of a string, which is far less common.

CVE-2020-7656 (2020-05-19)

jquery prior to 1.9.0 allows Cross-site Scripting attacks via the load method. The load method fails to recognize and remove "<script>" HTML tags that contain a whitespace character, i.e: "</script >", which results in the enclosed script logic to be executed.

CVE-2019-5428

Prototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as _proto_, constructor and prototype. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the Object.prototype are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.

CVE-2014-6071 (2018-01-16)

jQuery 1.4.2 allows remote attackers to conduct cross-site scripting (XSS) attacks via vectors related to use of the text method inside after.

CVE-2018-14040 (2018-07-13)

Prototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as _proto_, constructor and prototype. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the Object.prototype are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.

NAME

UR::Env - Environment variables that control UR behavior

DESCRIPTION

UR uses several environment variables to change its behavior or provide additional debugging information.

UR_STACK_DUMP_ON_DIE <bool>

When true, has the effect of turning any die() into a Carp::confess, meaning a stack dump will be printed after the die message.

UR_STACK_DUMP_ON_WARN <bool>

When true, has the effect of turning any warn() into a Carp::cluck, meaning a stack dump will be printed after the warn message.

UR_CONTEXT_ROOT <string>

The name of the Root context to instantiate when the program initializes. The default is UR::Context::DefaultRoot. Other Root Contexts can be used, for example, to connect to alternate databases when running in test mode.

UR_CONTEXT_BASE <string>

This value only changes in a sub-process which goes to its parent process for object I/O instead of the root (which is the default value for the base context in an application).

UR_CONTEXT_CACHE_SIZE_HIGHWATER <integer>

Set the object count highwater mark for the object cache pruner. See also "object_cache_size_highwater" in UR::Context

UR_CONTEXT_CACHE_SIZE_LOWWATER <integer>

Set the object count lowwater mark for the object cache pruner. See also "object_cache_size_lowwater" in UR::Context

UR_DEBUG_OBJECT_RELEASE <bool>

When true, messages will be printed to STDERR whenever objects are removed from the object cache, such as when the object pruner marks them for removal, when they are garbage collected, unloaded, or deleted.

UR_DEBUG_OBJECT_RELEASE <bool>

When true, messages will be printed to STDERR whenever the object pruner finishes its work, and show how many objects of each class were marked for removal.

UR_CONTEXT_MONITOR_QUERY <integer>

When true (non-zero), messages will be printed as the Context satisfies queries, such as when get() is called on a class, or while processing an iterator created through SomeClass->create_iterator and iterator->next(). If the value is 1, then only queries about Non-UR classes are printed. If 2, then all queries' information is printed.

UR_DBI_MONITOR_SQL <bool>

If this is true, most interactions with data sources such as connecting, disconnecting and querying will print messages to STDERR. Same as UR::DBI->monitor_sql(). Note that this affects non-DBI data sources as well, such as file-based data sources, which will render file I/O information instead of SQL.

UR_DBI_SUMMARIZE_SQL <bool>

If true, a report will be printed to STDERR as the program finishes about what SQL queries have been done during the program's execution, and how many times they were executed. This is helpful during optimization.

UR_DBI_MONITOR_EVERY_FETCH <bool>

Used in conjunction with UR_DBI_MONITOR_SQL, tells the data sources to also print messages to STDERR for each row fetched from the underlying data source. Same as UR::DBI->monitor_every_fetch().

UR_DBI_DUMP_STACK_ON_CONNECT <bool>

Print a message to STDERR only when connecting to an underlying data source. Same as UR::DBI->dump_stack_on_connect()

UR_DBI_EXPLAIN_SQL_MATCH <string>

If the query to a data source matches the given string (interpreted as a regex), then it will attempt to do an "explain plan" and print the results before executing the query. Same as UR::DBI->explain_sql_match()

UR_DBI_EXPLAIN_SQL_SLOW <float>

If the time between a prepare and the first fetch of a query is longer than the given number of seconds, then it will do an "explain plan" and print the results. Same as UR::DBI->explain_sql_slow()

UR_DBI_EXPLAIN_SQL_CALLSTACK <bool>

Used in conjunction with UR_DBI_EXPLAIN_SQL_MATCH and UR_DBI_EXPLAIN_SQL_SLOW, prints a stack trace with Carp::longmess. Same as UR::DBI->explain_sql_callstack()

UR_DBI_MONITOR_DML <bool>

Like UR_DBI_MONITOR_SQL, but only prints information during data-altering statements, like INSERT, UPDATE or DELETE. Same as UR::DBI->monitor_dml()

UR_DBI_NO_COMMIT <bool>

If true, data source commits will be ignored. Note that saving still occurs. If you are working with a RDBMS database, this means During UR::Context->commit(), the insert, update and delete SQL statements will be issued, but the changes will not be committed. Useful for testing. Same as UR::DBI->no_commit()

UR_USE_DUMMY_AUTOGENERATED_IDS <bool>

If true, objects created without ID params will use a special algorithm to generate IDs. Objects with these special IDs will never be saved to a data source. Useful during testing. Same as UR::DataSource->use_dummy_autogenerated_ids

UR_USED_LIBS

If true, prints a message to STDERR with the contents of @INC just before the program exits.

UR_USED_MODS

If true, prints a message to STDERR with the keys of %INC just before the program exits. This will be a list of what modules had been loaded during the life of the program. If UR_USED_MODS is greater than 1, then it will show the key/value pairs of %INC, which will show the path each module was loaded from.