Security Concerns

Special care has to be taken when using parameters provided by the user when composing command line invocations.

Sanitizing user input is not a new problem, but in the case of Kapow!, we have to take into account also the way that the shell parses its arguments, as well as the way the command itself interprets them, in order to get it right.

Warning

It is imperative that the user input is sanitized properly if we are going feed it as a parameter to a command line program.

Parameter Injection Attacks

When you resolve variable values be careful to tokenize correctly by using double quotes. Otherwise you could be vulnerable to parameter injection attacks.

This example is VULNERABLE to parameter injection

In this example, an attacker can inject arbitrary parameters to ls.

1
2
3
4
$ cat command-injection.pow
kapow route add '/vulnerable/{value}' - <<-'EOF'
     ls $(kapow get /request/matches/value) | kapow set /response/body
EOF

Exploiting using curl:

1
$ curl http://localhost:8080/vulnerable/-lai%20hello

This example is NOT VULNERABLE to parameter injection

Note how we add double quotes when we recover value data from the request:

1
2
3
4
$ cat command-injection.pow
kapow route add '/not-vulnerable/{value}' - <<-'EOF'
     ls -- "$(kapow get /request/matches/value)" | kapow set /response/body
EOF

Warning

Quotes around parameters only protect against the injection of additional arguments, but not against turning a non-option into option or vice-versa. Note that for many commands we can leverage double-dash to signal the end of the options. See the “Security Concern” section on the docs.

Parameter Mangling Attacks

In order to understand what we mean by parameter mangling let’s consider the following route:

#!/bin/sh
kapow route add /find -c <<-'EOF'
       BASEPATH=$(kapow get /request/params/path)
       find "$BASEPATH" | kapow set /response/body
EOF

The expected use for this endpoint is something like this:

$ curl http://kapow-host/find?path=/tmp
/tmp
/tmp/.X0-lock
/tmp/.Test-unix
/tmp/.font-unix
/tmp/.XIM-unix
/tmp/.ICE-unix
/tmp/.X11-unix
/tmp/.X11-unix/X0

Let’s suppose that a malicious attacker gets access to this service and makes this request:

$ curl http://kapow-host/find?path=-delete

Let’s see what happens:

The command that will eventually be executed by bash is:

find -delete | kapow set /response/body

This will silently delete all the files below the current directory, no questions asked. Probably not what you expected.

This happens because find has the last word on how to interpret its arguments. For find, the argument -delete is not a path.

Let’s see how we can handle this particular case:

#!/bin/sh
kapow route add /find -c <<-'EOF'
        USERINPUT=$(kapow get /request/params/path)
        BASEPATH=$(dirname -- "$USERINPUT")/$(basename -- "$USERINPUT")
        find "$BASEPATH" | kapow set /response/body
EOF

Note

Since this is critical for keeping your Kapow! services secure, we are working on a way to make this more transparent and safe, while at the same time keeping it Kapowy.