security.txt files

Similar to robots.txt and humans.txt is a recent addition of a security.txt file. This is currently a draft proposal to provide a standardized way to define security policies for researchers. This is useful for bug bounty and disclosure programs. Government agencies were tasked to add these back in 2019, but COVID-19 likely delayed implementation and rollout.

This is usually applied in the root of a website at /.well-known/security.txt, but can also be immediately in the root at /security.txt. Personally, I put mine in /.well-known/ and put a redirect at the root to simplify maintenance.

For additional security, you can optionally sign the policy with PGP.

Details:

I did some searching around the web and found some examples (linked below):

File in the root path:

File in the preferred /.well-known path:

Some PGP signed examples:

Questionable, though as the files are meant to be read by humans, this would meet the most simple use case:

SonarLint for Eclipse IDE

I’ve always been fan of tools for automation of development and testing. I’ve used SonarQube for a long time, and even connect it to my IDE (usually Eclipse), so that I can act on any warnings for code as I’m working on it.

SonarLint takes that to a new level, as it gives notifications before the code is even commited for SonarQube to analyze.

While the instructions here are for Eclipse, SonarLint is also available for IntelliJ IDEA, VisualStudio, and as a command line tool for download from the website.

Eclipse Update Site:
https://www.sonarlint.org/eclipse/

REFERENCES:

Code signing of java applets – using Ant

To sign your java assets during the Ant build process, you can add the following to the build.xml to make use of the values we established in the keystore creation step.

Something as simple as the following could be used:

<signjar jar="example.jar" alias="selfsigned" keystore="selfsignkeys.store" keypass="123456" storepass="123456"/>

I generally prefer to add the following:

In build.properties – I externalize the variables…

signing.alias=selfsigned
signing.keystore=selfsignkeys.store
signing.keypass=123456
signing.storepass=123456

Then, in build.xml – a ‘task’ for signing…


<property file="build.properties"></property>
... snip ...
<target name="signwar" depends="war">
<echo message="--- signing ---" />
<signjar jar="${build.dir}/${ant.project.name}.war" alias="${signing.alias}" keystore="${signing.keystore}" keypass="${signing.keypass}" storepass="${signing.storepass}" />
</target>

REFERENCES:

Code signing of java applets – using Maven

To sign your java assets during the maven build process, you can add the following to the pom.xml to make use of the values we established in the keystore creation step.

WARNING: for security and maintainability purposes, you should define the ‘configuration’ items in your local ‘settings.xml’ file instead of in the pom.xml as is done here for example only!


<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jarsigner-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>sign</id>
<goals>
<goal>sign</goal>
</goals>
</execution>
<execution>
<id>verify</id>
<goals>
<goal>verify</goal>
</goals>
</execution>
</executions>
<configuration>
<alias>selfsigned</alias><!-- ${project.name} -->
<keystore>selfsignkeys.store</keystore><!-- NOTE: you can also specify an absolute path here -->
<storepass>123456</storepass>
<keypass>123456</keypass>
</configuration>
</plugin>

REFERENCES:

Code signing of java assets – creating a keystore

This is generally done via the command line, though I’ve seen it done with Ant in some cases. Here are the specifics… you’ll want to change the passwords and likely take a look at the algorithm (RSA for this example and validity (365 days in this example) for your actual use.

Background, in order to sign your java assets, you will first need to generate a key. You can later get this verified by a CA (Certifying Authority) as needed, this example is selfsigned.

NOTE: I’ll use these example values in the Maven and Ant signing code examples to follow.


keytool -genkey -keyalg RSA -alias selfsigned -keystore selfsignkeys.store -storepass 123456 -keypass 123456 -validity 365

REFERENCES:

nbsp; and other common entities do not validate as HTML5!

The only built-in entities in XML are &, <, >, " and ' XHTML added the others via a DTD that is not a part of HTML5. As such, validators will report them as errors.

Safe replacements are the decimal notation: &#160; or the character itself U+00A0;

Quite a few other common symbols are not available without similar changes.

  • &lt; = &#60;
  • &gt; = &#62;
  • &amp; = &#38;
  • &apos; = &#39;
  • &quot; = &#34;
  • &nbsp;&#160;
  • &copy; = &#169;
  • &reg; = &#174;
  • &trade; = &#8482;

REFERENCES:

Java final modifier keyword

I’ve been a huge fan of the ‘final‘ modifier in Java for function arguments and variables. While there’s some debate on their usefulness for performance, they definitely add in readability and understanding of code as developers are instantly notified by modern IDE’s and when they try to reassign such values as the compiler will indicate the error.

NOTE: Use of final for classes or functions often contradicts the paradigm of Object Oriented programming as you’ll be restricted from extending or overriding those items!

JavaScript Code Quality (#2)

About a year ago I wrote a post regarding JSLint usage for code quality of JavaScript. There is now,for a while actually, an open-source fork of that code that allows for greater configuration.

Oddly, there are two separate sites, but I believe that they have the same content:

XML formatted JSP source code

I’ve found that many developers still use the classic coding style on JSP’s, unfortunately this makes it difficult to use some common tools for validation and complicates matters when looking for improperly nested tags in the markup. Migrating the XML formatted JSP markup simplifies matters and makes it possible for developers to quickly identify many problem areas of code within the IDE.

<%@ page language="java" %> = <jsp:page.directive language="java" />

<%@ page contentType="text/html; charset=utf-8" %> = <jsp:page.directive contentType="text/html; charset=utf-8" />

<%@ page import="" %> = <jsp:page.directive import="" />

NOTE: you can combine page.directive’s to a single tag with all attributes.

<% //some scriptlet %> = <jsp:scriptlet>//some scriptlet</jsp:scriptlet>

<%! String somevalue="1"; %> = <jsp:declaration>String somevalue="1";</jsp:declaration>

<%= somevalue %> = <jsp:expression>somevalue</jsp:expression>

<jsp:include page="" />
<jsp:directive.include file="" />

<jsp:useBean id="" scope="" type="" />

<jsp:setProperty name="" />

Unfortunately, there’s one common type of tag that does not have an XML equivalent:

<%@ taglib prefix="c" uri="/WEB-INF/tlds/c.tld" %>

REFERENCES:

Happy coding

JavaScript code quality

I’ve programmed in a lot of different languages, and with various IDE’s. The one area that has always been lacking is a simple means to review JavaScript code for common errors, both syntactical and format. This is where JSLint and JavaScript Lint come in…. these represent the tooling previously available to other languages like C++ and Java, where you can analyze code without actually executing it to identify problem areas. Often, these are items like ‘missing semicolons’ that occasionally cause difficult to find errors in browsers.

These can be scripted to execute from the command line or within (some) IDE’s on several operating systems.