What are some examples of injection attacks into databases that abuse common programs besides SQL?

Question

Most data validation deals with SQL injection attacks. My question is, what other types of injection types are there that use common programs, and what are good defenses against them?

Answer 1

XML injection is a somewhat common vulnerability (though it's becomming less so as JSON and YAML are starting to supplant XML as the language of choice for data interchange), and has historically allowed for some really nasty attacks.

The reason for this is pretty simple, XML is a pain in the arse to parse correctly (it's still pretty common to find at least buffer overrun bugs in new XML parsers), and even if you do, the grammar itself allows for some pretty crazy attacks, many of which revolve around handling of entity references (a somewhat questionable feature XML inherited from SGML).

The general concept behind an XML entity is pretty simple, it provides a way for you to associate a character, sequence of characters, or external resource with a a short reference. HTML uses the same concept to provide escape codes for characters that it uses as part of it's own syntax (and ones not in the encoding of the document itself).

The two most well known attacks involving XML entities are 'billion laughs' attacks, and XXE.

---

The 'billion laughs' attack is a general type of attack that takes a very small input, and exploits parsing behavior to produce a monstrously large output. They aren't exactly unique to XML (they work with anything that lets you define recursively expanded data structures). In XML, this can be done by taking advantage of nested entity definitions (that is, entities can contain references to other entities, and these references get recursively expanded). Wikipedia provides the following nice example on their page about this class of attack:

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

That 881 bytes of XML expands to just over three billion bytes when parsed (roughly 3.5 million times larger), enough to force swapping on a system with less than about 4GB of RAM.

---

XXE, or XML External Entity attacks, rely on the ability of XML entity definitions to refer to external resources. When the document is parsed, those resources are retrieved, and then their contents are inserted into the document. XML allows for any valid URI for the external entity reference, so you can do some pretty crazy things with this type of attack, including (but not limited to0;

• Injecting the contents of files on the system doing the parsing that are readable by the parser into the document (using file:/// URI's).
• Running Javascript code in some web browsers without loading a Javascript file (using javascript: URI's).
• Remote ACE (using any number of specialty URI's, such as expect:// if the parsing is being done by a web server running PHP which has the PHP expect module installed).
• Establishing temporary remote connections to arbitrary systems (using any URI that translates to a network access).
• Lock up processing of the document (by using a URI that connects to an attacker controlled server which then takes a very long time to respond).

And that's just stuff I've seen done with it myself, in theory, you can do almost anything, because accessing a URI can translate to doing pretty much anything.

Answer 2

Excel is a very common, very popular program, and it contains a vulnerability to CSV injection attacks.

To start: Excel (And other spreadsheet programs) try to be smart. If an item in a CSV file start with a +, -, @, or =, it'll interpret that item as a formula.

Ok, that's not too bad. What's the most damage an attacker can do with a formula?

Turns out, quite a bit. Excel has a feature called Dynamic Data Exchange, which allows it to talk with other parts of the computer.

One of the parts is the command prompt, allowing a malicious attacker to execute arbitrary code on the machine.

One example of this (I can't find the news story at this time) was Dutch police managed to take over a dark website that was selling drugs, and replaced the transaction history .txt file with a transaction history .csv file - that included a CSV injection to "phone home" once the user opened the file.

CSV injection attacks aren't anything particularly new, and the following link describes some methods of preventing them: Link

Of course, Excel is just one platform with vulnerabilities, and it does raise some flags when it notices a CSV attack. Google Sheets is another common spreadsheet software, and attacks on their platform execute immediately, without any warnings.

Further reading