Load and Save namespace misfiring.

RESOLVED INVALID

Status

()

Core
DOM
RESOLVED INVALID
16 years ago
5 months ago

People

(Reporter: Ray Whitmer, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
When a namespace declaration is given using the proper URI, the serializer does
not fixup namespaces properly, either on the declaration itself or on the
elements that should have used the declaration.

Case:

In the method nsSOAPMessage::Encode of
mozilla/extensions/xmlextras/soap/nsSOAPMessage.cpp, there are a few lines of
code that, as identified by the comment, "Declare the schema namespaces".  If
you eliminate the prefix from the qname (as a work-around the prefix is being
assigned with the local name appended, but just assign the local name to test
the bug) then attributes produced by SOAP implementations which rely on this
declaration will now remain unprefixed, as will the declarations themselves.

If the code has been modifed as described above, then use a test such as
mozilla/extensions/xmlextras/tests/soapisprimenumber.html, which creates a
bololean element identified by xsi:type.  But the xsi: will be missing, because
the serializer failed to fix it up properly.

It is my belief that this can be used as an exploit, in one case of SOAP even
circumventing security since a warning element is being securely added, but if
the serializer can be tricked into omitting namespace declarations, then the
recipient will not properly interpret the packet.  I believe that it is better
for a serializer to fail than to improperly fixup namespaces.

After discussions with Vidur, it is also possible that the namespace fixup
algorithm is also failing to work in another case where a prefix that has the
desired declaration is redeclared more-locally.

I will be happy to review the resulting fixes for correctness -- even to fix the
problem with a little assistance finding the actual code that implements the
algorithm.
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Assignee: general → nobody
QA Contact: gerardok → general

Updated

5 months ago
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.