Hide checksums.txt by default

[Bloke]

While there are many ways to determine which version of Txp is running on a server, should we close one simple mechanism: make checksums.txt inaccessible to the outside world? All it would involve is:

<Files checksums.txt> 
deny from all 
</Files>

added to textpattern/.htaccess. Diagnostics still runs fine because it reads the file directly. This change just makes one less essential file exposed to prying eyes. Overkill? Useful?

[bloatware]

Actually, would allowing just index.php, textpattern.[js|css] and admin-themes folder work?

[makss]

Maybe allow only index.php and static files? 1.. Files textpattern/.htaccess

order deny,allow
deny from all

<Files ~ "\.(js|css|svg|png|jpg|gif|ico)$">
        allow from all
</Files>

<Files ~ "^(index\.php|)$">
        allow from all
</Files>

setup/index.php works, but tmp/index.php works too. ;-(

---

2.. Or it is possible use mod_rewrite for this. textpattern/.htaccess

RewriteCond %{REQUEST_URI} \.(js|css|svg|png|jpg|gif|ico)$ [OR,NC]
RewriteCond %{REQUEST_URI} ^/textpattern/(setup/)?(index\.php)?$
RewriteRule ^(.*) - [L]
RewriteRule ^(.*) - [F,L]

mod_rewrite sample allow only php: /textpattern/ /textpattern/index.php /textpattern/setup/ /textpattern/setup/index.php

[rwetzlmayr]

Actually, would allowing just index.php, textpattern.[js|css] and admin-themes folder work?

No. Consider to add at least css.php.

[makss]

textpattern/css.php deprecated in 4.2.0 (2009-08-28) "This file is here for backwards compatibility."

It has been seven years in Textpattern's been a lot of changes. I do not know how this file can help with backward compatibility. Perhaps it is to remove.

[rwetzlmayr]

Wrong planet. Look here.

[makss]

I mean textpattern/css.php. link I fixed my post above.

[bloatware]

On second thoughts, we don't know what files plugins will need to access. So generic deny from all rules may be too restrictive.

[Bloke]

On second thoughts, we don't know what files plugins will need to access. So generic deny from all rules may be too restrictive.

Yeah, it would probably break MLP for starters. Well, alright, it's broken anyway but you know what I mean...

[petecooper]

Putting my pen tester (white) hat on, there are a bunch of trivial ways a Textpattern site's version number can be determined.

The easiest one for me is checksums.txt, then the <generator uri="http://textpattern.com/" version="x.y.z"> line in the Atom feed, then README.txt/HISTORY.txt (a lot of people just leave these in place), followed by checking the jQuery version, then follow up with the admin-side theme (which most people don't change) on the login page, and there are probably more.

I'd be inclined to leave as-is, especially if locking it down is going to break stuff.

[Bloke]

@petecooper Yeah, I did wonder if it was worth it given the number of other version leaks we have.

The only reason I raised it is because the checksums and the version string in the feed (which we could close) are the only definite indicators, because they are essential for site operation. You could manually change jQuery/jQueryUI version. You could omit README/HISTORY. The admin-side theme might not change much between minor versions, so the only sure-fire way would be to byte-compare the CSS file against the git version -- assuming you're not using a custom theme, as you say.

All these other methods give an indication, but not necessarily a definitive answer. As if it matters to script kiddies anyway, who fire and hope every website runs WordPress. Obfuscation isn't security, after all, hence the speculative nature of the request. If it's of limited value, I'm fine to leave it alone.

[petecooper]

I can understand the need to not be too liberal with information, especially if this is as a result of leakage, but historically Textpattern hasn't been that much of a target. Clearly things may change if more eyeballs are diverted here, and security through obscurity is not relevant.

Without giving anything away, if this is a result of a security issue/report then just ignore the above as conjecture.

[Bloke]

No security issue, just musings from my too-oft-random brain. Perhaps we'll revisit this when we run 25% of the Internet on our platform ;-)

[bloatware]

Hide it, already ;-)

[Bloke]

Closing this, as it's a potential minefield.