DEV Community: Joe Kutner

Ground Control to Major TOML: Why Buildpacks Use a Most Peculiar Format

Joe Kutner — Wed, 22 Jul 2020 15:08:01 +0000

YAML files dominate configuration in the cloud native ecosystem. They’re used by Kuberentes, Helm, Tekton, and many other projects to define custom configuration and workflows. But YAML has its oddities, which is why the Cloud Native Buildpacks project chose TOML as its primary configuration format.

TOML is a minimal configuration file format that's easy to read because of its simple semantics. You can learn more about TOML from the official documentation, but a simple buildpack TOML file looks like this:

api = "0.2"

[buildpack]
id = "heroku/maven"
version = "1.0"
name = "Maven"

Unlike YAML, TOML doesn’t rely on significant whitespace with difficult to read indentation. TOML is designed to be human readable, which is why it favors simple structures. It’s also easy for machines to read and write; you can even append to a TOML file without reading it first, which makes it a great data interchange format. But data interchange and machine readability aren’t the main driver for using TOML in the Buildpacks project; it’s humans.

Put Your Helmet On

The first time you use Buildpacks, you probably won’t need to write a TOML file. Buildpacks are designed to get out of your way, and disappear into the details. That’s why there’s no need for large configuration files like a Helm values.yaml or a Kubernetes pod configuration.

Buildpacks favor convention over configuration, and therefore don’t require complex customizations to tweak the inner workings of its tooling. Instead, Buildpacks detect what to do based on the contents of an application, which means configuration is usually limited to simple properties that are defined by a human.

Buildpacks also favor infrastructure as imperative code (rather than declarative). Buildpacks themselves are functions that run against an application, and are best implemented in higher level languages, which can use libraries and testing.

All of these properties lend to a simple configuration format and schema that doesn’t define complex structures. But that doesn’t mean the decision to use TOML was simple.

Can You Hear Me, Major TOML?

There are many other formats the Buildpacks project could have used besides YAML or TOML, and the Buildpacks core team considered all of these in the early days of the project.

JSON has simple syntax and semantics that are great for data interchange, but it doesn’t make a great human-readable format; in part because it doesn’t allow for comments. Buildpacks use JSON for machine readable config, like the OCI image metadata. But it shouldn’t be used for anything a human writes.

XML has incredibly powerful properties including schema validation, transformation tools, and rich semantics. It’s great for markup (like HTML) but it's much too heavy of a format for what Buildpacks require.

In the end, the Buildpacks project was comfortable choosing TOML because there was solid prior art (even though the format is somewhat obscure). In the cloud native ecosystem, the containerd project uses TOML. Additionally, many language ecosystem tools like Cargo (for Rust) and Poetry (for Python) use TOML to configure application dependencies.

Commencing Countdown, Engines On

The main disadvantage of TOML is its ubiquity. Tools that parse and query TOML files (something comparable to jq) aren’t readily available, and the format can still be jarring to new users even though it’s fairly simple.

Every trend has to start somewhere, and the Cloud Native Buildpacks project is happy to be one of the projects stepping through the door.

Samurai Duke and the Legend of OpenJDK

Joe Kutner — Wed, 10 Jul 2019 19:05:06 +0000

What is Duke? No one knows his species or genus. People say he’s a Java Bean or a Software Agent, but all we know for sure is that he reminds us of the more than twenty-year legacy of the Java language and its community. The Java community has such an affinity for Duke that designers have created surfing Duke, astronaut Duke, rockstar Duke, macramé Duke, and of course Heroku’s Samurai Duke.

But how can all of these Duke variants exist without violating copyright or trademark laws? After all, Duke represents the language at the middle of one of the fiercest copyright battles in the history of software. The answer, it turns out, can teach us a great deal about how to nurture an open source community.

Java’s history is filled with ups and downs, rights and wrongs, plaintiffs and defendants, and a whole lotta XML. And just as those who don’t read history are doomed to repeat it, learning about Java’s past might help you grow the communities and products you contribute to--even if you’re only reading about a mascot.

The Origin Story

Duke was created in the earliest days of Java by Joe Palrang, an artist who helped animate films including Shrek and Over the Hedge. At the time, Duke was the property of Sun Microsystems and was as proprietary as Java itself. But Duke was poised to lead Java’s charge into a brave new world.

In 2006, Duke was open-sourced under a BSD license, which coincided with the release of the Java HotSpot virtual machine and compiler under the GNU GPL license. This was the first subset of a truly open source Java, and Sun Microsystems promised that the rest of the JDK would be released under the GPL within the next year. Duke, already the mascot for Java, became the herald of a new future where Java could be freely distributed--just like Duke could be freely customized by designers.

A completely free and open source Java may seem inevitable today, but fifteen years ago there was no certainty in the matter. Sun was struggling to make money despite producing some of the most innovative technologies in the industry, and giving their most successful product away for free seemed unrealistic.

As the decade came to a close, Sun was acquired by Oracle and the first Java release under new ownership, JDK 7, was also the first in which the reference implementation was free and open source under the GNU GPL License. Today, there are multiple OpenJDK distributions and the open Java ecosystem is thriving--along with Duke.

That’s why Heroku, who has always supported a freely distributable version of OpenJDK, knew exactly where to look when it needed a logo for its Java product.

The Way of Samurai Duke

Actually, Duke was not Heroku’s first choice for a logo (sorry Duke). The story of how Duke became a Samurai is shrouded in mystery, intrigue, and lawyers.

The famous Java coffee cup with steam rising from it (which we are not allowed to show here) was the first logo Heroku tried. But our lawyers informed us that we were violating Oracle’s license on that image.

For once, lawyers did us a favor. By taking the coffee cup option away, they forced us to think harder about what Heroku Java should look like.

We thought of Duke, but a plain-old naked Duke just wasn’t exciting enough for Heroku’s standards. We decided to dress him up and in classic Heroku style, so we gave him a Samurai outfit. Initially, Samurai Duke had a samurai sword in his belt, but our corporate team informed us that it was too violent and had to be removed. The end result is a cute, non-violent Samurai Duke, whom we love.

Heroku has long been the ally of a free and open Java and the OpenJDK project. Samurai Duke is our metaphorical protector of that freedom. The next time you see Heroku at a conference, be sure to say hello and ask for one of our Samurai Duke stickers. Or grab a copy of our Samurai Duke wallpaper. You’ll be helping us celebrate Java and open source.

Ten Ways to Secure your Applications

Joe Kutner — Thu, 21 Feb 2019 17:49:29 +0000

This blog post is adapted from a talk given by Joe Kutner at Devoxx 2018 titled "10 Mistakes Hackers Want You to Make."

Building self-defending applications and services is no longer aspirational--it’s required. Applying security patches, handling passwords correctly, sanitizing inputs, and properly encoding output is now table stakes. Our attackers keep getting better, and so must we.

In this blog post, we'll take a look at several commonly overlooked ways to secure your web apps. Many of the examples provided will be specific to Java, but any modern programming language will have equivalent tactics. Please feel free to share methods for other languages in the comments.

1. Ensure dependencies are up-to-date

Every year, OWASP, a group of security experts and researchers, publishes a list of the common application security risks to watch out for. One of the more common issues they've found is the use of dependencies with known vulnerabilities. Once a known CVE is published, many open source maintainers and contributors make a concentrated effort to released patched updates to popular frameworks and libraries. But one report found that more than 70% of exploited applications are due to outdated dependencies.

To ensure that your projects are relying on the latest and greatest packages, and automating your dependency management is recommended.

With Maven, you can use the Maven Versions Plugin, which automatically updates your pom.xml to use the newest packages. In Ruby, the bundle update command does something similar. You could incorporate these tools into your CI/CD process, and have a test outright fail if a dependency is outdated, thus forcing you to upgrade a package before your app can be deployed.

A more proactive approach might be to incorporate a tool that automatically monitors your dependencies for you, such as Snyk. Rather than running a check when code is modified (which could expose your app to a vulnerability for weeks or months, if it's infrequently updated), Snyk monitors your dependencies and compares them with a known list of vulnerabilities mapped to dependencies. If a problem is identified, they'll alert you with a report identifying which dependencies are outdated and which version contains a patched fix. Snyk is also free to try on Heroku.

2. Explicitly declare acceptable user payloads

All too often, web applications will accept nearly anything a user submits through a form or an API. For example, a user may attempt to create an account with a password containing over a thousand characters. When numerous requests like this are sent, it is possible the server will crash under the intense computation necessary to encrypt them.

One way to mitigate attacks like this is by implementing database-level constraints. Columns should have a maximum size defined, or your data model should refuse to accept NULL values. While placing these restrictions on the database is always a good idea, it can be considered too "low level," as certain attacks can be exploited fair earlier in the request cycle.

If your application is exposed to the Internet, every vulnerability is just one curl call away. In one example with the Jackson data-binding library, a simple JSON payload was able to execute arbitrary code, once the request was received by the server.

By providing an explicit list of expected inputs , you can ensure that your application is only operating on data that it knows will be coming, and ignoring (or politely erroring) on everything else. If your application accepts JSON, perhaps as part of an API, implementing JSON schemas are an excellent way to model acceptable requests. For example, if an endpoint takes two string fields named firstName and lastName, and one integer named age, a JSON schema to validate user-provided requests might look like this:

{
  "title": "Person",
  "type": "object",
  "properties": {
    "firstName": {
      "type": "string",
      "description": "The person's first name."
    },
    "lastName": {
      "type": "string",
      "description": "The person's last name."
    },
    "age": {
      "description": "Age in years which must be equal to or greater than zero.",
      "type": "integer",
      "minimum": 1
    }
  }
}

By stating the valid types, you can prevent unexpected issues from occurring if a user decides to send integers for firstName or negative numbers for age.

In addition to the request body, you should also check request headers and query parameters, which can be similarly exploitable.

3. Assert safe regular expressions

Regular expressions are both a boon and curse for every developer. They can make pattern matching on strings an easy task, but a poorly crafted regular expression can also bring an application down.

Consider a simple pattern like this one: (a|aa)+. While it looks innocuous, the | ("or") combined with the + operator can take a catastrophically long time to match against a string such as "aaaaaaaaaaaaaaaaaaaaaaaa!". Malicious users could cause a denial-of-service attack on your system by submitting a particularly complicated (yet still technically "valid") text. (A similar issue affected the Node.js community several years ago.)

Validating your regular expressions will ensure that they are not susceptible to this type of ReDoS attack. One tool you can use is saferegex, a command-line Java utility that will report on the likelihood of a regular expressions causing a problem:

$ java -jar target/saferegex.jar "(a|aa)+"

Testing: (a|aa)+
More than 10000 samples found.
***
This expression is vulnerable.
Sample input: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab

4. Prevent abusive requests

Building a popular application involves more than just adding desired features. Your site will also need to handle the amount of traffic it receives as it grows. Even if every part of your application is secure, bad actors who repeatedly hammer your servers could succeed in bringing them down.

To ensure uptime for your users, you should throttle aggressive clients. This can be done in a few different ways, like limiting requests by IP address or user agent.

A better implementation would be to use a library that takes advantage of a token-bucket algorithm. Bucket4j is one such library. Incoming requests are grouped by a variety of properties into individual "buckets," and those buckets can in turn be throttled or blacklisted entirely. By classifying which requests are acceptable and which aren't, you'll be able to better handle sudden bursts of traffic.

5. Align your code to be secure-first

Often, in the midst of a particularly frustrating bug, we may in our haste implement a solution pilfered from some corner of the Internet. While finally solving a problem may come as a much-needed relief, it's always worth triple-checking that you haven't inadvertently introduced a security issue.

A few years ago, researchers found that a majority of acceptable answers on StackOverflow contained insecure flaws. Code that works does not mean that code is secure. Even if a snippet works in the short-term, it's important to be absolutely certain that it is safe to use.

6. Store credentials outside your codebase

We all know (hopefully!) that divulging your personal password can be a catastrophic mistake. In any sufficiently complicated application, there can be a dozen different tokens and passwords to manage: your database username and password, tokens to authenticate to New Relic, or DataDog, or Redis...

Keep your application's configuration separate from your code. Even if your repository is private, embedding plaintext credentials is never a good idea. A disgruntled employee who shouldn't have access could steal the token to impersonate users. To ensure that your project is safe, you should be confident that, if the code became open source at any moment, none of your credentials would be compromised.

Store your secrets in environment variables. A library like dotenv can seamlessly load and make use of these variables, provided they're accessible in a secure location. Another option is to use a product like Hashicorp Vault, which allows your application to manage secrets through a configurable CLI.

7. Deny HTTP requests

Unless you have a very specific use case, you should disable HTTP connections to your server. An HTTPS connection ensures that data between the client and the server is encrypted, thus prohibiting person-in-the-middle snooping attacks. Most major browsers default to HTTPS connections by default, and services such as Let's Encrypt make it easier than ever to obtain an SSL certificate for your application.

If you need to support HTTP locally or between a proxy and your web server, you can configure your server to only accepts clients whose X-Forwarded-Proto request header is set to https. Depending on your setup, this may also be configurable outside of your code via an NGINX or Apache configuration.

8. Enable certificate checking

Sometimes, your application might need to make a call to an external provider. Similar to the suggestion above, you should enable certificate checking for outgoing connections. This ensures that communication to third-party APIs or services are also secured via HTTPS. Note that if a third-party website has a misconfigured certificate, it can cause errors when your application tries to connect. You might be tempted to just disable certificate checking to ensure that the application "just works," but this is a very insecure move that puts your users' data at risk.

You can use a library like EnvKeyStore to facilitate the storage of keys and certificates. Similar to dotenv, EnvKeyStore asks that you keep set a certificate PEM be to an environment variable. You can then use this PEM as the default checker for any outgoing client requests. For example:

KeyStore ts = EnvKeyStore.createWithRandomPassword("TRUSTED_CERT").keyStore();

String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
TrustManagerFactory tmf = TrustManagerFactory.getInstance(tmfAlgorithm);
tmf.init(ts);

SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, tmf.getTrustManagers(), new SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

String urlStr = "https://ssl.selfsignedwebsite.xyz";
URL url = new URL(urlStr);
HttpsURLConnection con = (HttpsURLConnection)url.openConnection();
con.setDoInput(true);
con.setRequestMethod("GET");
con.getInputStream().close();

9. Log and monitor suspicious behavior

Many applications only log critical failures, like unexpected server errors. But even behavior we have accounted for can be used as an attack vector. In those cases, it's imperative to log any sensitive action. An example of some behavior to log includes:

Successful and unsuccessful logins
Password resets
Changes to access levels
Authorization failures

In many of these cases, a user who is repeatedly generating an error may be a sign of a malicious attacker attempting to take over an account.

In order to separate these events from other errors, we recommend prefixing your log statements with phrases such as SECURITY_SUCCESS, SECURITY_FAILURE, and SECURITY_AUDIT. This way, you can easily filter on specific categories of authorization failures, should the need arise. Keep in mind that sensitive information, such as session IDs or passwords, should not be logged, as they will be stored in plaintext.

Another tactic to employ is to add an intrusion detection system. OWASP has a project called AppSensor, which provides a framework to detect and respond to potential attacks in an automated way. This works by adding an agent to your web application which sends events to your external AppSensor service. AppSensor will analyze those events, and, if it determines malicious behavior, AppSensor will respond back to the web app with a payload of information identifying what is going on. The application can then determine which action to take.

Take a look at the list of AppSensor detection points to potentially identify where your application needs improved intrusion detection.

10. Limit your own access

We all make mistakes. Although we ask users of our applications to behave with security in mind, we also need to practice good security hygiene. Some common sense actions that everyone should take include:

Using two-factor authentication wherever possible
Locking your computer screen any time you're not at your workstation
Implementing unique passwords across accounts and services, and using a password manager

Final thoughts

Security is hard, not because it's difficult to implement, but because it's difficult to identify how to be secure. When writing code it's far easier to achieve the intended functionality but much harder to conceive the unintended functionality, which is where your security issues will arise. In addition, there are many different kinds of security that comprise a healthy security posture: network security, platform security, physical security, and so on.

The ten ways you just learned to protect yourself are good starting points to ensure that your application security is top-notch. If you want to continue learning about web application security, you can check out the OWASP Getting Started guide for more information.

Stay safe, and again share any security tips you have in the comments—for Java or any other language!