<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Here's a good one, following up on webserve.ca's use of mod_security.<br>
<br>
I finally convinced them to allow <a class="moz-txt-link-rfc2396E" href="http://">"http://"</a> in postings, which again
allows links to external websites, but there was still an apparently
random problem ("Forbidden" error) occurring in long wiki page
postings. After a couple of hours of diagnosis, it turns out that the
words "select" and "from" cannot follow each other anywhere in a
posting, regardless of location in the posting, and regardless of
either one being embedded in longer words.<br>
<br>
So the phrase "select from" will trigger the Forbidden error. But also:<br>
<br>
if a user posts the sentence: "I select an apple from a pile", the
error will occur.<br>
<br>
if a user posts: "I selected a piece of fromage (French for cheese)",
the error will occur, because the word "from" is embedded in the word
"fromage", and follows the word "select" even though "select" is
embedded in the word "selected".<br>
<br>
And if the word "select" occurs at the top of the document, and the
word "from" occurs several paragraphs later, the "Forbidden" error will
occur.<br>
<br>
I have submitted this diagnosis to them.<br>
<br>
So Patrick: casting your mind back to your days as a professor (and
bearing in mind that you are one of the world's leading authorities on
regular expressions), if you had given a student the assignment to add
a filter to mod_security against a "select from" problem, and they came
up with the above results, what mark would you give them? What would
you say to them?&lt;grin&gt;<br>
<br>
I have since signed up with canadianwebhosting.com, and have begun the
process of moving my websites away from webserve.ca. The above proves
(if any more proof were needed) that they are basically dangerous.<br>
<br>
- Henrik<br>
<br>
<br>
Patrick R. Michaud wrote:
<blockquote cite="mid:20080326210351.GS23964@host.pmichaud.com"
 type="cite">
  <pre wrap="">On Wed, Mar 26, 2008 at 04:02:06PM -0400, Henrik wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">   Thanks for pointing me to the specific module responsible for the
   security, Patrick, and for the reality check.

   I am continuing to investigate alternate webserver hosts.
   canadianwebhosting.com looks promising. They use an suPHP scheme which
   looks tight but workable, with "Your scripts and directories can have a
   maximum of 755 permissions" (all files have the same owner with rwx). I
   presume that would be workable? Would I have to reconfigure the
   umask(002); statement in pmwiki.php for this?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
You might want to add umask(022); near the beginning of your config.php,
but other than that you should find that things run much better under
suPHP.


Pm



  </pre>
  <blockquote type="cite">
    <pre wrap=""> On Sun, Mar 23, 2008 at 10:11:49AM -0400, Henrik wrote:
  

 This security change by my webhost is confirmed. In response to my query
 they sent me the following response.

 =============================

 The web server security is setup such that it will automatically block system related words while posting data from php based applications, as this may lead to web server exploit. We request you to stop using system related words in your applications.

 =============================

 So suddenly none of my websites can post external links (with the string
 <a class="moz-txt-link-rfc2396E" href="http://">"http://"</a> anywhere in the page), and hundreds if not thousands of pages
 that have this protocol embedded are suddenly uneditable.

 Truly horrible. A complete nightmare!

 But nothing to do with PmWiki.
    


 Just to follow up on this -- this particular issue is described
 at <a class="moz-txt-link-freetext" href="http://www.pmwiki.org/wiki/PmWiki/Troubleshooting#mod_security">http://www.pmwiki.org/wiki/PmWiki/Troubleshooting#mod_security</a> .
 There is no PmWiki-based workaround to it, as the problem is well
 outside of PmWiki (as you've recognized).

 I've never heard of someone using mod_security to block <a class="moz-txt-link-rfc2396E" href="http://">"http://"</a>
 before, though, so that's new (and an additional reason to doubt
 the sanity of the webhosting provider).  Note that this security
 measure affects not only PmWiki, but also any application that
 tries to use an input form where someone might want to provide
 an <a class="moz-txt-link-freetext" href="http://">http://</a> link (e.g., comments to blog postings, shopping carts,
 etc.).

 Pm

  

 --

 Henrik Bechmann
 <a class="moz-txt-link-abbreviated" href="http://www.bechmann.ca">www.bechmann.ca</a>
 Webmaster, <a class="moz-txt-link-abbreviated" href="http://www.dufferinpark.ca">www.dufferinpark.ca</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 

Henrik Bechmann
<a class="moz-txt-link-abbreviated" href="http://www.bechmann.ca">www.bechmann.ca</a>
Webmaster, <a class="moz-txt-link-abbreviated" href="http://www.dufferinpark.ca">www.dufferinpark.ca</a></pre>
</body>
</html>