So, it’s been a little while since I’ve posted anything, but, I’m back now, so here’s a quick Emoji plugin for Known.
I wrote this plugin (which is basically a Known wrapper around jloutsenhizer’s Javascript Emoji renderer) to scratch a particular itch of mine, whereby some Bridgy backported comments from Facebook were being rendered with Unicode placeholders.
Happy Christmas!
In my earlier post on this subject, I gave a brief overview of the Known API. I hope people found this useful.
Anyway, it is the nature of development that things change, and recently I pushed a patch that fixed a couple of potential security issues. I won’t bore you with the details, except to say that this might well have an effect on how you use the API.
In the older instance of the API, once you had authenticated, HMAC validation was short circuited and you were treated as logged in on subsequent requests (provided you remembered to store cookies). This was really a workaround to handle the way that Known would forward you to a created object after creation, and since this was a new URL, you’d need a new HMAC, but the 302 would happen before you could generate one.
Now, you are only logged in for the duration of the page visit, and sessions are destroyed after the page has been sent. Each request must now be individually signed.
Which brings us to the next big change..
Because each page request must be individually signed, it is no longer possible to forward you automatically to the created object. It is also no longer necessary for you to configure CURL to automatically handle 302 responses.
Instead, if you’re making an API request, instead of forwarding, Known will return some JSON containing a location for your next GET request, e.g.:
{
"location": "https://known.example.com/2015/example?_t=json"
}
This also gives room for extension.
Enjoy!
Ok, so here’s a quicky.
Like anyone who runs a wordpress site, I get numerous attempts from script kiddies attempting to guess the login. The vast majority of these are handled by fail2ban, but I’ve noticed an increase in the distributed kind of attack – multiple attempts to log in, but all from different IPs.
These fell below the ban threshold, so were getting through. Since strength in depth is good, and I wanted quiet logs, I thought I’d do something about this.
On inspection, it looked like the scripts aren’t terribly smart, in that they just make a POST to wp-login.php without first loading the login form, meaning they attempted to POST without setting a referrer. So, I wrote a rewrite rule that will block POST attempts to wp-login.php that have no referrer set.
This is by no means foolproof, the referrer can be easily faked, but it raises the bar slightly for them.
Place the following in your .htaccess file, or http.conf for your wordpress site:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} /wp-login\.php
RewriteCond %{HTTP_REFERER} ^$
RewriteRule .* - [F,L]
What this does is block all POST requests to wp-login.php that have an empty referrer, returning a 403 error when this occurs.
It’s very simple, and easy to work around, but seems to block most script kiddies.
To test, use curl; the following should fail:
curl -d 'test' https://example.com/wp-login.php
But this will return some content:
curl -d 'test' --referer foo.bar https://example.com/wp-login.php