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.
  • It is true that v 0.1 of the filter is hard-coded to munge OPML files, but the goal has always been to load a "sub" filter on the fly based on the /xref/@content-type attribute. Something along the lines of...

    if (my $ctype = $data->{Attributes}->{'{}content-type'}{'Value'}) {

        my $pkg = join("::",__PACKAGE__,(split(/\//,$ctype)));

        eval "require $pkg";
        if ($@) { ... }

        my $filter = $pkg->new();
        # Do stuff here....
    }

    If I manage to fin

    • by ziggy (25) on 2002.04.15 18:50 (#7027) Journal
      That code makes me rather uneasy from a security standpoint, since you're getting the module name by parsing the content-type. What happens when the value of content-type is something you don't expect to see like application/x-malcode-worm or ../../Malcode/BadWorm (thus overriding your initial setting of __PACKAGE__).

      That code may not have a new method, but the BEGIN block and import code may be sufficient to do something you don't expect.

      For safety's sake, you'd be better off to check to see if $pkg is one of the modules you expect to find in your namespace before blindly require'ing it dynamically through eval. There are ways to check what's available dynamically on the system before loading that module.

      This kind of technique isn't as easy to exploit as the recent SOAP::Lite server issue, but that's no reason to blindly require modules that are determined exclusively from your input.