Instagram Website Flaw Exposed Users' Phone Numbers and Email Addresses

Our weekly failure by Facebook.

I don’t get why the EU isn’t doing anything about Facebook or Instagram. Usually they r up on everyone’s a$$. I guess lobbying is a hell of a thing

Instagram: We’re sorry. We’ll try harder to protect your privacy.

Everyone sane: *begins taking bets on how long until the next privacy issue is discovered*

What the hell do they use as a security measure, a Trapper Keeper!?

as usual not surprising ....

By now everyone should know that those big cooperations care more about ad revenue and sale of personal data then about protecting the privacy of their user base - there is just no money in protecting the privacy and apparently users still stick with them - so no harm done in their view point.

The article is a bit jumbled on details, so hard to understand exactly what is going on. By "web site source code", I assume they mean HTML. But could be buried in some Javascript or retrieved using Ajax and then inserted into the DOM. Probably in a hidden element, hidden input, in a data- attribute, etc.

I am not at all surprised, though.

I am one of a small handful of developers who still answer questions on the jQuery developer forums. jQuery is a popular but rapidly-fading Javascript library that was created primarily to "normalize" the differences between browsers so that devs don't have to code "if this browser, do this, if that browser do that...". Instead, jQuery provides it's own API and if you use their API then it deals with the differences between browser. Rapidly becoming a Thing That Is Not Needed.

Anyhoo, I am shocked at the low level of competency on the part of the (almost always overseas) frontend devs for major Fortune 500 companies. Like, for example, the web site for a major U.S. cell phone provider that I shall not name. You'll have to cycle through the alphabet to guess, but you won't have to go very far. ;)

So, first off, how do I know that they are working for major Fortune 500 companies? Because they've repeatedly failed to reduce their examples to the minimum needed to show the problem, and just post links to their development site - which is typically open to the Internet with no security. If somebody is willing to help them, they will have to dig through mountains of code - like 50 or more JS files being loaded, with redundant plugins left by the previous devs who were hired to do Just One Thing and then moved on to other jobs for other companies. They just keep adding layer after layer of crap. And another dozen tracking scripts, etc.

Anyway, there's their logo, and say an order form for for service, or for the latest iPhone or whatnot, and they've posted a link to their example page and usually it's accessible without a password, though sometimes it needs one, which of course they post openly in an open forum.

So, I COMMONLY see things like price calculators that are being relied-upon by the backend (they have inadvertently created their very own "name your own price tool"!), and it's not uncommon for the devs to not understand that Javascript running in a browser is NO MEASURE OF SECURITY. The only reason anyone should be doing any kind of price calculations or form validations in a web page is as a convenience to the user, to avoid a trip back and forth to the server. Where the validations MUST be done again, but often never are.

It is very common to see posted PHP, C# code, etc. often with no understanding on the part of the dev that we can't help them with that - it's a jQuery forum, not a forum for some random server language. And, at the same time, no understanding that, say, the PHP code runs on the server, and the Javascript code runs in the browser. Chalk that up to the awful historical design of PHP where you can (you don't HAVE to, and this style is discouraged today) mix server and browser code in the same file. It's not uncommon for these devs to just not get it that the server is treating their file as a template, and generates HTML on the server to send to the browser, and the generated HTML (generated by the PHP code) is sent rather than the PHP.

Since we often see PHP/C#/Cold Fusion/whatever code, that means we also see their (common) SQL injection vulnerabilities and other horrors of poor or no security in server code.

I can see the described leakage easily happening because a dev made a query that returned columns that should never have been included in the page and/or the dev somehow thought there's no issue with including some extra data that "the user will never see". You know, because it is "hidden". Hidden, yes, to the casual user, but not to anybody who knows how to use the web inspection/debugging tools present in every desktop browser. Or to a scraper/crawler, which is not limited to seeing just the "visible" elements on a page.

Somebody "might have made a copy". No, it is certain that somebody made a copy. There are certainly multiple copies of the data now in scrapers archives, and they probably do not even know what they have. A scraper is just a robot - it will scrape whatever it finds and squirrel it away. Probably later, an algorithm or a human will comb through it to see what might be "interesting".

Front-end development practices, as done by many top companies, is just absolute crap. The companies piece it out to the cheapest bidder, and there is often no continuity. It gets handed off from one developer to another and again and again and again, and each adds their own layer of crap and leaves their own footprints to the mess.

Beyond that, it is OBVIOUS that many of these devs are getting their information from 10-20 year-old books (which is why I now dispose of old development books rather than them them to a charity store), outdated blogs and tutorial sites, etc. Search engines and SEO have a surprising influence on this, BTW. Because sites that work their way to the top continue to stay there for many years after they have ceased to be useful. There are so many "frozen" dev tutorial sites that just have obsolete information but were once the top reference, and the search engines do a poor job of "expiring" their rankings.

I have to admit, I often Google for answers. But I CHECK THE EXPIRATION DATE. Usually I will include a data constraint in my searches and then check any dates in the blog or tutorial, etc. to insure I am getting fresh results, and not some 10-year-old advice. You don't know how many of these devs I have to point toward MDN, CSS-Tricks, jQuery Learning Center (on the VERY SAME SITE they are posting on...) and they had no clue that these sites existed and are the best references on the development they are doing.

What this researcher uncovered is just the tip of the iceberg. It is not an anomaly. It is endemic.

Edit: It's probably not fair to place the blame on front-end developers. Much of it can be blamed on the scourge known as "full-stack development". This is the fantasy that one person can do it all - front end, back end, database, security, etc. So, you have devs that know a little bit of that, a little bit of that, much of it outdated. As well as the fantasy that developers are fungible - you can just pass off bits and pieces of functionality to whatever random dev is available or can be hired the cheapest from an online virtual sweat-shop to implement a feature and you will somehow magically wind-up with something coherent.

And that, my friends is how sausage.... er, many of the highest profile websites - are too often made.