Prophecy 2006

CCXML and VoiceXML are both vulnerable to "Programmatic XML injection attacks," which are similar in form to "SQL Injection Attacks." First, I'm going to explain what the vulnerability is, and then I'll explain how to secure your platform against the vulnerability.

Note that this vulnerability potentially affects all VoiceXML and CCXML platforms. I say potentially because (a) no one has reported this attack in the real world, at least yet, and (b) your system is only vulnerable under certain conditions. On the other hand, it only took me a short time to generate and test the attacks that I mention — they're quite simple to perform.

The Background

"Programmatic XML" is a language, such as CCXML or VoiceXML, that constitutes a program.

A Programmatic XML Injection Attack happens when the public can send text to your VoiceXML or CCXML platform and you accept that text as input. The attack is when the text is manipulated to and results in the CCXML/VoiceXML script executing instructions that you didn't expect.

First off, how do platforms accept text, and why? Platforms will accept text from the general public in order to provide services. For example, I might put up a web page and ask people to enter a telephone number. The web page sends that telephone number to a CCXML script, which then dials me. That telephone number is text which is used by my CCXML script, and it typically arrives at my program via an HTTP query (see next paragraph).

Another case is when the platform accepts HTTP queries from the Internet and the POST or GET data that accompanies that HTTP query. Anytime your script uses , you're sending an HTTP query that starts a script, and that script accepts the parameters "foo" and "bar" over the Internet.

In either case — text you allow the public to enter, or text that the public can send via HTTP — the platform takes that data and places it in the script via server-side programming. Server-side programming includes PHP, CGI scripts in languages such as Python, as well as Java Server Pages (or even Active Server Pages for the Microsoft-inclined).

If I send the variable "foo" with value "bar" via HTTP,

http://server_name/inject.php?foo=bar

the server will include that "foo" inside my script. For example, using HTTP and PHP, I could write this line in my CCXML script injecttest.php:

<var name="copyFoo" expr="' <?php echo($_REQUEST["foo"])?> '" />

and the output as seen by the interpreter would be:

<var name="copyFoo" expr="' bar '" />


I'm going to show how this creates a security vulnerability.

The Attack

The attack occurs when a malicious programmer (the "cracker") puts certain strings into the "foo" variable he sends. For example, let's say the cracker wants to attack the Python CGI script "inject.cgi". Ordinarily, the data sent to the script will look like this:

http://server_name/inject.php?foo=bar

The Python CGI script executes the following statement:

print "<var name=\"copyFoo\" expr=\"'%s'\"/>" % foo

where "foo" is the POST variable. The output will be

<var name="copyFoo" expr="'bar'" />

But instead, the cracker sends:

http://server_name/inject.php?foo=bar\'"/><log expr="\'hah hah

The output of inject.cgi becomes:

<var name="copy_of_foo" expr="'foo'"/>
<log expr="'hah hah'"/>

Of course, if done correctly, the cracker could send other code — for example, a "createccxml" element that points to an arbitrary location on the Internet.

PHP is also vulnerable. If PHP is used to read in a file, that file can contain malicious code. For example, consider this scenario. PHP has a config file, and the config file is supposed to read:

$foo = "bar";

but instead, a cracker manages to place

$foo = "bar\'"/><log expr="\'hah hah" ;

into the config information. Or, in a different example, the config file should read

<address>
<name>Bar</name>
</address>

But instead, it reads

<address>
<name>Bar\'"/><log expr="\'hah hah</name>
</address>

and the value of "$foo" is read from that XML file.

In either case, when I execute the CCXML script inject.php I run across the line:

<var name="copyFoo" expr="' <?php echo($foo) ?>'"/>

And the output is:

<var name="copy_of_foo" expr="'foo'"/>
<log expr="'hah hah'"/>

Defense

The defense against this attack is to never directly incorporate strings that arrive over the Internet, whether via HTTP or in another config file that's subject to tampering. All strings such as ' and " must be transformed into something safe, such as \' and \".

In fact, the best defense is to scrub all user input for all illegal characters. If you're expecting a telephone number, there's no reason to accept an apostrophe or a quote. If you're expecting a person's name, there's no reason to expect an angle bracket. The problem of "input validation" is well-known outside the VoiceXML/CCXML community, and it's time to adopt their solutions.

Vulnerability of P2006 Platform

P2006 ships with sqllite and PHP.

Current versions of PHP, such as used on the Prophecy 2006 platform, do not allow HTTP-based attacks by default. Any GET, POST, COOKIE, or REQUEST variable automatically has "dangerous" items in the string quoted. That is, the "bar'" that I'm trying to send becomes "bar\'", which prevents the attack. Similar HTTP-based attacks against JSP are possible; ASP is from Microsoft and I wouldn't bet a nickel on its default security settings.

Even on the Prophecy platform, you have to be careful about PHP that reads in data from files and databases. I would guess that the most vulnerable situation is when you expect an XML file with configuration information from outside the platform. Note that there's a setting on PHP that extends the same default protection available for HTTP variables to any variable you read from a file.

Of course the CGI Python attack I outline above can be a problem on P2006 if you use Python. Or Perl, or C, or any other CGI-based script and are not cautious.