askapache

It turns out that support for the 2nd parameter of sha1 just isn’t there for older php versions.. luckily I was able to to find a workaround hack using pack

I’m releasing a new version in a couple hours.. try that one. ??

That message will only show up if the final test fails.

The final test is actually pretty freaking sweet, what it does is create a temporary directory with an .htaccess file similar to the one this plugin installs in your wp-admin folder. It then uses fsockopen, a function almost all php installations have, to request the password protected page. If the response from the server returned 500 or 200, then this plugin wouldn’t work for your wp-admin folder either.

I’m hacking the code right now so stay tuned for an update.

That is the last resort the plugin takes, it means your current server or server configuration does not work with ANY of the 4 available .htpasswd encryption algorithms.

I will be adding support for non-apache hosted blogs in the future.

Sure sounds like the plugin, more specifically I forgot to add some error checking for incompatible versions of sha1 function. I’ll get on this.

You can get the program here, AskApache Password Protect

Oh ya, and I added an additional security option to password-protect /wp-login.php

Ok I fixed it.. The problem was occurring I think because the automatic upgrade stuff somehow included the file twice. Theres really no other explanation since it literally was only in the file once. So I added 2 different tests that make sure it doesn’t get included twice and the new version works!

Oh ya, and I added an additional security option to password-protect /wp-login.php

I can’t figure it out.. sorry.

It doens’t make any sense… how can a single add_options_page be declared twice? And why does it say that its occuring on the line right underneath the real one?

I change the name of the option but apparently it is still causing this problem for many.. all with an upgraded version?

And now “Pretty Permalinks” are working on my site. Can anyone explain to me why taking out the <IfModule lines fixed the problem?? I’d just like to understand.

That is awful weird. whooami is right, if you didn’t have mod_rewrite and you removed the IfModule lines, it would have resulted in a 500 error.

What version of Apache, what type of operating system? Where is the .htaccess file at relative to your domains root? ie is it in /wordpress/.htaccess or /.htaccess?

What does the AskApache RewriteRules Viewer tell you?

Theres only one way to figure out how to fix it.. debug. Using wireshark to capture packets from my end and using mod_security in a “pass,alow,auditlog” filter I was able to dermine that swfupload is the culprit. And having an upload file for “asynchronous uploads” from clients that can’t even send basic auth headers is not moving forward in my book.

Here’s the code I eventually settled on for the AskApache Password Protect plugin.

# BEGIN AskApache PassPro
AuthName "Protected By AskApache"
AuthUserFile /home/askapache.com/.htpasswda1
AuthType Basic
Require valid-user
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|css|js)$">
Allow from All
</FilesMatch>
<Files async-upload.php>
Allow from All
</Files>
Satisfy Any
# END AskApache PassPro

If I wasn’t trying to make it as compatible as possible I would have definatately used rewriterule or just SecFilterSelectives..

Someone should notify the swfupload developer that it is relatively a cinch to add headers to requests in flash. I mean even small childrends cell phones can do basic authentication. I really like the swfupload though.. brilliant.

So hopefully someone sets their mod_rewrite to log and then we can see what rule was giving us a false positive.

Circle-

1. Not really, most bloggers don’t even know what mod_security is, and even fewer actually do have it.

The one thing that gives me pause is that it opens up a pathway for attackers to push their exploits because mod_Security won’t be turned on. And also this asnc-upload.php script has some features that lower its overall security and make it easier to successfully exploit in terms of cookies and state tracking.

2. Yes the version I released this morning completely fixes this.

Although I allowed access to the file itself, which does create a small hole in the password protection of the admin dir, mod_security is still 100% doing its thing.

Turning mod_security completely off for an upload script scares me. I had to do that for my plugin because most people don’t have mod_security, but for those of you with mod_security you might want to consider some type of access control.

Instead of

<IfModule mod_security.c>
<Files async-upload.php>
SecFilterEngine Off
SecFilterScanPOST Off
</Files>
</IfModule>

Instead I would leave it on for everyone except me, and keep it on for everyone else. But actually if I was having this problem I would go and turn on debugging to find out the security rule causing this false positive and just fix that.

<IfModule mod_security.c>
<Files async-upload.php>
SetEnvIfNoCase Remote_Addr ^208\.113\.183\.103$ MODSEC_ENABLE=Off
</Files>
</IfModule>

While working on the AskApache Password Protect plugin I also had problems with the image media uploader. I found out that WordPress 2.5 is now using a small swfuploader.swf file which is a separate application than your browser. Javascript was my first guess but its definately connecting to your server from the flash application.

Which isn’t a bad thing, just some unfinished action-script programming for the flash developer. So sounds like you guys are having a different problem than a HTTP Basic authentication one, so my guess is the flash app is using some sort of suspicious looking request in its communication with the server.

You can easily find out exactly what is triggering the mod_security rule by turning on logging. I blogged in some detail about how to do that on DreamHost.

@neuroitc

I’m curious as to what security rules/filters are being triggered by your requests to async-upload.php

I experienced an error as well when using WP 2.5 to upload to the media gallery. After some debugging I found the reason for this error is simply because async-upload.php is sent the uploaded file via a POST from an swfupload.swf file, which doesn’t have support builtin to send HTTP Basic Authorization.

I am really curious how the above code fixes the problem, I haven’t had any problems with my mod_security. Could you please do this to help me out?

1. create a file called modsec_audit.log and chmod 666
2. add the code below to your .htaccess
3. try to upload an image to make the image occur again

<IfModule mod_security.c>
SecFilterEngine On
SecFilterCheckURLEncoding On
SecFilterCheckUnicodeEncoding Off
SecFilterScanPOST On
SecAuditLogParts ABCDEFGHZ
SecAuditEngine RelevantOnly
SecAuditLog /fullpathto/modsec_audit.log
</IfModule>

Now the modsec_audit.log will explain what rule the request is matching.

Or you can just upgrade to the newer version and see if it works for you.

@bene

Thanks for spotting this, I never use the visual editor so I didn’t even realize it was happening.. I’ve been grepping my access logs for anything failing in the wp-includes or wp-content directories and this is the only one so far.

The latest version of AskApache Password Protect fixes this.

I am definately thinking it is a WordPress bug. Because its not being redeclared, at least from what I know about redeclaring functions. Its just not.

Maybe the newer AskApache Password Protect 3.6.x version will work for you.