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::Object::View - a base class for "views" of UR::Objects

SYNOPSIS

$object = Acme::Product->get(1234);

## Acme::Product::View::InventoryHistory::Gtk2

$view = $object->create_view(
  perspective         => 'inventory history',
  toolkit             => 'gtk2',              
);
$widget = $view->widget();    # returns the Gtk2::Widget itself directly
$view->show();                # puts the widget in a Gtk2::Window and shows everything

##

$view = $object->create_view(
  perspective         => 'inventory history',
  toolkit             => 'xml',              
);
$widget = $view->widget();    # returns an arrayref with the xml string reference, and the output filehandle (stdout) 
$view->show();                # prints the current xml content to the handle

$xml = $view->content();     # returns the XML directly

##

$view = $object->create_view(
  perspective         => 'inventory history',
  toolkit             => 'html',              
);
$widget = $view->widget();    # returns an arrayref with the html string reference, and the output filehandle (stdout) 
$view->show();                # prints the html content to the handle

$html = $view->content();     # returns the HTML text directly

USAGE API

create

The constructor requires that the subject_class_name, perspective, and toolkit be set. Most concrete subclasses have perspective and toolkit set as constant.

Producing a view object does not "render" the view, just creates an interface for controlling the view, including encapsualting its creation.

The subject can be set later and changed. The aspects viewed may be constant for a given perspective, or mutable, depending on how flexible the of the perspective logic is.

show

For stand-alone views, this puts the view widget in its a window. For views which are part of a larger view, this makes the view widget visible in the parent.

hide

Makes the view invisible. This means hiding the window, or hiding the view widget in the parent widget for subordinate views.

show_modal

This method shows the view in a window, and only returns after the window is closed. It should only be used for views which are a full interface capable of closing itself when done.

widget

Returns the "widget" which renders the view. This is built lazily on demand. The actual object type depends on the toolkit named above. This method might return HTML text, or a Gtk object. This can be used directly, and is used internally by show/show_modal.

(Note: see UR::Object::View::Toolkit::Text for details on the "text" widget, used by HTML/XML views, etc. This is just the content and an I/O handle to which it should stream.)

delete

Delete the view (along with the widget(s) and infrastructure underlying it).

CONSTRUCTION PROPERTIES (CONSTANT)

The following three properties are constant for a given view class. They determine which class of view to construct, and must be provided to create().

subject_class_name

The class of subject this view will view. Constant for any given view, but this may be any abstract class up-to UR::Object itself.

perspective

Used to describe the layout logic which gives logical content to the view.

toolkit

The specific (typically graphical) toolkit used to construct the UI. Examples are Gtk, Gkt2, Tk, HTML, XML.

CONFIGURABLE PROPERTIES

These methods control which object is being viewed, and what properties of the object are viewed. They can be provided at construction time, or afterward.

subject

The particular "model" object, in MVC parlance, which is viewed by this view. This value may change

aspects / add_aspect / remove_aspect

Specifications for properties/methods of the subject which are rendered in the view. Some views have mutable aspects, while others merely report which aspects are revealed by the perspective in question.

An "aspect" is some characteristic of the "subject" which is rendered in the view. Any property of the subject is usable, as is any method.

IMPLEMENTATION INTERFACE

When writing new view logic, the class name is expected to follow a formula:

Acme::Rocket::View::FlightPath::Gtk2
\          /           \    /      \
subject class name    perspective  toolkit

The toolkit is expected to be a single word. The perspective is everything before the toolkit, and after the last 'View' word. The subject_class_name is everything to the left of the final '::View::'.

There are three methods which require an implementation, unless the developer inherits from a subclass of UR::Object::View which provides these methods:

_create_widget

This creates the widget the first time ->widget() is called on a view.

This should be implemented in a given perspective/toolkit module to actually create the GUI using the appropriate toolkit.

It will be called before the specific subject is known, so all widget creation which is subject-specific should be done in _bind_subject(). As such it typically only configures skeletal aspects of the view.

_bind_subject

This method is called when the subject is set, or when it is changed, or unset. It updates the widget to reflect changes to the widget due to a change in subject.

This method has a default implementation which does a general subscription to changes on the subject. It probably does not need to be overridden in custom views. Implementations which _do_ override this should take an undef subject, and be sure to un-bind a previously existing subject if there is one set.

_update_view_from_subject

If and when the property values of the subject change, this method will be called on all views which render the changed aspect of the subject.

_update_subject_from_view

When the widget changes, it should call this method to save the UI changes to the subject. This is not applicable to read-only views.

OTHER METHODS

_toolkit_package

This method is useful to provide generic toolkit-based services to a view, using a toolkit agnostic API. It can be used in abstract classes which, for instance, want to share logic for a given perspective across toolkits.

The toolkit class related to a view is responsible for handling show/hide logic, etc. in the base UR::Object::View class.

Returns the name of a class which is derived from UR::Object::View::Toolkit which implements certain utility methods for views of a given toolkit.

EXAMPLES

$o = Acme::Product->get(1234);

$v = Acme::Product::View::InventoryHistory::HTML->create(); $v->add_aspect('outstanding_orders'); $v->show;