It’s short, simple, easy to debug — and, now, far easier to secure with Contrast’s new, Kotlin-tuned AppSec testing. 

Kotlin — which originated in 2010 at JetBrains and has been open source since the year 2012 — is a statically typed programming language that runs on the Java Virtual Machine (JVM) and which can also be compiled to JavaScript source code as well as to use the LLVM compiler infrastructure. 

The appeal of Kotlin is that it gives you the ability to essentially create a web app with one language on both front and back end. 

Unique qualities of Kotlin

NullSafety — The Billion Dollar Mistake is the name given to the danger of null references in code. Kotlin’s type system is aimed at eliminating the danger of these null references. This has been one of the most common pitfalls in Java — and many other programming languages, as well.

No more Raw Types — Kotlin is designed with Java interoperability in mind: It can effectively call  existing Java code. Alternatively, Kotlin code can be used in Java rather smoothly.

Invariant Arrays — The basic types used in Kotlin are Numbers, Arrays, Characters and Strings. Unlike Java, the arrays in this programming language are invariant, meaning that Kotlin does not let a user assign an Array<String> to an Array<Any>. This prevents a possible runtime failure, which is one of the issues faced in Java.

Function Types — In Kotlin, a lambda expression or an anonymous function can access the variables declared in the outer scope. As opposed to Java’s SAM conversions,  Kotlin has proper function types.

Use-site Variance — Wildcard types are one of the trickiest parts of Java’s type System. This issue does not occur in Kotlin, given that the language does not have any Wildcard Types, just Type Projections and declaration-site variances.

Exceptions — Kotlin does not have any checked exceptions, as all exception classes in this language are the descendants of the class Throwable. And every exception has a message, stack trace, and an optional cause.

Smart Casts — Working with the mixed types requires knowing the type of an object at  runtime in order to safely cast the object to the desired type — and, further, to call methods or access properties on it. For class casting in Java, we first check the type of the variable using the “instance of” operator and then cast it to the target type.

Whereas in Kotlin, when we perform an “!is” or “is” check on a variable, the compiler tracks this information and will automatically cast the variable to the target type where the “!is” or “is” check is true in the scope. 

Singletons — Once in a while, a user needs to create an object of a slight modification of some class but without explicitly declaring a new subclass for it. Java handles this case with anonymous inner classes, but Kotlin generalizes the same concept by using object expressions and declarations. Just like the anonymous inner classes in Java, the code in object expressions can access variables from the enclosing scope. But in Kotlin, this is not restricted to final variables like in Java.

Data Classes — The purpose of creating classes is to hold data and, in some classes, standard functionality with utility functions can be mechanically derived from that data. This is known as a Data Class in Kotlin. These classes generally contain some old boilerplate code in the form of toString(), hashcode(), equals(), setters and getters.

Basically, Kotlin’s Data Classes are like regular classes but with some additional functionality.

Conclusion

Kotlin has come a long way, even if it is still in the early stage of version 1.6. Kotlin code is both safer and more concise than Java code. Kotlin is not just useful for new apps, but its files can coexist with Java files,  meaning  it also has scope for existing applications.

Best practices for Kotlin users

Avoid SQL injections by never building SQL queries using string concatenation. Instead, use a Prepared Statement or use Spring JDBCTemplate or frameworks like Hibernate, iBatis, etc. to handle communication with the database.

• Keep OWASP Top 10 Vulnerabilities in check
• Make sure to check against a whitelist of input characters to avoid XSS ( Cross Site Scripting).
• Avoid old versions of software.
• Threat Modeling to understand the various security threats posed to the application.
• Use known and tested libraries.  For application security, Spring Security is the de facto standard. It offers a wide range of options and the flexibility to fit with any app architecture, and it incorporates a range of security approaches.
• Beware of external Input.  SQL injection and cross-site scripting (XSS) are just the most commonly known attacks that can result from mishandling external input. Whenever  you receive input, it should be sanity checked and sanitized. Always use prepared statements to handle SQL parameters. Also watch out for Denial of Service (DoS) attacks.
• Keep implementation hidden.  Don’t reveal implementation via error messages.
• Keep security releases up to date — Auto-update where possible.
• Scan for Dependency Vulnerabilities — There are many tools available to automatically scan your codebase and dependencies for vulnerabilities. All you have to do is use them. The Open Web Application Security Project (OWASP) — an organization dedicated to improving code security — offers a  list of trusted, high-quality, automated code-scanning tools that includes several Java-oriented tools.

Contrast can help with Kotlin AppSec issues

Kotlin is just getting started. Don’t ignore it!

Contrast Security certainly hasn’t. With all the Kotlin goodness outlined  above, there are good reasons to  consider application security testing that’s tuned and optimized for the language. Despite capabilities designed in Kotlin to prevent application developers from getting into trouble, security bugs — including injection vulnerabilities, misconfigurations and other issues that could potentially lead to exploit — will inevitably get into code. Finding and fixing these security risks early in the development cycle is critical. 

In order to find and fix those issues, Contrast has provided the first instrumented — inside out — solution for detecting vulnerabilities in Kotlin applications, expanding Contrast’s application security platform capabilities to cover this valuable language and ease the work of those who use it. Contrast’s new Kotlin offering enables AppSec & dev teams to instrument and thus test Kotlin apps during runtime, with higher accuracy and reduced manual intervention. 

Today, we’re seeing far more companies taking up application security testing as part of their Agile process. It’s a positive move:  As applications become more complex, with more add-ons and bug fixtures, application testing has been leaning more towards test automation compared to manual testing.

Much of this shift can be attributed to how much time security testing takes up in the software development lifecycle, with manual labor being the biggest factor. In order to reduce how much time engineers spend manually triaging vulnerabilities, companies are embracing the use of security automation. Contrast provides a suite of products — including IAST, SAST, RASP, SCA, and more — that will deal with Kotlin AppSec issues and help you ship better and more secure applications. 

If you’re not yet a Contrast customer, please contact us to discuss participation. If you are an existing Contrast customer, please ask your support or customer success representative for access.