1. Authentication
- Brute Force
- Insufficient Authentication
- Weak Password Recovery Validation
2. Authorization
- Credential/Session Prediction
- Insufficient Authorization
- Insufficient Session Expiration
- Session Fixation
3. Client-side Attacks
- Content Spoofing
- Cross-site Scripting
4. Command Execution
- Buffer Overflow
- Format String Attack
- LDAP Injection
- OS Commanding
- SQL Injection
- SSI Injection
- XPath Injection
5. Information Disclosure
- Directory Indexing
- Information Leakage
- Path Traversal
- Predictable Resource Location
6. Logical Attacks
- Abuse of Functionality
- Denial of Service
- Insufficient Anti-automation
- Insufficient Process Validation
|
|
XPath Injection
XPath Injection is an attack technique used to exploit web sites that
construct XPath queries from user-supplied input.
XPath 1.0 is a language used to refer to parts of an XML document. It
can be used directly by an application to query an XML document, or
as part of a larger operation such as applying an XSLT transformation
to an XML document, or applying an XQuery to an XML document.
The syntax of XPath bears some resemblance to an SQL query, and
indeed, it is possible to form SQL-like queries on an XML document
using XPath. For example, assume an XML document that contains
elements by the name user, each of which contains three
subelements - name, password and account. The following XPath
expression yields the account number of the user whose name is
"jsmith" and whose password is "Demo1234" (or an empty string if no
such user exists):
string(//user[name/text()='jsmith' and
password/text()='Demo1234']/account/text())
If an application uses run-time XPath query construction, embedding
unsafe user input into the query, it may be possible for the attacker to
inject data into the query such that the newly formed query will be
parsed in a way differing from the programmer's intention.
Example
Consider a web application that uses XPath to query an XML
document and retrieve the account number of a user whose name
and password are received from the client. Such application may
embed these values directly in the XPath query, thereby creating a
security hole.
Here's an example (assuming Microsoft ASP.NET and C#):
XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr =
nav.Compile("string(//user[name/text()='"+TextBox1.Text+"'
and password/text()='"+TextBox2.Text+
"']/account/text())");
String account=Convert.ToString(nav.Evaluate(expr));
if (account=="") {
// name+password pair is not found in the XML document
-
// login failed.
} else {
// account found -> Login succeeded.
// Proceed into the application.
}
When such code is used, an attacker can inject XPath expressions,
e.g. provide the following value as a user name:
' or 1=1 or ''='
This causes the semantics of the original XPath to change, so that it
always returns the first account number in the XML document. The
query, in this case, will be:
string(//user[name/text()='' or 1=1 or ''='' and
password/text()='foobar']/account/text())
Which is identical (since the predicate is evaluates to true on all nodes) to
string(//user/account/text())
Yielding the first instance of //user/account/text().
The attack, therefore, results in having the attacker logged in (as the
first user listed in the XML document), although the attacker did not
provide any valid user name or password.
References
"XML Path Language (XPath) Version 1.0" - W3C Recommendation, 16 Nov 1999
http://www.w3.org/TR/xpath
"Encoding a Taxonomy of Web Attacks with Different-Length Vectors" - G. Alvarez and S. Petrovic
http://arxiv.org/PS_cache/cs/pdf/0210/0210026.pdf
"Blind XPath Injection" - Amit Klein
http://www.sanctuminc.com/pdfc/WhitePaper_Blind_XPath_Injection_20040518.pdf
To receive your Free Application
Vulnerability Assessment for testing of one attack vulnerability of your choice, please submit your payment of $1999.00 for a second XPath Injection attack vulnerability test.
|