Javascript let keyword

ECMAScript 6 (ES2015) added the ‘let’ keyword. let works a lot like the legacy ‘var’ keyword, but adds scoping capabilities.

Unfortunately, support cannot be retrofitted to older browsers with a polyfill, supported by IE11(with limitations), Edge 12+, Firefox 44+, Chrome 49+, Safari 10+. If you still need to support older browsers or devices you may want to stick with var.

REFERENCES:

Javascript const

Formally introduced in ES6, const was introduced in JavaScript 1.5 and was a Mozilla-specific extension and not part of ECMAScript 5.

Unfortunately, support cannot be retrofitted to older browsers with a polyfill, supported by IE11+, Edge 12+, Firefox 36+, Chrome 21+, Safari 5.1+. If you still need to support older browsers or devices you may want to stick with var.

NOTE: some initial implementations may have thrown different exceptions on reassignment, were not limited in scope, or treated const like ‘var‘.

Name may start with letter, underscore or $ character.

REFERENCES:

RetireJS for Eclipse extension

Several years ago I wrote an Eclipse plugin to help me identify vulnerable javascript libraries using RetireJS. On a whim, I finally got around to submitting it to the Eclipse marketplace last week and it was approved.

This addresses a common OWASP Top-Ten item – A9:2017-Using Components with Known Vulnerabilities.

For Non-Developers… in English, while software developers are creating websites they often use open-source libraries such as jQuery (or literally thousands of other libraries) to simplify their development. Eventually, almost all software is identified as being vulnerable to various attacks. This tool makes it easier to scan and report on libraries that might be used in an application so that they can be updated or replaced.

REFERENCES:

Minify .js files during Maven builds

Minifying files for use on the web is essential to improving performance, to reduce network overhead as well as a slight bump in execution speed.

Long ago I used the YUICompressor plugin for both JS as well as CSS files, unfortunately that project appears to have been abandoned many years ago and no longer functions well for JS files that make use of modern features.

For JS files, I’ve found that most capabilities can be replicated with the following in the pom.xml:

<plugin>
<groupId>com.github.blutorange</groupId>
<artifactId>closure-compiler-maven-plugin</artifactId>
<version>2.21.0</version>
<executions>
<execution>
<id>default-minify-js</id>
<phase>generate-resources</phase>
<configuration>
<!-- not supported (always uses .min) <suffix>-min</suffix> -->
<encoding>UTF-8</encoding>
<baseSourceDir>${basedir}/${webapp-folder}</baseSourceDir>
<baseTargetDir>${webapp.path}/</baseTargetDir>
<sourceDir>js</sourceDir>
<targetDir>js</targetDir>
<skipMerge>true</skipMerge>
<includes>
<include>**/*.js</include>
</includes>
<excludes>
<exclude>**/webjars-requirejs.js</exclude>
<exclude>**/bootstrap*.*</exclude>
<exclude>**/jasmine*.*</exclude>
<exclude>**/*-min.js</exclude>
<exclude>**/*.min.js</exclude>
</excludes>
</configuration>
<goals>
<goal>minify</goal>
</goals>
</execution>
</executions>
</plugin>

NOTE: the only feature I have not yet been able to match is the suffix, as it appears to always use *.min.js (where I used to prefer *-min.js).

An additional advantage of using the plugin is that many common syntax errors will be identified at build time, before they cause user problems… but they will also break your build!

REFERENCES:

Minify .css files during Maven builds

Minifying files for use on the web is essential to improving performance, to reduce network overhead as well as a slight bump in execution speed.

Long ago I used the YUICompressor plugin for both JS as well as CSS files, unfortunately that project appears to have been abandoned many years ago but is still effective for CSS even if it is less useful for modern JS.

NOTE: default extension uses -min, to change it set property ‘maven.yuicompressor.suffix’ to the desired value, such as .min to match GCC used for JS.

For CSS files, you can use following in the pom.xml (JS is also possible if you are not using ES6 features):

<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>yuicompressor-maven-plugin</artifactId>
<version>1.5.1</version>
<executions>
<execution>
<id>compressyui-min</id>
<phase>prepare-package</phase>
<goals>
<goal>jslint</goal>
<goal>compress</goal>
</goals>
</execution>
</executions>
<configuration>
<nosuffix>false</nosuffix><!-- false will create -min versions, true does not -->
<warSourceDirectory>${basedir}/${webapp-folder}</warSourceDirectory>
<webappDirectory>${webapp.path}/</webappDirectory>
<jswarn>false</jswarn>
<gzip>false</gzip><!-- create .min.gz files -->
<nocompress>false</nocompress>
<force>true</force>
<excludes>
<exclude>**/*.js</exclude><!-- YUI cannot handle ES6 const let, use closure-compiler instead -->
<exclude>${webjars-output.path}*.*</exclude>
<exclude>**/webjars-requirejs.js</exclude>
<exclude>**/bootstrap*.*</exclude>
<exclude>**/jasmine*.*</exclude>
<exclude>**/*-min.css</exclude>
<exclude>**/*.min.css</exclude>
</excludes>
</configuration>
</plugin>

REFERENCES:

Stanford Javascript Crypto Library (SJCL) JavaScript encryption

I found this while looking for a means to do some simple encryption in Javascript for a browser based application. With open-source support for AES and other protocols, it is quite robust and fast.

As a bonus, it is packaged as a webjar and available in Maven Central:

<dependency>
<groupId>org.webjars.npm</groupId>
<artifactId>sjcl</artifactId>
<version>1.0.6</version>
</dependency>

REFERENCES:

Redirect within a javascript file

There often comes a time when you are working on a large project and find a need to refactor javascript resources. Unfortunately, if those assets are accessed by 3rd parties or other code you cannot easily update, you might find yourself stuck.

If you have access to the Tier1 (HTTP server such as ApacheHTTPd) you can often do this within the httpd.conf, or an .htaccess file update. If not, you can always do a simple function within the old javascript file itself, such as the one below.

Put this in the old javascript file location, it is in a closure to prevent the variables from “leaking” into the global namespace.


/* MOVED */
(function(){
"use strict";
var u='/js/newfile.js';
var t=document.createElement('script');t.type='text/javascript';t.src=u;
var s=document.getElementsByTagName('script')[0];s.parentNode.insertBefore(t,s);
})();

Brotli Compression

If you look at HTTP Headers as often as I do, you’ve likely noticed something different in Firefox 44 and Chrome 49. In addition to the usual ‘gzip’, ‘deflate’ and ‘sdhc’ , a new value ‘br’ has started to appear for HTTPS connections.

Request:

Accept-Encoding:br

Response:

Content-Encoding:br

Compared to gzip, Brotli claims to have significantly better (26% smaller) compression density woth comparable decompression speed.

The smaller compressed size allows for better space utilization and faster page loads. We hope that this format will be supported by major browsers in the near future, as the smaller compressed size would give additional benefits to mobile users, such as lower data transfer fees and reduced battery use.

Advantages:

  • Brotli outperforms gzip for typical web assets (e.g. css, html, js) by 17–25 %.
  • Brotli -11 density compared to gzip -9:
  • html (multi-language corpus): 25 % savings
  • js (alexa top 10k): 17 % savings
  • minified js (alexa top 10k): 17 % savings
  • css (alexa top 10k): 20 % savings


NOTE: Brotli is not currently supported Apache HTTPd server (as of 2016feb10), but will likely be added in an upcoming release.

http://mail-archives.apache.org/mod_mbox/httpd-users/201601.mbox/%[email protected]%3E

Until there is native support, you can pre-compress files by following instructions here…
https://lyncd.com/2015/11/brotli-support-apache/

REFERENCES:

RetireJS javascript libary vulnerability scanning with Maven

It’s important to note that even though your site is using a vulnerable library, that does not necessarily mean your site is vulnerable. It depends on whether and how your site exercises
the vulnerable code. That said, it’s better to be safe than sorry.

I identified this method of using the asset after reading the instructions for the Burp/Gulp scanner from h3xstream after the following section caught my eye:
https://github.com/h3xstream/burp-retire-js#maven-plugin-, it contained a small reference to Maven and even showed output but no configuration for use. A couple of attempts later I came up with the following:

Add to pom.xml:

<build>
<plugins>
<plugin>
<groupId>com.h3xstream.retirejs</groupId>
<artifactId>retirejs-maven-plugin</artifactId>
<version>2.1.0</version>
<executions>
<execution>
<id>scanProjectJavascript</id>
<phase>install</phase>
<goals>
<goal>scan</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

After adding this to your pom.xml, the console output for each build will contain information regarding each vulnerable JavaScript library.

One small problem exists in the current version, use behind corporate firewalls can often be blocked, resulting in an error in the console and use of an older version of the vulnerability library to be used in scans.

Error example:

[ERROR] Exception while loading the repository (Most likely unable to access the internet) java.net.UnknownHostException: raw.githubusercontent.com

See the following for updates:
https://github.com/h3xstream/burp-retire-js/issues/8

See https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities.

REFERENCES:

Install Google mod_pagespeed for Apache HTTP

Website network performance is usually a very complicated process. Over the years, I’ve outlined many development techniques that can be used toward this goal. I’d heard about mod_pagespeed for some time, but never had the opportunity to experiment with it until recently. My first impression is that it is a VERY EASY means to gain performance improvements without reworking your existing website to implement techniques for establishing far-future expires, cache-busting, minification and static file merging.

Out of the box, most common techniques are automatically applied to your assets and a local server cache is created to utilize them.

Default installation is trivial:

  1. Download the latest version for your server architecture:

    wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_amd64.deb

    OR

    wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_i386.deb

  2. sudo dpkg -i mod-pagespeed-*.deb

  3. sudo apt-get -f install
    (if required)

  4. sudo service apache2 restart

NOTE: Using tools like Firebug will enable you to see an HTTP Header indicating the version being used for your requests.

If you need to modify configuration from the default:

sudo vi /etc/apache2/mods-available/pagespeed.conf

For VirtualDomains, you can selectively enable and disable PageSpeed and many of it’s settings in your appropriate configuration files with:

<IfModule pagespeed_module>
ModPagespeed on
</IfModule>

NOTE: Appending ?ModPagespeed=off to your URL will disable functions for that request.

REFERENCES: