/ 
HTML-TagFilter-1.03
River stage one • 3 direct dependents • 3 total dependents
/ HTML::TagFilter

NAME

HTML::TagFilter - A fine-grained html-filter, xss-blocker and mailto-obfuscator

SYNOPSIS

use HTML::TagFilter;
my $tf = new HTML::TagFilter;
my $clean_html = $tf->filter($dirty_html);

# or

my $tf = HTML::TagFilter->new(
    allow=>{...}, 
    deny=>{...}, 
    log_rejects => 1, 
    strip_comments => 1, 
    echo => 1,
    verbose => 1,
    skip_xss_protection => 1,
    skip_entification => 1,
    skip_mailto_entification => 1,
    xss_risky_attributes => [...],
    xss_permitted_protocols => [...],
    xss_allow_local_links => 1,
);

# or

my $tf = HTML::TagFilter->new(
    on_finish_document =>sub {
    	return "\n<p>" . $self->report . "</p>\n";
    }, 
);

$tf->parse($some_html);
$tf->parse($more_html);
my $clean_html = $tf->output;
my $cleaning_summary = $tf->report;
my @tags_removed = $tf->report;
my $error_log = $tf->error;

DESCRIPTION

HTML::TagFilter is a subclass of HTML::Parser with a single purpose: it will remove unwanted html tags and attributes from a piece of text. It can act in a more or less fine-grained way - you can specify permitted tags, permitted attributes of each tag, and permitted values for each attribute in as much detail as you like.

Tags which are not allowed are removed. Tags which are allowed are trimmed down to only the attributes which are allowed for each tag. It is possible to allow all or no attributes from a tag, or to allow all or no values for an attribute, and so on.

The filter will also guard against cross-site scripting attacks and obfuscate any mailto:email addresses, unless you tell it not to.

The original purpose for this was to screen user input. In that setting you'll often find that just using:

my $tf = new HTML::TagFilter;
put_in_database($tf->filter($my_text));

will do. However, it can also be used for display processes (eg text-only translation) or cleanup (eg removal of old javascript). In those cases you'll probably want to override the default rule set with a small number of denial rules.

my $self = HTML::TagFilter->new(deny => {img => {'all'}});
print $tf->filter($my_text);

Will strip out all images, for example, but leave everything else untouched.

nb (faq #1) the filter only removes the tags themselves: all it does to text which is not part of a tag is to escape the <s and >s, to guard against false negatives and some common cross-site attacks.

obPascal: Sorry about the incredibly long documentation, by the way. When I have time I'll make it shorter.

CONFIGURATION: RULES

Creating the rule set is fairly simple. You have three options:

use the defaults

which will produce safe but still formatted html, without tables, javascript or much else apart from inline text formatting, links and images.

selectively override the defaults

use the allow_tags and deny_tags methods to pass in one or more additional tag settings. eg:

$self->allow_tags({ p => { class=> ['lurid','sombre','plain']} });
$self->deny_tags({ img => { all => [] });

will mean that all attributes other than class="lurid|sombre|plain" will be removed from <p> tags, but the other default rules will remain unchanged. See below for more about how to specify rules.

supply your own configuration

To override the defaults completely, supply the constructor with some rules:

my $self = HTML::TagFilter->new( 
    allow=>{ p => { class=> ['lurid','sombre','plain']} }
);

In this case only the rules you supply will be applied: the defaults are ignored. You can achieve the same thing after construction by first clearing the rule set:

my $self = HTML::TagFilter->new();
$self->clear_rules();
$self->allow_tags({ p => { align=> ['left','right','center']} });

Future versions are intended to offer a more sophisticated rule system, allowing you to specify combinations of attributes, ranges for values and generally match names in a more fuzzy way.

CONFIGURATION: BEHAVIOUR

There are currently seven switches that will change the behaviour of the filter. They're supplied at construction time alongside any rules you care to specify. All of them default to 'off':

my $tf = HTML::TagFilter->new(
  log_rejects => 1,
  strip_comments => 1,
  echo => 1,
  verbose => 1,
  skip_xss_protection => 1,
  skip_ltgt_entification => 1,
  skip_mailto_entification => 1,
);

log_rejects

Set log to something true and the filter will keep a detailed log of all the tags it removes. The log can be retrieved by calling report(), which will return a summary in scalar context and a detailed AoH in list.

echo

Set echo to 1, or anything true, and the output of the filter will be sent straight to STDOUT. Otherwise the filter is silent until you call output().

verbose

Set verbose to 1, or anything true, and error messages will be output to STDERR as well as being stockpiled ready for a call to error().

strip_comments

Set strip_comments to 1 and comments will be stripped. If you don't, they won't.

skip_xss_protection

Unless you set skip_xss_protection to 1, the filter will postprocess some of its output to protect against common cross-site scripting attacks.

It will entify any < and > in non-tag text, entify quotes in attribute values (the Parser will have unencoded them) and strip out values for vulnerable attributes if they don't look suitably like urls. By default these attributes are checked: src, lowsrc, href, background and cite. You can replace that list (not extend it) at any time:

$self->xss_risky_attributes( qw(your list of attributes) );

skip_ltgt_entification

Disables the entification of < and > even if cross-site protection is on.

skip_mailto_entification

Unless you specify otherwise, any mailto:url seen by the filter is completely turned into html entities. <a href="mailto:wross@cpan.org">will</a> becomes <a href="mailto:%77%72%6F%73%73%40%63%70%61%6E%2E%6F%72%67">will</a>. This should defeat most email-harvesting software, but note that it has no effect on the text of your link, only its address. Links like <a href="mailto:wross@cpan.org">wross@cpan.org</a> are only partly obscured and should be avoided.

other constructor parameters

You can also supply values that will be used as default values for the methods of the same name:

xss_risky_attributes
xss_permitted_protocols

each of which expects a list of strings, and

xss_allow_local_links

which wants a single true or false value.

RULES

Each element is tested as it is encountered, in two stages:

tag filter

Just checks that this tag is permitted, and blocks the whole thing if not. Applied to both opening and closing tags.

attribute filter

Any tag that passes the tag filter will remain in the text, but the attribute filter will strip out of it any attributes that are not permitted, or which have values that are not permitted for that tag/attribute combination.

format for rules

There are two kinds of rule: permissions and denials. They work as you'd expect, and can coexist, but they're not quite symmetrical. Denial rules are intended to complement permission rules, so that they can provide a kind of compound 'unless'.

* If there are any 'permission' rules, then everything that doesn't satisfy any of them is eliminated.

* If there are any 'deny' rules, then anything that satisfies any of them is eliminated.

* If there are both denial and permission rules, then everything either satisfies a denial rule or fails to satisfy any of the permission rules is eliminated.

* If there is neither kind, we strip out everything just to be on the safe side.

The two most likely setups are

1. a full set of permission rules and maybe a couple of denial rules to eliminate pet hates.

2. no permission rules at all and a small set of denial rules to remove particular tags.

Rules are passed in as a HoHoL:

{ tag name->{attribute name}->[valuelist] }

There are three reserved words: 'any and 'none' stand respectively for 'anything is permitted' and 'nothing is permitted', or if in denial: 'anything is removed' and 'nothing is removed'. 'all' is only used in denial rules and it indicates that the whole tag should be stripped out: see below for an explanation and some mumbled excuses.

For example:

$self->allow_tags({ p => { any => [] });

Will permit <p> tags with any attributes. For clarity's sake it may be shortened to:

$self->allow_tags({ p => { 'any' });

but note that you'll get a warning about the odd number of hash elements if -w is on, and in the absence of the => the quotes are required. And

$self->allow_tags({ p => { none => [] });

Will allow <p> tags to remain in the text, but all attributes will be removed. The same rules apply at all levels in the tag/attribute/value hierarchy, so you can say things like:

$self->allow_tags({ any => { align => [qw(left center right)] });
$self->allow_tags({ p => { align => ['any'] });

examples

To indicate that a link destination is ok and you don't mind what value it takes:

$self->allow_tags({ a => { 'href' } });

To limit the values an attribute can take:

$self->allow_tags({ a => { class => [qw(big small middling)] } });

To clear all permissions:

$self->allow_tags({});

To remove all onClicks from links but allow all targets:

$self->allow_tags({ a => { onClick => ['none'], target => [], } });

You can combine allows and denies to create 'unless' rules:

$self->allow_tags({ a => { any => [] } });
$self->deny_tags({ a => { onClick => [] } });

Will remove only the onClick attribute of a link, allowing everything else through. If this was your only purpose, you could achieve the same thing just with the denial rule and an empty permission set, but if there's other stuff going on then you probably need this combination.

order of application

denial rules are applied first. we take out whatever you specify in deny, then take out whatever you don't specify in allow, unless the allow set is empty, in which case we ignore it. If both sets are empty, no tags gets through.

(We prefer to err on the side of less markup, but I expect this will be configurable soon.)

oddities

Only one deliberate one, so far. The main asymmetry between permission and denial rules is that from

allow_tags->{ p => {...}}

it follows that p tags are permitted, but the reverse is not true:

deny_tags->{ p => {...}}

doesn't imply that p tags are removed, just that the relevant attributes are removed from them. If you want to use a denial rule to eliminate a whole tag, you have to say so explicitly:

deny_tags->{ p => {'all'}}

will remove every <p> tag, whereas

deny_tags->{ p => {'any'}}

will just remove all the attributes from <p> tags. Not very pretty, I know. It's likely to change, but probably not until after we've invented a system for supplying rules in a more readable format.

CALLBACKS

Several trigger points are provided for the convenience of people who want to extend rather than replacing the normal behaviour of a tagfilter object. To use them, you just pass in a code reference with the appropriate name at construction time.

The example below will maintain a stack of seen tags and make the filter repair tag nesting, so that any unclosed tags are closed in roughly the right place, and any unopened close tags are omitted:

  my $filter = HTML::TagFilter->new(
	on_start_document => sub {
		my ($self, $rawtext) = @_;
		$self->{_tag_stack} = [];
		return;
	},
	on_open_tag => sub {
		my ($self, $tag, $attributes, $sequence) = @_;
		push @{ $self->{_tag_stack} }, $$tag unless grep {$_ eq $$tag} qw(img br hr meta link);
		return;
	},
	on_close_tag => sub {
		my ($self, $tag) = @_;
		unless (@{ $self->{_tag_stack} } && grep {$_ eq $$tag} @{ $self->{_tag_stack} }) {
			undef ${ $tag };
			return;
		}
		my @unclosed;
		while (my $lasttag = pop @{ $self->{_tag_stack} })  {
			return join '', map "</$_>", @unclosed if $lasttag eq $$tag;
			push @unclosed, $lasttag;
		}
	},
	on_finish_document => sub {
		my ($self, $cleantext) = @_;
		return join '', map "</$_>", reverse @{ $self->{_tag_stack} };
	},
  );

You can also fill these trigger points in subclass: If no callback method is supplied, we will call the class method of the same (triggerpoint) name instead. In this class those methods do nothing, so you can selectively override them without affecting normal functionality. To change all <b> tags to <strong> tags, for example:

  sub on_open_tag {
	my ($self, $tag, $attributes, $sequence) = @_;
  	$$tag = 'strong' if $$tag eq 'b';
  }

  sub on_close_tag {
	my ($self, $tag) = @_;
  	$$tag = 'strong' if $$tag eq 'b';
  }

As you can see here The tag and attribute values are passed in as string references: changes you make in callback will change the tag itself.

The available trigger points are:

on_construct ()

This is called during construction of a new TagFilter object, just before the constructed object is returned. It receives no arguments apart from the tagfilter object.

on_start_document ( $text )

This is called by the filter() method, and passed a reference to the text that is to be filtered. You can change the text, or return any values that should be prepended to output.

on_open_tag ( $tagname, $attributes, $attribute_sequence )

This is called by the filter_start() method, with is the checker of opening and single tags. It is passed the same variables as that method uses: the name of the tag, a hashref containing all its attributes and a listref holding attribute names in order.

Together with on_close_tag, this hook is very useful for adding document-tidying functions like tag closure, or for more sophisticated logging than tagfilter provides by itself.

on_process_text ( $text )

We normally just translate disallowed characters in text blocks, but this method receives a reference to the text string, so you can do what you like with it.

Note that if you just want to add more disallowed characters, you can just subclass character_map().

on_close_tag ( $text )

This is called by the filter_end() method, which is the checker of closing tags. It is passed the closing tag name.

on_finish_document ( $text )

This is called by the output() method. It receives no arguments, or we get the output a bit tangled up, but whatever you return will be appended to the final output string.

METHODS

For reference:

HTML::TagFilter->new();

If called without parameters, loads the default set. Otherwise loads the rules you supply. For the rule format, see above.

FILTER METHODS

These make up the main interface. You probably won't often need to call anything but filter().

$tf->filter($html);

Exactly equivalent to:

$tf->parse($html);
$tf->output();

but more useful, because it'll fit in a oneliner. eg:

print $tf->filter( $pages{$_} ) for keys %pages;

Note that calling filter() will clear anything that was waiting in the output buffer, and will clear the buffer again when it's finished. it's meant to be a one-shot operation and doesn't co-operate well. use parse() and output() if you want to daisychain.

parse($text);

The parse method is inherited from HTML::Parser, but most of its ancillary methods are subclassed here and the output they normally print is kept for later. The other configuration options that HTML::Parser normally offers are not passed on, at the moment, nor can you override the handler definitions in this module.

output()

This will return and clear the output buffer. It will conclude the processing of your text, but you can of course pass a new piece of text to the same parser object and begin again.

report()

If called in list context, returns the array of rejected tag/attribute/value combinations.

In scalar context returns a more or less readable summary. Returns () if logging not enabled. Clears the log.

filter_start($tag, $attributes_hashref, $attribute_sequence_listref);

This is the handler for html start tags: it checks the tag against the current set of rules, then checks each attribute and its value. Any text that fails is stripped out: the rest is passed to output.

filter_end($tag);

This is the handler for html end tags: it checks the tag against the current set of rules, and passes it to output if it's ok.

clean_text($text);

This is the handler for text: anything which is not tag is passed through here before being passed to output. At the moment it only applies some very simple cross-site protection: subclassing this method is an easy way to modify just the text part of your page.

character_map($text);

Returns a hashref of {disallowed_character => replacement_character} for use when cleaning text blocks.

add_to_output($text);

The supplied text is appended to the output buffer (or immediately printed, if echo is on).

logging($boolean);

This provides get-or-set access to the 'log' configuration parameter. Switching logging on or off during parsing will result in incomplete reports, of course.

log_denied($refused_tag);

If logging is on, this method will append the supplied failure information to the log. The standard form for this is a hashref that will contain some or all of these keys: 'tag', 'attribute', 'value' and 'reason'.

RULE CHECKERS

Compare individual tags and attributes against the rule set currently in force. These simple methods are the core of tagfilter: most of the rest is configuration, and the filter methods are really just glue to connect these tests to HTML::Parser's progress through a document.

tag_ok($tag);

Returns true if the supplied tag name is allowed in the text. If not, returns false and logs the failure with the reason 'tag'.

attribute_ok($tag, $attribute);

Returns true if it that attribute is allowed for that tag, and it is allowed to have the supplied value. If not, returns false and logs the failure with the reason 'attribute'.

url_ok($tag, $attributes, $value);

If xss protection is on, we check whether this attribute is a url field, and if it is we check that the url is a url (rather than a script tag or some other naughtiness). Failures are logged with the reason 'url'.

configuration methods

The configuration of the filter is held in a hash of hashes, usually referred to here as a hohoho as it usually has at least three levels. These methods expect to receive full or partial rule sets in the simplified form described above and merge them into - or drop them on top of - the active set.

allow_tags($hashref)

Takes a hashref of permissions and adds them to what we already have, replacing at the tag level where rules are already defined. In other words, you can add a tag to the existing set, but to add an attribute to an existing tag you have to specify the whole set of attribute permissions.

If no rules are sent (eg an empty hashref, or nothing at all, or a non-hashref) this clears the permission rule set.

deny_tags($hashref)

likewise but sets up (or clears) denial rules.

has_rules()

Returns true only if either allow or deny rules have been defined.

has_allow_rules()

Returns true if allow rules have been defined.

has_deny_rules()

Returns true if denial rules have been defined.

clear_rules()

Clears the entire rule set ready for the supply of a new set. A filter with no rules will strip *all* html from supplied text, by the way.

allows()

Returns the full set of permissions as a HoHoho. Can't be set this way: just a utility function in case you want to either display the rule set, or get the whole thing so you can send it back to allow_tags in a modified form.

denies()

Likewise for denial rules.

XSS configuration

Cross-site scripting attacks are invented or identified all the time. We'll try and stay up to date, but you may be more paranoid or up to date than us: if so, just override one or more of these methods.

xss_risky_attributes( @list_of_attributes );

Sets and returns a list of attributes that are considered to be urls, and should be checked for well-formedness.

The default list is href, src, lowsrc, cite and background: any supplied values will be used to replace (not extend) this list.

xss_permitted_protocols( @list_of_prefixes );

Sets and returns a list of protocols that are acceptable in attributes that we considered to be urls (ie they're in the list returned by xss_risky_attributes).

The default list is http, https, ftp and mailto. Any supplied values will be used to replace (not extend) this list. Don't include the colon.

xss_allow_local_links( $boolean );

If this method returns a true value, then addresses that begin '/' or '../' will be accepted in url fields.

You can set this value by calling the method with a parameter, as usual. The default is true.

error()

Returns an error report of currently dubious usefulness. If you want to record error messages in subclass, call $self->_add_error(@messages).

There is no class-level error logging mechanism at the moment, which is why the usefulness of this is rather limited.

TO DO

Make the documentation about half as long

More sanity checks on incoming rules

Simpler rule-definition interface

Complex rules. The long term goal is that someone can supply a rule like "remove all images where height or width is missing" or "change all font tags where size="2" to <span class="small">. Which will be hard. For a start, HTML::Parser doesn't see paired start and close tags, which would be required for conditional actions.

An option to speed up operations by working only at the tag level and using HTML::Parser's built-in screens.

REQUIRES

HTML::Parser

SEE ALSO

HTML::Parser

AUTHOR

William Ross, wross@cpan.org

COPYRIGHT

Copyright 2001-3 William Ross

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

Please use https://rt.cpan.org/ to report bugs & omissions, describe cross-site attacks that get through, or suggest improvements.

4 POD Errors

The following errors were encountered while parsing the POD:

Around line 124:

You forgot a '=back' before '=head3'

Around line 169:

=back without =over

Around line 177:

You forgot a '=back' before '=head3'

Around line 185:

=back without =over