次の場合に XPath Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。



2. データが XPath クエリの動的な構築に使用された場合。

例 1: 以下のコードは、指定されたアカウント ID の電子メールアドレスを取得する XPath クエリを動的に構築して実行します。このアカウント ID は、HTTP リクエストから読み取られるため、信頼することはできません。

...
string acctID = Request["acctID"];
string query = null;
if(acctID != null) {
       StringBuffer sb = new StringBuffer("/accounts/account[acctID='");
       sb.append(acctID);
       sb.append("']/email/text()");
       query = sb.toString();
}

XPathDocument docNav = new XPathDocument(myXml);
XPathNavigator nav = docNav.CreateNavigator();
nav.Evaluate(query);
...

アカウント番号 1 に属する電子メールアドレスを検索するような通常の状況では、このコードが実行するクエリは次のようになります。

/accounts/account[acctID='1']/email/text()

ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、acctID に単一引用符が含まれない場合のみクエリは正しく動作します。攻撃者が acctID に文字列「1' or '1' = '1」を入力すると、クエリは次のようになります。

/accounts/account[acctID='1' or '1' = '1']/email/text()1' or '1' = '1 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。

//email/text()

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、文書内に格納されているすべての電子メール アドレスを返すようになりました。

次の場合に XPath Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。




2. データが XPath クエリの動的な構築に使用された場合。

例 1: C API をコールする次の Objective-C コードは、指定されたアカウント ID の電子メール アドレスを取得する XPath クエリを動的に構築して実行します。このアカウント ID は、HTTP リクエストから読み取られるため、信頼することはできません。

...
    NSString *accountStr = account.text;

    xmlXPathContextPtr xpathCtx;
    NSString *query = @"/accounts/account[actId='" + accountStr + @"']/email/text()";

    xpathCtx = xmlXPathNewContext(doc);

    /* Evaluate XPath expression */
    xmlChar *queryString =
        (xmlChar *)[query cStringUsingEncoding:NSUTF8StringEncoding];
    xpathObj = xmlXPathEvalExpression(queryString, xpathCtx);
...

アカウント番号 1 に属する電子メールアドレスを検索するような通常の状況では、このコードが実行するクエリは次のようになります。

/accounts/account[acctID='1']/email/text()

ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、acctID に単一引用符が含まれない場合のみクエリは正しく動作します。攻撃者が acctID に文字列「1' or '1' = '1」を入力すると、クエリは次のようになります。

/accounts/account[acctID='1' or '1' = '1']/email/text()1' or '1' = '1 条件を追加すると、where 句は常に真 (true) の評価を行います。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。

//email/text()

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、文書内に格納されているすべての電子メール アドレスを返すようになりました。

次の場合に XPath Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。



2. データが XPath クエリの動的な構築に使用された場合。

例 1: 以下のコードは、指定されたアカウント ID の電子メールアドレスを取得する XPath クエリを動的に構築して実行します。このアカウント ID は、HTTP リクエストから読み取られるため、信頼することはできません。

query = "/accounts/account[acctID='" & url.acctID & "']/email/text()";
selectedElements = XmlSearch(myxmldoc, query);

アカウント番号 1 に属する電子メールアドレスを検索するような通常の状況では、このコードが実行するクエリは次のようになります。

/accounts/account[acctID='1']/email/text()

ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、acctID に単一引用符が含まれない場合のみクエリは正しく動作します。攻撃者が acctID に文字列「1' or '1' = '1」を入力すると、クエリは次のようになります。

/accounts/account[acctID='1' or '1' = '1']/email/text()1' or '1' = '1 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。

//email/text()

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、文書内に格納されているすべての電子メール アドレスを返すようになりました。

次の場合に XPath Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。




2. データが XPath クエリの動的な構築に使用された場合。

例 1: 以下のコードは、指定されたアカウント ID の電子メールアドレスを取得する XPath クエリを動的に構築して実行します。このアカウント ID は、HTTP リクエストから読み取られるため、信頼することはできません。

...
    NSString *accountStr = account.text;

    xmlXPathContextPtr xpathCtx;
    NSString *query = @"/accounts/account[actId='" + accountStr + @"']/email/text()";

    xpathCtx = xmlXPathNewContext(doc);

    /* Evaluate XPath expression */
    xmlChar *queryString =
        (xmlChar *)[query cStringUsingEncoding:NSUTF8StringEncoding];
    xpathObj = xmlXPathEvalExpression(queryString, xpathCtx);
...

アカウント番号 1 に属する電子メールアドレスを検索するような通常の状況では、このコードが実行するクエリは次のようになります。

/accounts/account[acctID='1']/email/text()

ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、acctID に単一引用符が含まれない場合のみクエリは正しく動作します。攻撃者が acctID に文字列「1' or '1' = '1」を入力すると、クエリは次のようになります。

/accounts/account[acctID='1' or '1' = '1']/email/text()1' or '1' = '1 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。

//email/text()

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、文書内に格納されているすべての電子メール アドレスを返すようになりました。

次の場合に XPath Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。



2. データが XPath クエリの動的な構築に使用されます。

例 1: 以下のコードは、指定されたアカウント ID の電子メールアドレスを取得する XPath クエリを動的に構築して実行します。このアカウント ID は、HTTP リクエストから読み取られるため、信頼することはできません。

...
<?php
load('articles.xml');
 
$xpath = new DOMXPath($doc);
$emailAddrs = $xpath->query(&quot;/accounts/account[acctID='&quot; . $_GET[&quot;test1&quot;] . &quot;']/email/text()&quot;);
//$arts = $xpath->evaluate(&quot;/accounts/account[acctID='&quot; . $_GET[&quot;test1&quot;] . &quot;']/email/text()&quot;)
 
foreach ($emailAddrs as $email)
{
    echo $email->nodeValue."";
}
	?>
...

アカウント番号 1 に属する電子メールアドレスを検索するような通常の状況では、このコードが実行するクエリは次のようになります。

/accounts/account[acctID='1']/email/text()

ただし、クエリは定数のクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、acctID に単一引用符が含まれない場合のみクエリは正しく動作します。攻撃者が acctID に文字列「1' or '1' = '1」を入力すると、クエリは次のようになります。

/accounts/account[acctID='1' or '1' = '1']/email/text()1' or '1' = '1 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。

//email/text()

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、文書内に格納されているすべての電子メール アドレスを返すようになりました。

次の場合に XPath Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。



2. データが XPath クエリの動的な構築に使用されます。

例 1: 以下のコードは、指定されたアカウント ID の電子メールアドレスを取得する XPath クエリを動的に構築して実行します。このアカウント ID は、HTTP リクエストから読み取られるため、信頼することはできません。

...
tree = etree.parse('articles.xml')
emailAddrs = "/accounts/account[acctID=" + request.GET["test1"] + "]/email/text()"
r = tree.xpath(emailAddrs)
...

アカウント番号 1 に属する電子メールアドレスを検索するような通常の状況では、このコードが実行するクエリは次のようになります。

/accounts/account[acctID='1']/email/text()

ただし、クエリは定数のクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、acctID に単一引用符が含まれない場合のみクエリは正しく動作します。攻撃者が acctID に文字列「1' or '1' = '1」を入力すると、クエリは次のようになります。

/accounts/account[acctID='1' or '1' = '1']/email/text()1' or '1' = '1 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。

//email/text()

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、文書内に格納されているすべての電子メール アドレスを返すようになりました。

次の場合に XQuery Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。



2. データが XQuery 式の動的な構築に使用された場合。

例 1: 以下のコードは、特定のユーザー名とパスワードの組み合わせでユーザー アカウントを検索する XQuery 式を動的に構築し、実行します。ユーザー名とパスワードは HTTP リクエストから返されたものであり、したがって、信頼できません。

  ...

  String squery = "for \$user in doc(users.xml)//user[username='" + Request["username"] + "'and pass='" + Request["password"] + "'] return \$user";

  Processor processor = new Processor();

  XdmNode indoc = processor.NewDocumentBuilder().Build(new Uri(Server.MapPath("users.xml")));

  StreamReader query = new StreamReader(squery);
  XQueryCompiler compiler = processor.NewXQueryCompiler();
  XQueryExecutable exp = compiler.Compile(query.ReadToEnd());
  XQueryEvaluator eval = exp.Load();
  eval.ContextItem = indoc;

  Serializer qout = new Serializer();
  qout.SetOutputProperty(Serializer.METHOD, "xml");
  qout.SetOutputProperty(Serializer.DOCTYPE_PUBLIC, "-//W3C//DTD XHTML 1.0 Strict//EN");
  qout.SetOutputProperty(Serializer.DOCTYPE_SYSTEM, "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd");
  qout.SetOutputProperty(Serializer.INDENT, "yes");
  qout.SetOutputProperty(Serializer.OMIT_XML_DECLARATION, "no");

  qout.SetOutputWriter(Response.Output);
  eval.Run(qout);

  ...
  

適切なユーザー名とパスワードを持つユーザー アカウントを検索するような通常の状況では、このコードが実行する式は次のようになります。

for \$user in doc(users.xml)//user[username='test_user' and pass='pass123'] return \$user

ただし、式は定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、 username または password に単一引用符が含まれない場合のみクエリは正しく動作します。攻撃者が username に文字列「admin' or 1=1 or ''='」を入力すると、クエリは次のようになります。

for \$user in doc(users.xml)//user[username='admin' or 1=1 or ''='' and password='x' or ''=''] return \$useradmin' or 1=1 or ''=' 条件を追加すると、XQuery 式は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。

//user[username='admin']

クエリをこのように単純化すると、攻撃者がクエリはパスワードにマッチしていることという要件を迂回することを許します。このクエリは、入力されたパスワードが何であろうと、文書内に格納されている管理者ユーザーを返します。

次の場合に XQuery Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。



2. データが XQuery 式の動的な構築に使用されます。

例 1: 以下のコードは、特定のユーザー名とパスワードの組み合わせでユーザー アカウントを検索する XQuery 式を動的に構築し、実行します。ユーザー名とパスワードは HTTP リクエストから返されたものであり、したがって、信頼できません。

...

$memstor = InMemoryStore::getInstance();
$z = Zorba::getInstance($memstor);

try {
  // get data manager
  $dataman = $z->getXmlDataManager();

  // load external XML document
  $dataman->loadDocument('users.xml', file_get_contents('users.xml'));

  // create and compile query
  $express =
"for \$user in doc(users.xml)//user[username='" . $_GET["username"] . "'and pass='" . $_GET["password"] . "'] return \$user"

  $query = $zorba->compileQuery($express);

  // execute query
  $result = $query->execute();



?>
...

適切なユーザー名とパスワードを持つユーザー アカウントを検索するような通常の状況では、このコードが実行する式は次のようになります。

for \$user in doc(users.xml)//user[username='test_user' and pass='pass123'] return \$user

ただし、式は定数のクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、username または password に単一引用符が含まれない場合のみクエリは正しく動作します。攻撃者が username に文字列「admin' or 1=1 or ''='」を入力すると、クエリは次のようになります。

for \$user in doc(users.xml)//user[username='admin' or 1=1 or ''='' and password='x' or ''=''] return \$useradmin' or 1=1 or ''=' 条件を追加すると、XQuery 式は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。

//user[username='admin']

クエリをこのように単純化すると、攻撃者がクエリはパスワードにマッチしていることという要件を迂回することを許します。このクエリは、入力されたパスワードが何であろうと、文書内に格納されている管理者ユーザーを返します。

次の場合に XSLT Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. このデータは、XSL スタイルシートに書き込まれます。


アプリケーションは通常 XSL スタイルシートを使用して XML 文書のフォーマット変換を行います。XSL スタイルシートには変換プロセスを強化する特殊な関数が含まれているので、適切に使用しないと、脆弱性が増加します。

攻撃者が XSL スタイルシート内の XSL 要素に書き込みが可能な場合、XSL スタイルシートおよび処理のセマンティクスが改変される場合があります。攻撃者は XSS (Cross-Site Scripting) 攻撃を仕掛けられるようにスタイルシートの出力を改変し、ローカルファイルシステムのリソースのコンテンツを露出させ、あるいは任意のコードを実行することができます。

例 1: XSLT Injection に対して脆弱なコードの例を次に示します。

  ...
  String xmlUrl = Request["xmlurl"];
  String xslUrl = Request["xslurl"];

  XslCompiledTransform xslt = new XslCompiledTransform();
  xslt.Load(xslUrl);

  xslt.Transform(xmlUrl, "books.html");
  ...
  

攻撃者が特定の XSL を XSTL プロセッサに渡す権限を獲得している場合、Example 1 は次のような 3 種類の結果を引き起こします。

1. XSS:

  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/">
      <script>alert(123)</script>
    </xsl:template>
  </xsl:stylesheet>

  

XSL スタイルシートを処理するとき、<script> タグは対象者のブラウザーでレンダリングされ、Cross-site Scripting 攻撃の実行を許します。

2. サーバーのファイルシステムから任意のファイルを読み込みます。

  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/">
      <xsl:copy-of select="document('file:///c:/winnt/win.ini')"/>
    </xsl:template>
  </xsl:stylesheet>

  

上記の XSL スタイルシートは、/etc/passwd ファイルのコンテンツを返します。

3. 任意のコードを実行します。

XSLT プロセッサーは、ネイティブの言語メソッドを XSLT 関数として (それらが無効でない限り) 露出させる機能があります。

  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:App="http://www.tempuri.org/App">
    <msxsl:script implements-prefix="App" language="C#">
      <![CDATA[
        public string ToShortDateString(string date)
          {
              System.Diagnostics.Process.Start("cmd.exe");
              return "01/01/2001";
          }
      ]]>
    </msxsl:script>
    <xsl:template match="ArrayOfTest">
      <TABLE>
        <xsl:for-each select="Test">
          <TR>
          <TD>
            <xsl:value-of select="App:ToShortDateString(TestDate)" />
          </TD>
          </TR>
        </xsl:for-each>
      </TABLE>
    </xsl:template>
  </xsl:stylesheet>

  

上記のスタイルシートは、サーバー上で "cmd.exe" コマンドを実行します。

次の場合に XSLT Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. このデータは、XSL スタイルシートに書き込まれます。


アプリケーションは通常 XSL スタイルシートを使用して XML 文書のフォーマット変換を行います。XSL スタイルシートには変換プロセスを強化する特殊な関数が含まれているので、適切に使用しないと、脆弱性が増加します。

攻撃者が XSL スタイルシート内の XSL 要素に書き込みが可能な場合、XSL スタイルシートおよび処理のセマンティクスが改変される場合があります。攻撃者は XSS (Cross-Site Scripting) 攻撃を仕掛けられるようにスタイルシートの出力を改変し、ローカルファイルシステムのリソースのコンテンツを露出させ、あるいは任意のコードを実行することができます。攻撃者がアプリケーションに対して発行されたスタイルシートについて完全な制御権を獲得した場合、攻撃者は XXE (XML External Entity) Injection 攻撃を実行することもできます。

例 1: XSLT Injection に対して脆弱なコードの例を次に示します。

...
<?php

$xml = new DOMDocument;
$xml->load('local.xml');

$xsl = new DOMDocument;
$xsl->load($_GET['key']);

$processor = new XSLTProcessor;
$processor->registerPHPFunctions();
$processor->importStyleSheet($xsl);

echo $processor->transformToXML($xml);

?>
...

攻撃者が特定の XSL を XSTL プロセッサに渡す権限を獲得している場合、Example 1 のコードは次のような 3 種類の結果を引き起こします。

1. XSS:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<xsl:template match="/">
<script>alert(123)</script>
</xsl:template>
</xsl:stylesheet>

XSL スタイルシートを処理するとき、<script> タグは対象者のブラウザーでレンダリングされ、Cross-site Scripting 攻撃の実行を許します。

2. サーバーのファイルシステムから任意のファイルを読み込みます。

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<xsl:template match="/">
<xsl:copy-of select="document('/etc/passwd')"/>
</xsl:template>
</xsl:stylesheet>

上記の XSL スタイルシートは、/etc/passwd ファイルのコンテンツを返します。

3. 任意の PHP コードを実行します。

XSLT プロセッサーは、"registerPHPFunctions" を有効にすることで、ネイティブの PHP 言語メソッドを XSLT 関数として露出させる機能があります。

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<xsl:template match="/">
<xsl:value-of select="php:function('passthru','ls -la')"/>
</xsl:template>
</xsl:stylesheet>

上記のスタイルシートはサーバーで実行される "ls" コマンドの結果を出力します。

次の場合に XSLT Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. このデータは、XSL スタイルシートに書き込まれます。


アプリケーションは通常 XSL スタイルシートを使用して XML 文書のフォーマット変換を行います。XSL スタイルシートには変換プロセスを強化する特殊な関数が含まれているので、適切に使用しないと、脆弱性が増加します。

攻撃者が XSL スタイルシート内の XSL 要素に書き込みが可能な場合、XSL スタイルシートおよび処理のセマンティクスが改変される場合があります。攻撃者は XSS (Cross-Site Scripting) 攻撃を仕掛けられるようにスタイルシートの出力を改変し、ローカルファイルシステムのリソースのコンテンツを露出させ、あるいは任意のコードを実行することができます。

例 1: XSLT Injection に対して脆弱なコードの例を次に示します。

...
xml = StringIO.StringIO(request.POST['xml'])
xslt = StringIO.StringIO(request.POST['xslt'])

xslt_root = etree.XML(xslt)
transform = etree.XSLT(xslt_root)
result_tree = transform(xml)
return render_to_response(template_name, {'result': etree.tostring(result_tree)})
...

攻撃者が特定の XSL を XSTL プロセッサに渡す権限を獲得している場合、Example 1 のコードは次のような 3 種類の結果を引き起こします。

1. XSS:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <script>alert(123)</script>
  </xsl:template>
</xsl:stylesheet>

XSL スタイルシートを処理するとき、<script> タグは対象者のブラウザーでレンダリングされ、Cross-site Scripting 攻撃の実行を許します。

2. サーバーのファイルシステムから任意のファイルを読み込みます。

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:copy-of select="document('/etc/passwd')"/>
  </xsl:template>
</xsl:stylesheet>

上記の XSL スタイルシートは、/etc/passwd ファイルのコンテンツを返します。