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.
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.
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.
> 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.
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...
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.)
"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.
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.
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.
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.
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.
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?"
44 comments
[ 3.9 ms ] story [ 108 ms ] threadand weev actually had to do work to break the AT&T service... this looks like he just searched for users.
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.
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.
Although I agree that this is not ideal, zero is not null.
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.
Out[1]: False
Idiomatic Python may say "if not user_id:" and erroneously skip this.
Idiomatic test for `None` is:
It would be incorrect to use `if not something:` here."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.
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.
More exciting trend-hopping startup news out of Silicon Valley and Techcrunch.
http://techcrunch.com/2013/09/30/leaked-youtube-video-tumblr...
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.
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.
Lots of 'what?' moments in tech reporting lately...
http://twitter.github.io/typeahead.js/
If only tech journalists actually knew something about tech.
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?"