XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Namespace prefixes are a security risk

No need to involve namespace prefixes here. Simply use comments:

<!-- ATTACK, Language="MyPreferredHackingLanguage"

  [
         A program in MyPreferredHackingLanguage that destroys the world.
  ]

-->

As a matter of fact I did use exactly this approach in the past when I
was working for a payroll company in Sydney, to implement a new
feature, desired urgently by a customer, without changes to the used
languages/protocols, and everybody was happy (if a little-bit
surprized this was possible)   :)


Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play




On Mon, Dec 28, 2009 at 8:14 AM, Costello, Roger L. <costello@mitre.org> wrote:
>
> Hi Folks,
>
>
> INTRODUCTION
>
> The problem described below occurs with XML 'guards' that are trying to prevent the release of unauthorized information at an enclave boundary. Namespace prefixes provide a ready channel for transmitting information out of the protected enclave.  That channel is overlooked by most XML applications, expect for an application that is specifically looking for that information.
>
>
> THE PROBLEM
>
> Consider this XML document containing data about a book:
>
>    <book xmlns="http://www.book.org";>
>        <title>The Origin of Wealth</title>
>        <author>Eric D. Beinhocker</author>
>        <date>2006</date>
>        <ISBN>1-57851-777-X</ISBN>
>        <publisher>Harvard Business School Press</publisher>
>        <cost currency="USD">29.95</cost>
>    </book>
>
> Seems pretty innocuous, right?
>
> It uses a default namespace declaration. Alternatively (equivalently) each element can be qualified. And the prefix can be anything, e.g.,
>
>    <attackNOW:book xmlns:attackNOW="http://www.book.org";>
>        <attackNOW:title>The Origin of Wealth</attackNOW:title>
>        <attackNOW:author>Eric D. Beinhocker</attackNOW:author>
>        <attackNOW:date>2006</attackNOW:date>
>        <attackNOW:ISBN>1-57851-777-X</attackNOW:ISBN>
>        <attackNOW:publisher>Harvard Business School Press</attackNOW:publisher>
>        <attackNOW:cost currency="USD">29.95</cost>
>    </attackNOW:book>
>
> Not so innocent-looking anymore, is it?
>
> But the problem isn't in how it "looks." The problem is that, as far as XML tools are concerned, the two forms are exactly equivalent:
>
> - If the first form is schema-valid,
>  then the second form is schema-valid.
>
> - If the first form can be parsed by an
>  XML parser, then the second form can
>  be parsed by an XML parser.
>
> - If the first form can be processed by
>  an XSLT transform, then the second form
>  can be processed by an XML transform.
>
> So, a guard, processing XML documents, using XML tools, may be completely oblivious to the covert information being passed via the namespace prefix. You may even say that the prefix is "invisible" to the guard.
>
>
> REPLACE NAMESPACE PREFIXES
>
> The good news is that, whatever prefixes the XML document contains, they can be replaced with controlled prefixes. Here is an XSLT transform that replaces the namespace prefix with N103: (Thanks to Ken Holman for this XSLT)
>
> <?xml version="1.0" encoding="US-ASCII"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
>                version="1.0">
>
>    <xsl:param name="use-this-prefix"/>
>
>    <xsl:template match="*[namespace-uri(.)]">
>        <xsl:element name="{$use-this-prefix}{local-name()}"
>                     namespace="{namespace-uri(.)}">
>            <xsl:apply-templates select="@*|node()"/>
>       </xsl:element>
>    </xsl:template>
>
>    <xsl:template match="@*[namespace-uri(.)]">
>       <xsl:attribute name="{$use-this-prefix}{local-name()}"
>                      namespace="{namespace-uri(.)}">
>           <xsl:value-of select="."/>
>       </xsl:attribute>
>    </xsl:template>
>
>    <xsl:template match="@*|node()"><!--identity for all other nodes-->
>       <xsl:copy>
>           <xsl:apply-templates select="@*|node()"/>
>       </xsl:copy>
>    </xsl:template>
>
> </xsl:stylesheet>
>
>
> COMMENTS
>
> I welcome your comments.
>
> /Roger
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>



-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
I enjoy the massacre of ads. This sentence will slaughter ads without
a messy bloodbath.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS