#php

Zend_View is a component that utilizes PHP as a templating language. To utilize it, you specify "script paths" that contain view scripts, and then `render()` view scripts by specifying subdirectories within those script paths; the output is then returned as a string value which may be cached or directly output. `Zend_View::setScriptPath()` in versions up to and including 1.7.4 include a potential Local File Inclusion vulnerability. If untrusted input is used to specify the script path and/or view script itself, a malicious attacker could potentially specify a system directory and thus render a system file. As an example, if the user-supplied string `/etc/passwd` or a relative path that resolved to that file, was supplied to `Zend_View::render()`, that file would be rendered.

zend-diactoros (and, by extension, Expressive), zend-http (and, by extension, Zend Framework MVC projects), and zend-feed (specifically, its PubSubHubbub sub-component) each contain a potential URL rewrite exploit. In each case, marshaling a request URI includes logic that introspects HTTP request headers that are specific to a given server-side URL rewrite mechanism. When these headers are present on systems not running the specific URL rewriting mechanism, the logic would still trigger, allowing a malicious client or proxy to emulate the headers to request arbitrary content.

`Zend\Debug`, `Zend\Feed\PubSubHubbub`, `Zend\Log\Formatter\Xml`, `Zend\Tag\Cloud\Decorator`, `Zend\Uri`, `Zend\View\Helper\HeadStyle, Zend\View\Helper\Navigation\Sitemap`, and `Zend\View\Helper\Placeholder\Container\AbstractStandalone` were not using `Zend\Escaper` when escaping HTML, HTML attributes, and/or URLs. While most were performing some escaping, because they were not using context-appropriate escaping mechanisms, they could potentially be exploited to perform Cross Site Scripting (XSS) attacks.

`Zend\Session\Validator\RemoteAddr` and `Zend\View\Helper\ServerUrl` were found to be improperly parsing HTTP headers for proxy information, which could potentially allow an attacker to spoof a proxied IP or host name. In `Zend\Session\Validator\RemoteAddr`, if the client is behind a proxy server, the detection of the proxy URL was incorrect, and could lead to invalid results on subsequent lookups. In `Zend\View\Helper\ServerUrl`, if the server lives behind a proxy, the helper would always generate a URL based on the proxy host, regardless of whether or not this was desired; additionally, it did not take into account the proxy port or protocol, if provided.

In Zend Framework, `Zend_Captcha_Word` (v1) and `Zend\Captcha\Word` (v2) generate a "word" for a CAPTCHA challenge by selecting a sequence of random letters from a character set. Prior to this advisory, the selection was performed using PHP's `internal array_rand()` function. This function does not generate sufficient entropy due to its usage of `rand()` instead of more cryptographically secure methods such as `openssl_pseudo_random_bytes()`. This could potentially lead to information disclosure should an attacker be able to brute force the random number generation.

The `Zend\Db` component in Zend Framework 2 provides platform abstraction, which is used in particular for SQL abstraction. Two methods defined in the platform interface, `quoteValue()` and `quoteValueList()`, allow users to manually quote values for creating SQL statements; these are in turn consumed by aspects of the SQL abstraction platform, including `Zend\Db\Sql\Sql::getSqlStringForSqlObject()`, and the `getSqlString()` method provided in a number of classes in the Zend\Db\Sql namespace. While these methods are primarily intended for debugging and logging purposes, developers can use them to produce SQL that is then passed to the driver to execute. Due to a flaw in how the `quoteValue()` and `quoteValueList()` methods were written, this can lead to potential SQL injection. The offending code is located in any of the `Zend\Db\Adapter\Platform*` objects, particularly the quoteValue() and `quoteValueList()` methods. These methods did not take into account most of the possible escap...

Numerous components utilizing PHP's DOMDocument, SimpleXML, and xml_parse functionality are vulnerable to two types of attacks: - XML eXternal Entity (XXE) Injection attacks. The above mentioned extensions are insecure by default, allowing external entities to be specified by adding a specific DOCTYPE element to XML documents and strings. By exploiting this vulnerability an application may be coerced to open arbitrary files and/or TCP connections. - XML Entity Expansion (XEE) vectors, leading to Denial of Service vectors. XEE attacks occur when the XML DOCTYPE declaration includes XML entity definitions that contain either recursive or circular references; this leads to CPU and memory consumption, making Denial of Service exploits trivial to implement.

In Zend Framework 2, the `Zend\Math\Rand` component generates random bytes using the OpenSSL or Mcrypt extensions when available but will otherwise use PHP's `mt_rand()` function as a fallback. All outputs from `mt_rand()` are predictable for the same PHP process if an attacker can brute force the seed used by the Marsenne-Twister algorithm in a Seed Recovery Attack. This attack can be successfully applied with minimum effort if the attacker has access to either a random number from `mt_rand()` or a Session ID generated without using additional entropy. This makes `mt_rand()` unsuitable for generating non-trivial random bytes since it has Insufficient Entropy to protect against brute force attacks on the seed. The `Zend\Validate\Csrf` component generates CSRF tokens by SHA1 hashing a salt, random number possibly generated using `mt_rand()` and a form name. Where the salt is known, an attacker can brute force the SHA1 hash with minimum effort to discover the random number when `mt_rand...

`Zend\Session` session validators do not work as expected if set prior to the start of a session. For instance, the following test case fails (where `$this->manager` is an instance of `Zend\Session\SessionManager`): ``` $this ->manager ->getValidatorChain() ->attach('session.validate', array(new RemoteAddr(), 'isValid')); $this->manager->start(); $this->assertSame( array( 'Zend\Session\Validator\RemoteAddr' =3D> '', ), $_SESSION['__ZF']['_VALID'] ); ``` The implication is that subsequent calls to `Zend\Session\SessionManager#start()` (in later requests, assuming a session was created) will not have any validator metadata attached, which causes any validator metadata to be re-built from scratch, thus marking the session as valid. An attacker is thus able to simply ignore session validators such as RemoteAddr or HttpUserAgent, since the "signature" that these validators check against is not being stored in the session.

In Zend Framework 2, `Zend\Mvc\Router\Http\Query` is used primarily to allow appending query strings to URLs when assembled. However, due to the fact that it captures any query parameters into the RouteMatch, and the fact that RouteMatch parameters are merged with any parent routes, this can lead to overriding already captured routing parameters, bypassing constraints defined in the parents. As an example, consider the following route definition: ``` array( 'user' => array( 'type' => 'segment', 'options' => array( 'route' => '/user/:key', 'defaults' => array( 'controller' => 'UserController', 'action' => 'show-action', ), 'constraints' => array( 'key' => '[a-z0-9]+', ), ), 'child_routes' => array( 'query' => array('type' => 'query'), ), ), ) ``` If the request URI was /user/foo/?controller=SecretController&key=inval...