view release on metacpan or  search on metacpan

doc/faq/security.html  view on Meta::CPAN

that would popup windows (which had a similiar style of the web-based
email hosting provider) requesting sensitive information from
users (like passwords).
</p>

<p>These types of attacks are classified as <em>Cross-Site
Scripting</em> (XSS) attacks by the security community.  The common
goal for XSS attacks is to obtain private information of a user,
like browser cookies used for site authentication.  </p>

<p>The following is a brief list of some of the security issues
related to HTML messages:
</p>
<ul>
<li>Can contain foreign dynamic content.
    </li>
<li>Can autoload URLs (via IMG, and similiar, elements) which
    can be used to collect statistics on unsuspected readers.
    </li>
<li>Contain hidden contents (like server-side include comments)
    which may be processed by web servers to execute arbitrary
    programs or extract arbitrary system files.
    </li>
</ul>

<p>MHonArc's HTML filter (documented under the <a href="../resources/mimefilters.html">MIMEFILTERS</a>)
resource provides functionality of stripping out HTML data to
minimize security exploits.  Check the document for full details.
The general recommendation for the security conscience is to exclude
any HTML message data (see <a href="#htmlexchow">next question</a>).

<!-- ??????????????????????????????????????????????????????????????? -->
<hr noshade size=1>
<table border=0>
<tr valign=baseline><td><img src="monicon.png" align="bottom" alt=""></td><td>
<h3><b><a name="htmlexchow">So how can I exclude HTML mail?</a></b></h3>
</td></tr></table>

<p>The quickest method is
via the <a href="../resources/mimeexcs.html">MIMEEXCS</a> resource:
<p>
<pre class="code">
<b>&lt;MIMEExcs&gt;</b>
text/html
text/x-html
<b>&lt;/MIMEExcs&gt;</b>
</pre>

<p>Unfortunately, for messages that contain only HTML data, the
entire message body will be excluded.  Therefore, you may still
want to show the data, but have it so the HTML markup is completely
neutralized.  The following resource settings will neutralize the
dangers of HTML messages without excluding message data:
</p>

<pre class="code">
&lt;!-- It is common for popular MUA's to provide a text/plain version
     of the text/html version of a message body.  Therefore, we
     use MIMEALTPREFS to choose the text/plain version if available.
  --&gt;
<b><a href="../resources/mimealtprefs.html">&lt;MimeAltPrefs&gt;</a></b>
text/plain
text/html
<b>&lt;/MimeAltPrefs&gt;</b>

&lt;!-- For messages that do not have a text/plain alternative, we
     treat HTML data as text/plain so the content is not lost, but
     HTML markup is escaped and neutralized.
  --&gt;
<b><a href="../resources/mimefilters.html">&lt;MIMEFilters&gt;</a></b>
text/html;   m2h_text_plain::filter; mhtxtplain.pl
text/x-html; m2h_text_plain::filter; mhtxtplain.pl
<b>&lt;/MIMEFilters&gt;</b>
</pre>

<!-- ??????????????????????????????????????????????????????????????? -->
<hr noshade size=1>
<table border=0>
<tr valign=baseline><td><img src="monicon.png" align="bottom" alt=""></td><td>
<h3><b><a name="attachments">Why doesn't MHonArc, by default, use the specified filename when saving attachments?</a></b></h3>
</td></tr></table>

<p>A malicious person could send a message with an attachment filename
that could overwrite existing content or be interpreted by the web
server in some special manner to execute actions.  Example: Apache
allows for the support for creating <tt>.htaccess</tt> files to allow
configuration settings within a directory.  If you have this feature
enabled and a message containes an attachment with the specified
filename <tt>.htaccess</tt> and MHonArc blindly used the attachment
filename, the attachment will override any existing <tt>.htaccess</tt>
file you created with a version defined by the sender of the message.
</p>

<p>Another possibility is that web servers sometimes interpret
filenames with certain extensions as executable content, like
<tt>.shtml</tt>, <tt>.cgi</tt>, <tt>.phtml</tt>.  If MHonArc used the
attachment filename, or even just the attachment filename extension,
anyone who can send mail that will be archived on your site can
introduce executable content.
</p>

<p>It is because of the above reasons that the
<a href="../resources/mimefilters.html#m2h_external"><tt>m2h_external::filter</tt></a>
documented in the <a href="../resources/mimefilters.html">MIMEFILTERS</a>
resource advises caution when using the filter options that enable
the usage of attachment filenames or filename extensions.
</p>

<!-- ??????????????????????????????????????????????????????????????? -->
<hr noshade size=1>
<table border=0>
<tr valign=baseline><td><img src="monicon.png" align="bottom" alt=""></td><td>
<h3><b><a name="suid">Is it okay to run <tt>mhonarc</tt> setuid?</a></b></h3>
</td></tr></table>

<p><strong>NO!</strong>  It is not okay.  First, MHonArc does
not pass Perl's taint checks.  Second, MHonArc is vulnerable to
symlink attacks.  Hence, if <tt>mhonarc</tt> (or any of the utility
programs) is setuid, <tt>mhonarc</tt> can be used for local priviledge
escalation attacks.
</p>