use Perl

• OTLML sax filters (Score:1)

  by aaron of montreal (2785)

  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
  • Re:OTLML sax filters (Score:2)

    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.

    Reply to This

    Parent

    • Re:OTLML sax filters (Score:1)

      by aaron of montreal (2785)

      Yup. Yup. And yup again. The code I included was of the "thinking out loud" variety, but I will make sure to try and add appropriate hooks to check for bad-ness. Thanks!