/ 
YATT-Lite-0.0_7
/ YATT::Lite::WebMVC0::SiteApp
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

YATT::Lite::WebMVC0::SiteApp - PSGI Handler for yatt

SYNOPSIS

# In app.psgi

use FindBin;
use YATT::Lite::WebMVC0::SiteApp -as_base;
use YATT::Lite qw/Entity *CON/;

return do {

  my $site = MY->new(doc_root => "$FindBin::Bin/html");

  #----- You can define entities here. ----
  Entity session => sub {
    my ($this, $key) = @_;
    my $sess = $CON->get_session
      or return;
    $sess->param($key);
  };

  if (YATT::Lite::Factory->want_object) {

    # When app.psgi is loaded from yatt support scripts(eg. yatt lint),
    # return bare object, not app.

    $site;

  } else {

    # Otherwise, normal PSGI. You can use Plack::Builder and/or middleware.

    $site->to_app;
  }
};

DESCRIPTION

SiteApp is a Factory of DirApp, which is a web specific subclass of YATT::Lite.

SiteApp takes a template directory tree at startup and becomes a PSGI application.

When SiteApp called for incoming request, it first determins a sub-directory for the request. Then SiteApp looks for DirApp from own cache, load/build it when necessary, and finally invoke DirApp to handle do rest of work.

CONFIGS

SiteApp accepts YATT::Lite::Object style configurations.

doc_root

Document root of this PSGI application. *.yatt should be placed under this. Usually, $FindBin::Bin/html

app_ns

Namespace of per-directory YATT::Lite class. Default is MyApp. This will also be used as a base class of each YATT::Lite instances. This class will be loaded at startup (but can be missing). If it exists, it must be a subclass of YATT::Lite.

app_root

The application directory where app.psgi lives in. Sometime omissible, but recommended to set as $FindBin::Bin.

app_base

Base DirApp for all DirApp under doc_root. A.k.a inheritance of app-directory. Omissible. Usually, $FindBin::Bin/ytmpl.

site_prefix

If your app.psgi is located under subpath, specify this. You can refer this from *.yatt via &yatt:site_prefix();.

header_charset

Default charset for HTTP response headers. Default is utf-8.

tmpl_encoding, output_encoding

Encoding of *.yatt and HTTP response body, respectively.

XXX: should note about widechars....

no_nested_query

By default, yatt turns specific parameters into hashes/arrays like PHP and Ruby on Rails. This feature is useful(I hope), but is experimental. So if you don't want this feature, turn this config on.

psgi_static

Requests other than *.yatt, *.ytmpl, *.ydo are passed to this PSGI app. Default is:

Plack::App::File->new(root => $self->{cf_doc_root})->to_app

backend

Room for your Model instance. If it is given and it has startup method is implemented, $backend->startup($siteapp, @all_dirapps) will be called when prepare_app.

METHODS

call($env)

PSGI entry function. SiteApp uses $env as following:

PATH_TRANSLATED, REDIRECT_STATUS

If $env->{REDIRECT_STATUS} is 200 and has non empty $env->{PATH_TRANSLATED}, yatt tries to serve specified path.

PATH_INFO

Otherwise, yatt examines $env->{PATH_INFO} under doc_root and app_base, in this order.

prepare_app

PSGI startup hook.

render($path_info, $args)

Aid for batch execution.

make_connection($parent_fh, @config)

Build helper for YATT::Lite::WebMVC0::Connection object. $parent_fh can be undef. If specified, $con->flush will flush buffered contents to $parent_fh.

HOOKS

before_dirhandler($dirapp, $connection, $filename)