Why you should consider Kotlin for Burp extension development

This small article is an opinion piece to explain why we find the Kotlin language interesting. Its benefits applied to Burp extension development.

Security professionals might not be aware of Kotlin. However, it is becoming a trending language in the Android development ecosystem. Additionally, being propelled by Google and JetBrains, it should not be seen as a risky technology choice. In this article, we are going to outline the main advantages of this language.

  

Debugging and Tooling

While this may sound very basic, having IDE-level debugging is very helpful on medium and large projects.  The only supported language that has full debugging support in the context of Burp is Java. The implementation of Python (Jython) and Ruby (JRuby) used by Burp have rudimentary debugging features such as interactive debugging and console output. It makes Python and Ruby less attractive for big Burp extensions that will require long-term maintenance.

  

  

Null Resistant

Having uninitialized objects at runtime is a common problem in many languages. In that regards, Kotlin adds some beneficial safeguard: The compiler will make sure variables are not nullable avoiding a common source of runtime exceptions.

Declaring an object nullable will allow the compiler to do additional safety checks. In the following code sample, we can see few instances of unsafe code detected by the compiler and the use of the safe call feature in action.

fun extractXmlTag(nullableValue:String?, safeValue:String) : String? {
  var tag:String? = "";
  tag = nullableValue.substring(nullableValue.indexOf("<")) //Prohibit: Compiler error for potential null
  if(nullableValue != null) tag = nullableValue.substring(nullableValue.indexOf("<")) //OK: Null check
  tag = nullableValue?.substring(nullableValue?.indexOf("<")) //OK: Use of Safe call
  return tag
}

  

Class Extension

Class extension is a way to add the utility functions that you wish the Burp API had. This will replace utility classes in an elegant matter.

Here is an example where a method getHeader(String) is added as if it was part of the interfaces IRequestInfo and IResponseInfo.

val httpInfo = helpers.analyzeRequest(content)
if (isRequest) {
    this.headerValue = httpInfo.getHeader("Authorization")
} else {
    this.headerValue = httpInfo.getHeader("WWW-Authenticate")
}

fun IRequestInfo.getHeader(headerName:String):String = getHeaderCommon(headerName, this.headers)
fun IResponseInfo.getHeader(headerName:String):String = getHeaderCommon(headerName, this.headers)

internal fun getHeaderCommon(headerName:String,headers: List<String>):String {
    //Implementation goes here
}

  
While syntax sugar may not correlate directly with efficiency, it makes development significantly more pleasant. Here is an overview of the most commonly used patterns.

   

String template

String concatenation is a very common pattern. For this operation, Kotlin supports the inclusion of variable name or expression called « String Template ».

fun process(val status:String, val cipherText:ByteArray) {
    log("Output $status ${cipherText.toHex()} ")
}

   

Field initialization simplified

class Payload(val parameter1: String, val parameter2: String) {
}

 
The previous Kotlin constructor is analog to the following Java code:

class Payload {
  final String parameter1;
  final String parameter2;
  Payload(String parameter1,String parameter2) {
   this.parameter1 = parameter1;
   this.parameter2 = parameter2;
  }
}

   

Typing simplified

The left operant of assignation does not need to declare its type if it matches the one on the right.

ArrayList<String> listElements = new ArrayList<String>()
//becomes
val listElements = new ArrayList<String>()

   

No more getters and setters

Interoperability with Java code was one of the main objectives of the language. For this reason, fields (see var identifier) will implicitly have getX() and setX() methods created.

class PayloadMessage(
  var valid: Boolean,
  var version: String) {
}

 
The previous Kotlin code is analog to the following Java code:

class PayloadMessage {
  Boolean valid;
  String version;

  public PayloadMessage (Boolean valid, String version) { [...] }
  public String getVersion() {
    return version;
  }
  public void setVersion(String version) {
    this.version = version;
  }
  public Boolean isValid() {
    return valid;
  }
  public void setValid(Boolean valid) {
    this.valid = valid;
  }

  [...]
}

 

Conclusion

Kotlin is on the rise. Pentesters will inevitably have to review Kotlin code if they do Android assessments. Building small tools with the language is a fun way to explore it.

We have built few internal Burp plugins so far. Our soon-to-be-released to the Burp App Store SSP Decoder plugin is a demonstration that can serve as an example for new projects.

If you have an existing Java project and you wish you had started the project in Kotlin, you can always use the code conversion capabilities from IntelliJ to do the migration.

 

References

• Interactive tutorial to learn about the Kotlin language
• Official Kotlin website
• IntelliJ Java to Kotlin conversion tool
• Burp SSP Decoder : Burp extension developed in Kotlin that can serve as example