medialize · Jul 11, 2021 · Jul 11, 2021 · Jul 11, 2021 · Jul 11, 2021 · Jul 11, 2021
diff --git a/.jshintrc b/.jshintrc
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -2,6 +2,13 @@
 
 The release notes tracked in this document are also made available on the [releases page](https://github.com/medialize/URI.js/releases)
 
+### 1.19.7 (July 14th 2021) ###
+
+* **SECURITY** fixing [`URI.parseQuery()`](http://medialize.github.io/URI.js/docs.html#static-parseQuery) to prevent overwriting `__proto__` in parseQuery() - disclosed privately by @NewEraCracker
+* **SECURITY** fixing [`URI.parse()`](http://medialize.github.io/URI.js/docs.html#static-parse) to handle variable amounts of `\` and `/` in scheme delimiter as Node and Browsers do - disclosed privately by [ready-research](https://github.com/ready-research) via https://huntr.dev/
+* removed obsolete build tools
+* updated jQuery versions (verifying compatibility with 1.12.4, 2.2.4, 3.6.0)
+
 ### 1.19.6 (February 13th 2021) ###
 
 * **SECURITY** fixing [`URI.parse()`](http://medialize.github.io/URI.js/docs.html#static-parse) to rewrite `\` in scheme delimiter to `/` as Node and Browsers do - disclosed privately by [Yaniv Nizry](https://twitter.com/ynizry) from the CxSCA AppSec team at Checkmarx

diff --git a/Gruntfile.js b/Gruntfile.js
diff --git a/SECURITY.md b/SECURITY.md
@@ -0,0 +1,12 @@
+# Security Policy
+
+## Supported Versions
+
+| Version | Supported          |
+| ------- | ------------------ |
+| 1.19.x   | :white_check_mark: |
+| < 1.19.0 | :x:                |
+
+## Reporting a Vulnerability
+
+Please ping the maintainer privately at mail+github@rodneyrehm.de :)
diff --git a/about-uris.html b/about-uris.html
@@ -5,8 +5,8 @@
     <meta http-equiv="content-type" content="text/html; charset=utf-8" />
     <title>URI.js - About URIs</title>
     <meta name="description" content="URI.js is a Javascript library for working with URLs." />
-    
-    <script src="jquery-1.9.1.min.js" type="text/javascript"></script>
+
+    <script src="jquery-3.6.0.min.js" type="text/javascript"></script>
     <script src="prettify/prettify.js" type="text/javascript"></script>
     <script src="screen.js" type="text/javascript"></script>
     <link href="screen.css" rel="stylesheet" type="text/css" />
@@ -28,10 +28,10 @@
 </head>
 <body>
     <a id="github-forkme" href="https://github.com/medialize/URI.js"><img src="http://s3.amazonaws.com/github/ribbons/forkme_right_darkblue_121621.png" alt="Fork me on GitHub" /></a>
-    
+
     <div id="container">
     <h1><a href="https://github.com/medialize/URI.js">URI.js</a></h1>
-    
+
     <ul class="menu">
         <li><a href="/URI.js/">Intro</a></li>
         <li class="active"><a href="about-uris.html">Understanding URIs</a></li>
@@ -41,14 +41,14 @@ <h1><a href="https://github.com/medialize/URI.js">URI.js</a></h1>
         <li><a href="build.html">Build</a></li>
         <li><a href="http://rodneyrehm.de/en/">Author</a></li>
     </ul>
-    
+
     <h2>Understanding URIs</h2>
-    
+
     <p>
         Uniform Resource Identifiers (URI) can be one of two things, a Uniform Resource Locator (URL) or a Uniform Resource Name (URN).
         You likely deal with URLs most of the time. See RFC 3986 for a proper definition of the terms <a href="http://tools.ietf.org/html/rfc3986#section-1.1.3">URI, URL and URN</a>
     </p>
-    
+
     <p>
         URNs <em>name</em> a resource.
         They are (supposed to) designate a globally unique, permanent identifier for that resource.
@@ -84,7 +84,7 @@ <h2>URLs and URNs in URI.js</h2>
         The most surprising result of this is that <code>mailto:</code> URLs will be considered by URI.js to be URNs rather than URLs.
         That said, the functional differences will not adversely impact the handling of those URLs.
     </p>
-    
+
     <h2 id="components">Components of an URI</h2>
     <p><a href="http://tools.ietf.org/html/rfc3986#section-3">RFC 3986 Section 3</a> visualizes the structure of <abbr title="Uniform Resource Indicator">URI</abbr>s as follows:</p>
     <pre class="ascii-art">
@@ -120,70 +120,70 @@ <h3 id="components-url">Components of an <abbr title="Uniform Resource Locator">
 </span>                                    <a href="docs.html#accessors-domain">domain</a>                   <a href="docs.html#accessors-filename">filename</a>
 
 </pre>
-    
+
     <p>
-        In Javascript the <em>query</em> is often referred to as the <em>search</em>. 
+        In Javascript the <em>query</em> is often referred to as the <em>search</em>.
         URI.js provides both accessors with the subtle difference of <a href="docs.html#accessors-search">.search()</a> beginning with the <code>?</code>-character
         and <a href="docs.html#accessors-search">.query()</a> not.
     </p>
     <p>
-        In Javascript the <em>fragment</em> is often referred to as the <em>hash</em>. 
+        In Javascript the <em>fragment</em> is often referred to as the <em>hash</em>.
         URI.js provides both accessors with the subtle difference of <a href="docs.html#accessors-hash">.hash()</a> beginning with the <code>#</code>-character
         and <a href="docs.html#accessors-hash">.fragment()</a> not.
     </p>
-    
+
     <h3 id="components-urn">Components of an <abbr title="Uniform Resource Name">URN</abbr> in URI.js</h3>
-    
+
     <pre class="ascii-art">
     urn:example:animal:ferret:nose?name=ferret#foo
 <span class="line">    \ / \________________________/ \_________/ \ /
      |               |                  |       |
 </span>  <a href="docs.html#accessors-protocol">scheme</a>       <a href="docs.html#accessors-pathname">path</a> &amp; <a href="docs.html#accessors-segment">segment</a>         <a href="docs.html#accessors-search">query</a>   <a href="docs.html#accessors-hash">fragment</a>
     </pre>
-    
+
     <p>While <a href="http://tools.ietf.org/html/rfc2141">RFC 2141</a> does not define URNs having a query or fragment component, URI.js enables these accessors for convenience.</p>
-    
+
     <h2 id="problems">URLs - Man Made Problems</h2>
-    
+
     <p>URLs (URIs, whatever) aren't easy. There are a couple of issues that make this simple text representation of a resource a real pain</p>
     <ul>
         <li>Look simple but have tricky encoding issues</li>
         <li>Domains aren't part of the specification</li>
         <li>Query String Format isn't part of the specification</li>
         <li>Environments (PHP, JS, Ruby, …) handle Query Strings quite differently</li>
     </ul>
-    
+
     <h3 id="problems-encoding">Parsing (seemingly) invalid URLs</h3>
     <p>Because URLs look very simple, most people haven't read the formal specification. As a result, most people get URLs wrong on many different levels. The one thing most everybody screws up is proper encoding/escaping.</p>
     <p><code>http://username:pass:word@example.org/</code> is such a case. Often times homebrew URL handling misses escaping the less frequently used parts such as the userinfo.</p>
     <p><code>http://example.org/@foo</code> that "@" doesn't have to be escaped according to RFC3986. Homebrew URL handlers often just treat everything between "://" and "@" as the userinfo.</p>
     <p><code>some/path/:foo</code> is a valid relative path (as URIs don't have to contain scheme and authority). Since homebrew URL handlers usually just look for the first occurence of ":" to delimit the scheme, they'll screw this up as well.</p>
     <p><code>+</code> is the proper escape-sequence for a space-character within the query string component, while every other component prefers <code>%20</code>. This is due to the fact that the actual format used within the query string component is not defined in RFC 3986, but in the HTML spec.</p>
     <p>There is encoding and strict encoding - and Javascript won't get them right: <a href="https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/encodeURIComponent#Description">encodeURIComponent()</a></p>
-    
+
     <h3 id="problems-tld">Top Level Domains</h3>
     <p>The hostname component can be one of may things. An IPv4 or IPv6 address, an IDN or Punycode domain name, or a regular domain name. While the format (and meaning) of IPv4 and IPv6 addresses is defined in RFC 3986, the meaning of domain names is not.</p>
-    <p>DNS is the base of translating domain names to IP addresses. DNS itself only specifies syntax, not semantics. The missing semantics is what's driving us crazy here.</p> 
+    <p>DNS is the base of translating domain names to IP addresses. DNS itself only specifies syntax, not semantics. The missing semantics is what's driving us crazy here.</p>
     <p>ICANN provides a <a href="http://www.iana.org/domains/root/db/">list of registered Top Level Domains</a> (TLD). There are country code TLDs (ccTLDs, assigned to each country, like ".uk" for United Kindom) and generic TLDs (gTLDs, like ".xxx" for you know what). Also note that a TLD may be non-ASCII <code>.香港</code> (IDN version of HK, Hong Kong).</p>
     <p>IDN TLDs such as <code>.香港</code> and the fact that any possible new TLD could pop up next month has lead to a lot of URL/Domain verification tools to fail.</p>
 
-    <h3 id="problems-sld">Second Level Domains</h3>    
+    <h3 id="problems-sld">Second Level Domains</h3>
     <p>To make Things worse, people thought it to be a good idea to introduce Second Level Domains (SLD, ".co.uk" - the commercial namespace of United Kingdom). These SLDs are not up to ICANN to define, they're handled individually by each NIC (Network Information Center, the orgianisation responsible for a specific TLD).</p>
     <p>Since there is no central oversight, things got really messy in this particular space. Germany doesn't do SDLs, Australia does. Australia has different SLDs than the United Kingdom (".csiro.au" but no ".csiro.uk"). The individual NICs are not required to publish their arbitrarily chosen SLDs in a defined syntax anywhere.</p>
     <p>You can scour each NIC's website to find some hints at their SLDs. You can look them up on Wikipedia and hope they're right. Or you can use <a href="http://publicsuffix.org/">PublicSuffix</a>.</p>
     <p>Speaking of PublicSuffix, it's time mentioning that browser vendors actually keep a list of known Second Level Domains. They need to know those for security issues. Remember cookies? They can be read and set on a domain level. What do you think would happen if "co.uk" was treated as the domain? <code>amazon.co.uk</code> would be able to read the cookies of <code>google.co.uk</code>. PublicSuffix also contains custom SLDs, such as <code>.dyndns.org</code>. While this makes perfect sense for browser security, it's not what we need for basic URL handling.</p>
     <p>TL;DR: It's a mess.</p>
-    
+
     <h3 id="problems-querystring">The Query String</h3>
     <p>PHP (<a href="http://php.net/manual/en/function.parse-str.php">parse_str()</a>) will automatically parse the query string and populate the superglobal <code>$_GET</code> for you. <code>?foo=1&amp;foo=2</code> becomes <code>$_GET = array('foo' => 2);</code>, while <code>?foo[]=1&amp;foo[]=2</code> becomes <code>$_GET = array('foo' => array("1", "2"));</code>.</p>
     <p>Ruby's <code>CGI.parse()</code> turns <code>?a=1&amp;a=2</code> into <code>{"a" : ["1", "2"]}</code>, while Ruby on Rails chose the PHP-way.</p>
     <p>Python's <a href="http://docs.python.org/2/library/urlparse.html#urlparse.parse_qs">parse_qs()</a> doesn't care for <code>[]</code> either.
     <p>Most other languages don't follow the <code>[]</code>-style array-notation and deal with this mess differently.</p>
     <p>TL;DR: You need to know the target-environment, to know how complex query string data has to be encoded</p>
-    
+
     <h3 id="problems-fragment">The Fragment</h3>
     <p>Given the URL <code>http://example.org/index.html#foobar</code>, browsers only request <code>http://example.org/index.html</code>, the fragment <code>#foobar</code> is a client-side thing.</p>
-    
+
     </div>
 </body>
 </html>
diff --git a/bower.json b/bower.json
@@ -1,6 +1,6 @@
 {
   "name": "urijs",
-  "version": "1.19.6",
+  "version": "1.19.7",
   "main": "src/URI.js",
   "ignore": [
     ".*",

diff --git a/build.html b/build.html
@@ -5,14 +5,14 @@
     <meta http-equiv="content-type" content="text/html; charset=utf-8" />
     <title>URI.js - Custom Build</title>
     <meta name="description" content="URI.js is a Javascript library for working with URLs." />
-    
-    <script src="jquery-1.9.1.min.js" type="text/javascript"></script>
+
+    <script src="jquery-3.6.0.min.js" type="text/javascript"></script>
     <script src="screen.js" type="text/javascript"></script>
     <script src="build.js" type="text/javascript"></script>
     <link href="screen.css" rel="stylesheet" type="text/css" />
 </head>
 <body>
-    
+
     <a id="github-forkme" href="https://github.com/medialize/URI.js"><img src="http://s3.amazonaws.com/github/ribbons/forkme_right_darkblue_121621.png" alt="Fork me on GitHub" /></a>
 
         <div id="container">
@@ -57,12 +57,12 @@ <h2>Custom Built URI.js</h2>
                 <p class="download"> your custom built <code>URI.js</code> or copy the following code:</p>
                 <textarea id="output" cols="50" rows="5" style="width: 100%; height: 200px;"></textarea>
             </div>
-            
+
             <hr>
-            
+
             <p>
                 This "build tool" does nothing but downloading the selected files, concatenating them and pushing them through <a href="http://closure-compiler.appspot.com/home">Closure Compiler</a>.
-                Since Closure Compiler is running on a different domain, this trick will only work on modern browsers. 
+                Since Closure Compiler is running on a different domain, this trick will only work on modern browsers.
                 I'm sorry for the ~2% of you IE users. You'll have to do this <a href="https://github.com/medialize/URI.js#minify">manually</a>.
             </p>
         </form>

diff --git a/build.js b/build.js
@@ -29,7 +29,7 @@ function build(files) {
             output_format: "text",
             output_info: "compiled_code"
         }, function(data) {
-            var code = "/*! URI.js v1.19.6 http://medialize.github.io/URI.js/ */\n/* build contains: " + files.join(', ') + " */\n" + data;
+            var code = "/*! URI.js v1.19.7 http://medialize.github.io/URI.js/ */\n/* build contains: " + files.join(', ') + " */\n" + data;
             $progress.hide();
             $out.val(code).parent().show();
             $out.prev().find('a').remove();

diff --git a/contributing.md b/contributing.md
@@ -13,7 +13,3 @@ Thanks for your help!
 Pull Requests go into the branch **master**. The *gh-pages* branch is a presentation of the *master* branch at the last given release.
 
 Whenever you change code, make sure you run the test suite before sending a pull request. Please add tests for any features you add to the code base. We're using [QUnit](http://qunitjs.com/) for testing.
-
-We're looking forward to splitting URI.js in several files, each dealing with a specific domain, to make the 1800 lines of code more bearable to work with. This will lead to using [Grunt](http://gruntjs.com/) to build a distributable version (and the removal of `build.html`). We're not sure when we'll get to this. If you want to pitch in, just holler!
-
-
diff --git a/docs.html b/docs.html
@@ -6,7 +6,7 @@
     <title>URI.js - API Documentation</title>
     <meta name="description" content="URI.js is a Javascript library for working with URLs." />
 
-    <script src="jquery-1.9.1.min.js" type="text/javascript"></script>
+    <script src="jquery-3.6.0.min.js" type="text/javascript"></script>
     <script src="prettify/prettify.js" type="text/javascript"></script>
     <script src="screen.js" type="text/javascript"></script>
     <link href="screen.css" rel="stylesheet" type="text/css" />
Original file line number	Diff line number	Diff line change
		@@ -13,7 +13,3 @@ Thanks for your help!
		Pull Requests go into the branch master. The gh-pages branch is a presentation of the master branch at the last given release.

		Whenever you change code, make sure you run the test suite before sending a pull request. Please add tests for any features you add to the code base. We're using [QUnit](http://qunitjs.com/) for testing.

		We're looking forward to splitting URI.js in several files, each dealing with a specific domain, to make the 1800 lines of code more bearable to work with. This will lead to using [Grunt](http://gruntjs.com/) to build a distributable version (and the removal of `build.html`). We're not sure when we'll get to this. If you want to pitch in, just holler!