> Paul,
>
> The <LimitExcept GET HEAD> approach would deny all POST/PUT/DELETE
> requests to the cgi-bin directory entirely -- including the legitimate
> ones from your own form. That would effectively break your application
> since your form uses POST.
>
> One thing worth checking: you mentioned Require ip 127.0.0.1 is
> "functional" -- are you testing from the server itself, or is there
> a reverse proxy in front of Apache that might be making all requests
> appear to come from localhost? That would explain why it seems to
> work but wouldn't actually protect you from external POSTs arriving
> directly. Worth verifying it still blocks when tested from outside
> your network.
>
> If the goal is to block external actors while allowing your form's
> POST through, you have a few practical options in order of robustness:
>
> 1. CSRF tokens (as Nutchanon described) -- the strongest solution,
> but requires modifying your Perl script.
>
> 2. Referer check via mod_rewrite -- lighter-weight, can be done
> in .htaccess:
>
> RewriteEngine On
> RewriteCond %{REQUEST_METHOD} POST
> RewriteCond %{HTTP_REFERER} !^https?://your.domain.com/ [NC]
> RewriteRule ^cgi-bin/ - [F,L]
>
> This isn't bulletproof (Referer can be spoofed), but it stops
> casual abuse.
>
> 3. Require expr with Referer (an alternate Apache 2.4 native approach):
>
> <Directory "/www/mysite/cgi-bin">
> <If "%{REQUEST_METHOD} == 'POST' && %{HTTP_REFERER} !~
> m#^https?://your.domain.com/#">
> Require all denied
> </If>
> </Directory>
>
> For a production system, CSRF is the right long-term answer, but
> option 2 or 3 gives you an immediate improvement over the
> Require ip 127.0.0.1 approach while you implement that.
>
> -- Rich
—
Rich Bowen
[email protected]
