Clinkle gets hacked before it even launches | Hacker News Reader

Clinkle gets hacked before it even launches

techcrunch.com

49 pointsaustenallred42 comments

Oh please, this is not a hack. Just someone who found an internal-use TEMPORARY api endpoint and ran a search query. The API did what it was programmed to do, give me a break.

While I agree just finding something isn't hacking per-se, "did what it was programmed to do" is a terrible excuse. By that definition, no exploit was hacking because it "did what it was programmed to do". Even saying "yeah it's like that by design" doesn't really excuse it.

Except in this case, as the parent mentions, it's not an excuse. Why would you secure a type-ahead API that only has access to employee testing data?

It is by design that if someone finds the API they will be able to use it without authentication and nothing is required on behalf of the "hacker" to access it. Are all users of software hackers under this definition?

I do not believe they are lying in their statement that it was temporarily open and intended to be closed, it makes sense to me why that effort would be put off for test data.

[Note: Twitter has a similar tool with the same name — it's unclear if they're one and the same.]

Lots of 'what?' moments in tech reporting lately...

Twitter does have a library named typeahead. I'm not sure if you meant that was obvious, or I'm just missing the point.

http://twitter.github.io/typeahead.js/

This was a private API endpoint. typeahead is a client-side library for a fancy autocomplete textbox from Twitter. It needs a lot of clueless to somehow connect the two things as if they were one and the same.

Seriously. It's not just Twitter...

If only tech journalists actually knew something about tech.

You can't "hack" service that doesn't exist. (I mean that until they launch this software is something obscure from the depths of internet, not a real service.)

It does exist, though whether this counts as a hack is a fair question.

A mixture of camelCase and snake_case? A travesty.

I wish I could upvote this more than once.

First comment on article from a Clinkle engineer:

"how is this different from facebook or google plus search? i type in someone's name, i get back their full name, profile photo, phone number if it's public, etc."

Fair enough, the only real personal information is your telephone number, and we don't know if they are operating like the white pages, opting out of displaying that publicly.

later on in the thread, the engineer specifies that users can make their phone numbers private.

That's an extraordinarily generous definition of hacking.

AOL employs an extraordinarily generous definition of journalists.

On one hand, I'm thinking "meh, it's in testing, it's not live, no big deal".

On the other hand, I'm thinking "how much other stuff are they going to forget to lock down when they go live?"

There are two quotes on the back of my business cards. One of them says, "If you don't have the time to do it right, when you will have the time to do it over?"

The developers of Clinkle should try to get the FBI to do a court case based on the Computer Fraud and Abuse Act.

According to the Pastebin dump, one user has a user_id = 0

Why would you even design an application to allow that? Even if the user was deleted (as potentially indicated by a null phone number), it's still a conflict.

Why do you allow an array index to start at 0?

Although I agree that this is not ideal, zero is not null.

Why wouldn't you want a user_id being 0?

I believe it has to do with Unix-like OSes always assigning the UID 0 to root.

This doesn't make any sense unless for some reason you are creating unix users based on the users in your application and using the application user ID as the unix user ID which would be silly.

The convention of 0 as NULL is more likely, as UID 0 doesn't really make sense in this context.

Perhaps some implementation might consider 0 to be a 'NULL' value, assume it's null data and thus ignore it.

NULL != 0.

That never stopped JavaScript, Python and friends from giving them equal truthiness.

> That never stopped JavaScript, Python and friends from giving them equal truthiness.

Implicit casts -- including to booleans -- are dangerous, but if you try to write APIs to try to avoid every bad thing that might happen with naive use of implicit casting in every language that might be used to consume your API, you won't be able to do anything at all.

Ehm, Python doesn't have a NULL:

  >>> NULL == 0
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  NameError: name 'NULL' is not defined

Even None, which is as close to NULL you are going to get in Python is not 0.

  >>> None == 0
  False

This is probably what the parent meant:

    >>> 'truthy' if None else 'falsy'
    'falsy'
    >>> 'truthy' if False  else 'falsy'
    'falsy'
    >>> 'truthy' if 0 else 'falsy'
    'falsy'

"truthiness" is true/false and NOT NULL! 0 != null null != false

In [1]: bool(0)

Out[1]: False

Idiomatic Python may say "if not user_id:" and erroneously skip this.

There is no `NULL` in Python. It is `None`.

Idiomatic test for `None` is:

   if something is None:
      # ...

It would be incorrect to use `if not something:` here.

When possible, you should avoid having any userid that could be mistaken for a non-userid number - it prevents a lot of silly programming errors from going unnoticed or turning into bigger problems, and has very little downside. http://www.phabricator.com/docs/phabricator/article/Things_Y...

in what world is a public profile search by name called "hacking"?

The same one where Andrew "weev" Auernheimer is in jail for three and a half years for doing essentially the same thing?

so i'm about to go to jail for using the facebook search bar?

and weev actually had to do work to break the AT&T service... this looks like he just searched for users.

For using a website's search bar, no, but for using "hacker tools" like Chrome Developer Tools' Network tab, seeing the resulting http data and then rewriting it with a trivial value change and rePOSTing that to the server -- very possibly, if you happen to stumble upon a security issue that gives you data beyond what the company initially expected you to get.

My point isn't to vilify the unknown "hacker" here but rather to suggest that what is or isn't hacking varies greatly upon whose point of view you're looking at things from, and how badly they'd like to shift the blame for their errors to someone else, and how willing they are to go after you with the full force of a federal prosecutor all too willing to jump on a trending gravy-train. We've set some very dangerous recent precedents where trivial "hacks" have resulted in very serious punishments.

PR stunt?

I doubt it, if so it is horribly misguided.

This is the first I've heard of the company and I'm not inclined to use a payment processing company where my first impression of them is they "leak user data like a sieve".

Granted, they are still in development, this can all change, etc, but my first impression is now set, and not in a positive way.

This is after their "leaked youtube video" proceeded to "reveal all" about them. Then turned out not to, or something.

More exciting trend-hopping startup news out of Silicon Valley and Techcrunch.

http://techcrunch.com/2013/09/30/leaked-youtube-video-tumblr...

If it’s a PR stunt then they choose poorly!

They are about to ask a lot of people for private information dealing with peoples money. If they have any loose API ends and choose to slough it off as no big deal, then count me out on using their product.

MHP?

Reply on news.ycombinator.com