Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by Matts (1087) on 2002.11.02 11:17 (#14436) Journal
    This is old old news. I first thought about this when I was developing my first XML applications back in 1998. I think we probably talked about it on the perl-xml list back then, but I don't recall - it's a long time!

    Anyway, I guess the issue is still a relatively minor security issue for most systems. I can see it being mainly a "discovery" mechanism, rather than an exploitation mechanism. You might conceivably be able to get some system to send back an error in the case of invalid content, which contains the original request, which potentially could include some included data. The bad thing of course is this data could potentially be something like /etc/passwd.

    One thing I thought about at the time was that it might be nice for XML to have forced external parsed entities to have a single top-level tag. This would alleviate some of the problem (i.e. a plain text document wouldn't work), but not all of it, obviously.

    The other thing to watch out for would be any pure perl entity resolvers that might naively call open() on the filename, potentially allowing remote execution. I don't know of any such systems, but there's a remote possibility of something doing this.
    • I had been under the (misguided) impression that entity resolution and validation were somehow linked, and that not providing the one (validation) meant you weren't doing the other.

      It was a simple-enough fix, but since my server classes proudly identify themselves in headers, I didn't want anyone being left vulnerable.

      --

      --rjray