Twitter and Romance Scams

This article should take around 3 minutes 8 seconds to read.

Twitter has a problem with romance scams (a variant of the famous 419 scams) especially romance scams targeting female users, and I thought I’d use my latest scammer to look into the issue.

As you can see “Richard” here is following 170 people and has never tweeted.

As may not be surprising, everyone “Richard” follows appears to be a women

But what is interesting is so many of us appear to be based in Scotland / political. I’m guessing that “Richard” doesn’t really care which women he follows, they are just hoping that enough of us fall for him and give him money.
So why is their such a cluster of Scottish political women they are following? My guess is they started with a single woman and followed all the women that profile was following/follows since people interested in similar topics this tactic is likely to form a group of women with similar interests.

Not only does “Richard” not follow and men (or NB people) they only one guy follows them…

Yoann, “Richard”‘s only male friend

Yoann, hasn’t tweeted much, but he does have an Instagram account https://www.instagram.com/yoann_dix/

Sadly my browser doesn’t render the emojis well, but he claimes to be a 15-year-old male model from the Ivory Coast. he also has a second Instagram account

On his Twitter bio Yoann claims to come from Abidjan, Côte d’Ivoire
Is this 15 year old kid, the scammer behind “Richard” who knows but I’ve reached out to him for comment.

Continue Reading

Implementing rate limiting with PHP

This article should take around 2 minutes 57 seconds to read.

If you’ve ever implemented a public facing API, you will know how important rate limiting is. If you don’t someone, somewhere will abuse your API’s sending millions of requests a second, either because they want to pull your your data (just ask FFS), because they want to take your service down or just because they messed up the coding and put the request in an infinite loop (… no… I’ve never done that… honest… Sorry @Jack). Whatever the reason, such a huge volume of requests will, like the “Tragedy of the commons“, cause at least a reduced service for other users and increased costs for you and, if left unchecked, eventually cause your service to start falling over.

The answer to this is of course to limit the number of requests a user can make. Their are two main approaches to this, limit by IP address or limit by account, for the purposes of this post, it doesn’t matter too much which you choose, their are good arguments for either (or both) schema’s, the one you decided to implement will be dependent on your use, threat model and willingness to manage accounts.

Regardless of which approach you choose the logic you need to follow is the same. For the purposes of the examples below I’ll assume we’re managing by a key and allowing no more than 100 requests every 10 minutes.

  1. When a request is made, and before you perform whatever function the API performs, log the key/IP address in a table. The details you store here should be just the key/IP address, the endpoint being accessed and a DateTime stamp of the transaction
  2. Perform an SQL query something like SELECT count(*) FROM table WHERE key=@key AND timestamp < DATE_ADD(CURRENT_TIMESTAMP(), INTERVAL -10 MINUTE);
  3. This will return the total number of requests in the last 10 minutes, if that’s less then 101 (101 because we’ve already logged the current request) then we can allow the call otherwise we return a failed message.

The problem with this is that this table will grow huge in a very short amount of time, therefore we should add an event to reduce the size of this table every hour or so (of courses if you want to the know exactly who has accessed what and when, you could you this as as way to log that information).

A second problem arises with this if we want to allow different limits for different users. For example you may want to allow FaceBook to make slightly more calls to your API’s then you would allow this blog to make. This can easily be implemented with a step 0.

  1. Validate the users key and retrieve their settings.

This allows you to revoke keys, set limits at the key level and do fancy things like return different data for different users (who pay different amounts) based on the program they have signed up to.

Continue Reading