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.
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.