Bot army risk as 3,000+ apps found spilling Twitter API keys

Want to build your own army? Engineers at CloudSEK have published a report on how to do just that in terms of bots and Twitter, thanks to API keys leaking from applications. Researchers at the company say they've uncovered 3,207 apps leaking Twitter API keys, which can be used to gain access to or even entirely take over …

[Little Mouse]

But who's at risk here?

If the only compromised accounts are the ones where developers have foolishly hard-coded the authentication keys into their apps then presumably a) we're talking about a relatively small "army", and b) Joe Public isn't actually at risk.

Or did I miss something?

[yetanotheraoc]

Re: But who's at risk here?

You missed the phishing risk when Joe Public trusts a compromised account.

[iron]

Re: But who's at risk here?

There's clearly a lot of FUD going on in this article.

I'm not familiar with the Twitter API but the way these things usually work an application key will not allow account take over. It just allows the API owner to know which devs are responsible if an app misbehaves.

Posting or changing account details should require a user key or token which can't be hard-coded because it requires user login and expires.

I was expecting to hear these apps were storing user tokens in an area of memory that could be read by another app or something likie that, not hard-coded app keys.

[Anonymous Coward]

But who uses Twitter ?

I don't for one.

It's degenerated into an echo chamber for the Wokeist Wars.

Any "news" that appears there can be sourced elsewhere. And call me old school I'd rather it was accurate than early.

Also, I suspect that the more people that realise the French word for a Twitter user is "twitto", the fewer people will use it anyway.

[Charlie Clark]

Re: But who uses Twitter ?

It was an echo chamber from the get go. And it was precisely because it was an echo chamber that journalists found it so is useful, whether it was because it confirmed their bias or when they came across a group of loons spouting conspiracies.

[yetanotheraoc]

Re: But who uses Twitter ?

A "group of loons" is called an asylum of loons.

[jake]

Re: But who uses Twitter ?

And here I always thought it was a congregation of loons.

_{Six of one ...}

[Doctor Syntax]

"230 were leaking enough credentials to permit a full account takeover.

What can be done?"

Lock the owners out of the account. Tell them where they went wrong and return it to them in a week or so. If they won't learn any other way but by experience give them a little experience to learn from.

[Charlie Clark]

I for one welcome our robot overlords

I'm all for giving control to the bots it's not as if they'll post anything worse than what people already do!

[tiggity]

I wonder how much blame can be attributed to poor code examples

Cannot comment on the twitter APIs as never played with them (..obviously..)

But often when looking at code samples provided for demonstrating API use, the samples are usually focused on easy to read, quick to get up and running and try out and so often the very opposite of good security practice.

.. Consider that awareness of secure coding varies a lot across devs, and the often high pressure imposed by managers to churn code out as fast as possible I wouldn't be surprised if lots of "live" code incorporates some of the bad code patterns used in the example.

e.g. most Google maps API examples have the "key" just as part of the HTML page.

If I go to

https://developers.google.com/maps/documentation/javascript/examples/map-simple

and then click on the stackblitz link

https://stackblitz.com/github/googlemaps/js-samples/tree/sample-map-simple?file=README.md

In the index.html of that code sample I find this

<script

src="https://maps.googleapis.com/maps/api/js?key=AIzaSyB41DRUbKWJHPxaFjMAwdrzWzbVKartNGg&callback=initMap&v=weekly"

defer

></script>

i.e. sample having key plainly visible in HTML.

API providers really ought to be coerced into providing best security practice examples - may be more difficult / slower for users to get up and running but would mean better security practices likely to be used.

[Anonymous Coward]

Re: I wonder how much blame can be attributed to poor code examples

In this example the Maps API key can only be used from a specified domain hosting the web page. Unless the user has explicitly added a wildcard. In this case it will cost the cos Google charge per api call (after some free credit).

Besides locking the domain hosting the html/javascript, not sure apart from some obsfucation you can really secure client side web stuff. Android apps however is completely different story.

[Brian Miller]

Re: I wonder how much blame can be attributed to poor code examples

There's a big difference between a temporary key in a URI parameter and a key hard-coded in the source. Dumping strings from an object is old hat. Keys in source code is never a good idea. Keys in hardware is only a good idea if the key is stored in a manner that it can't be directly read, only used.

Security is supposed to be like an onion, not a waving wiener.

[Fonant]

Re: I wonder how much blame can be attributed to poor code examples

That's actually more of an identifier than a key. It tells Google which account to charge the maps API usage to.

The identifier is also linked to the page domain, in the developer's Google account settings, so you can't use someone else's API key on your own website.

You can still, if you want, keep reloading the map page to trigger payments to Google by the site owner. But only Google benefits from that.

[Michael Wojcik]

Re: I wonder how much blame can be attributed to poor code examples

Code samples? Who has time to read code samples?

I assume the developers of these apps just copy and paste from StackOverflow.

[Smeagolberg]

From the start, mobile 'App(lication)s' took the level of security and privacy characterised by the worst release of Windows ever and lowered it by 2-3 orders of magnitude.

Try telling that to the kids of today...

[Someone Else]

Wait...what?!?

While perhaps not very fashionable in the modern development world, CloudSEK recommends proper versioning replete with code reviews and approval.

Wow! The clear implication here is that all the K3wl Kidz don't use (or perhaps don't even know about) versioning and code reviews. If that is indeed true, then that explains the overall suck state of today's software (and especially the stuff spit out by "web programmers"!).

_{And I use the term "stuff" euphemistically...}

[jake]

Simple is as simple does.

"What can be done? The answer is simply good practice."

But, but, but, I coded it in RUST!!!! That's always safe, right?

_{Now get orf me lawn ...}

[Michael Wojcik]

Obvious fix

What can be done? The answer is

... don't use Twitter. There, problem solved.