How not to write an API(ghost.teario.com) |
How not to write an API(ghost.teario.com) |
Stealing 2853 user's passwords, which are stored in plaintext, sent over HTTP isn't an issue? This wasn't an SQL injection, the API gives it away.
There are so many WTFs in this whole situation that it's a wonder criticker has managed to keep the website online. Which is a shame, as it looks like a really useful website.
When you are looking at a small website/API someone made for fun or something....It can normally be badly broken in less than 2-3 minutes....and I'm not even that talented like some of the guys out there.
For this reason, I don't think "I made it for fun" or "I made it over a weekend" is a good excuse for such broken security. For tiny new apps, it's easier to use a library that does it correctly than it is to roll your own.
I cannot say i am surprised though. A general amount of carelessness, undeserved self-confidence and ignorance is a given in most websites, especially when it comes to PHP.
I think that the app can only access all users registered with its api key. Same for passwords.
You say "all users registered on the site", the api says "Note, this can't be used to lookup just any user's password – the user must have been created by the API account."
Whoever created this monstrosity should be ashamed of themselves.
Due to a security breach, the Criticker APIs have been taken off-line for an unspecified amount of time.
We apologize for the inconvenience.
Still, WTF!?
Once after having gotten the vibe, I ended up on phone support with the site in question. At some point I was instructed to "log back in with ummmm that uhhh same password you signed up with...." I could tell that my plaintext-dar hadn't failed me that time :)
While some developers may be able to clearly identify bad practices, best practices may not always be so clear.
I'd love to know what a best practice would be for things like authentication to an API and some of the other issues brought up here.
Also, I like the 'handler.php' endpoint returning some kind of ugly pseudo-SOAP. Ugh.
I learned the hard way, that even the creation of internal APIs of software is hard, since you can make many errors. I made many errors, after I came from university. After I made them, I knew it better, because I had to manage an other developer that had to use it and I saw what a mess it was.
External APIs are even more difficult to create, because such things as security and others have to be covered ... but still it seems many companies thing any stuff scribbled by a student in the first semester would suffice.
Wait, did their API return a negative processing time?
In seriousness, recall the weev/AT&T case[1]. As I understand it, the attack was roughly of the sophistication of making a totally unauthenticated request to:
get_user_email_address.php?id=N
(where N was from a series of sequential integers)... and apparently the feds had a colorable argument that N constituted an "access control system", and therefore the act of iterating the entire series of possible N values (and downloading the resulting data) constituted "unauthorized access to a protected system".
Not quite in the same realm as coughing up plain-text passwords, I'll admit. But clearly some relevant authorities would set the bar for "access control system" fairly low. And apparently rank incompetence on the part of the site developer/owner appears not to come into things.
Weev was convicted to 3.5 years in prison for calling a public API with lots of different keys:
http://arstechnica.com/tech-policy/2013/03/auernheimer-aka-w...
In the UK, Daniel Cuthbert was convicted for typing "../../../" in his address bar:
Suddenly the fact that you were watching documentaries or movies that let you infer their political or sexual proclivities could be determined by outsiders.
Due to a security breach, the Criticker APIs have been taken off-line for an unspecified amount of time.
We apologize for the inconvenience.
And here I was, looking forward to actually verifying if this stuff was true...
From there he was able to use the key to get the users and plaintext passwords. Very much wtf.
> Due to a security breach, the Criticker APIs have been taken off-line for an unspecified amount of time.
> We apologize for the inconvenience.
Returns the password for a user associated with the API account. Note, this can't be used to lookup just any user's password – the user must have been created by the API account.
I'll help you guys integrate, or -- if you prefer, I'd be more than happy to dive into your source and help figure out problems and get them resolved. We have a pretty huge team of security experts, and we're all more than happy to help.
I'm randall@stormpath.com if you'd like to chat.
By the way, the alt-text for the portraits on your "About" page needs to be fixed.
Furthermore, we'll go out of our way to help you move off the platform if you want.
One common way is OAuth signed requests: http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-... There should be an OAuth library for the language that you are using.
No thanks!
1. Hash the secret API token/key given to each client that is sent to the server with each API request. This will prevent attackers from being able to find out your secret token.
If you only hash the secret token though, this still won't help, as attackers could just send other API requests along with the hashed token. Instead, you will want the client to hash other data unique to the specific API request as well. For example:
http://api.example.com/api_function_name?app_id=my_app&hash={hash_value}&other=stuff
EDIT: Clarified hash_function parameters, thanks @eru.
hash_function( secret_key, api_function_name)
This would mean attackers couldn't reuse the hashed value to send other API calls. But they'd still be able to send calls to that function and just change the parameters to the call to get other information from that API call. So, you could also include the other API call parameters in the hash_function as well, which would mean attackers could only replay that exact API call and not change any of the parameters.
You might notice, this is still not good. So, to prevent this "replay attack", you would also generally include the current datetime in the API call as well:
hash_function( secret_key, api_function_name, datetime )
This is theoretical though, because in reality the above wouldn't work well if the clocks on the client and server were at all out of sync (and they probably will be). So, usually, you'd also have to include the current datetime of the request as another parameter in the call to let the server know exactly what datetimestamp was used in the hash_function, and the server will simply make sure the datetime is within an acceptable window of the current datetime on the server. Of course, the bigger the window, the easier to get the API working with clients, but the larger the window for allowing replay attacks.
http://api.example.com/api_function_name?app_id=my_app&hash={hash_value}&other=stuff&time=datetime
OK, 1 was longer than I anticipated, but the others are pretty short.
2. Another more full-proof way to prevent attackers from getting secret tokens, hashed or unhashed, would be to make all API requests work only via HTTPS.
3. Don't provide API (or any) access to user passwords.
4. Don't store user passwords in plain-text, or even via simple hashes. Instead use a cryptographically secure hashing function with salts.
Use OAuth or similar and make sure every user has their own account. That's the only answer. Don't roll your own! Especially don't roll your own when you don't have a solid security background. You have obviously heard some of the right terms, but how and where you can apply them is at least as important as using them at all.
1. Doesn't protect anything at all. Hash functions don't do anything when people have access to the program code. No matter how fancy you go with time limited hashes (and there are smarter ways to create those). At most it adds a few minutes to the reverse engineering.
2. Again, this doesn't protect against anything. HTTPS stops intercepts on the wire, not someone who has access to your app, people can still lift the secret keys and the hashing scheme from the app binary.
3.& 4. Both true, and would protect against mass stealing of the passwords like happened here, but it wouldn't prevent abuse of the API.
There are very many people who use techniques like the ones you suggest in 1. and 2. and the same very many people have vulnerable apps that usually expose all users' data to the world. There are a lot of apps that store e.g. user files or some sort of configuration not on a per user OAuth protected storage like OneDrive, DropBox or Google Drive, but either there but on just the account of the developer, or on another storage that is only authenticated with the developer's credentials. People who do that allow anyone to read and modify the data of all users, exactly the same as people are allowed to do to their own data, or more if the credentials aren't properly limited, even if it's blocked in the app.
By the way, be aware than hash(string1 + string2) constructions are often vulnerable. hash(hash(string1) + string2) is better for most hashes, I believe. But you shouldn't roll these primitives yourself, either. Just use a proper library.
Certainly signing your requests as actually having come from your application is a legitimate means of security. But there are much lower hanging fruit (in terms of available security measures). Specifically, using SSL to handle API traffic. That should absolutely always be step 0. In instance of this specific post, had the API provider enforced using SSL as their transport protocol we probably wouldn't even be having this discussion.
There's a ton of other security measures/protocols that should be taken and followed, most of which are already talked about in other parts of these comment threads. I just wanted to really point out that what you're describing above sounds an awful lot like an HMAC code.
[1] http://en.wikipedia.org/wiki/Hash-based_message_authenticati...
If you can do that, the solution is pretty simple. Do it as you would do it with any website. Simply use https (TLS) to transmit username and password and return a session cookie to use in subsequent requests. Run your API over https only.
If you don't want your users to entrust client software (i.e. apps) with their passwords then use https with OAuth.
The reason why using https alone works well for web apps is that users can trust their browsers. Browsers can know the password and they probably won't steal it.
However, if you provide an API and you expect many different client apps, including some dubious ones, to use that API on behalf of your users then users cannot trust the client software and hence you should use OAuth.
The decision doesn't depend on whether or not your application stores sensitive data, because users often use the same password for different sites. So if you like your users and you provide an API for mobile apps to use, you should use OAuth.
This is called a shared secret.
Using the shared secret, you can come up with a unique signature, that only yourself and the host can generate.
You also want to use some sort of TTL for the signature, to prevent replay attacks.
Passwords should never be stored in plaintext. They should be hashed using a cryptographically secure hashing function (bcrypt is easy enough).
Password hashes shouldn't ever be exposed to anyone.
If you need to provide login functionality, provide a method that takes a username and password.
Make sure that username and password method has a backoff time to prevent someone from partying on that api (calling it with username and password combinations)
As the password has to be sent in clear text, make sure your login api is over SSL.
As far as APIs, the good ones will hash your secret key together along with other data unique to your HTTP request, in particular the headers and the datetime. This is a good idea because: 1. you are not sending your secret key in clear text 2. it makes it difficult for a man-in-the-middle attack because they cannot just take your hash from one of your requests since it will be invalid after received or if some time has elapsed.
For an example, see how Knox sets up requests for Amazon AWS: https://github.com/LearnBoost/knox
I'm confused. What do you do with that hash then?
Aside from that, I don't see a reason for an API to be able to retrieve passwords. If passwords need to be reset then the API could maybe issue a pass reset request that would email a confirmation link.
The plain text password is something that's beyond the API design, but a one way hash is generally better with an algorithm that is recognized as being secure (not MD5).
Basically, to repeat, simply not designing your own security but using recognized libraries will typically be a better idea.
...and an amazing number of finance organisations who can't handle non alpha-numeric characters in passwords, indicating failure to hash.
In October 2013, I received another email from Springer with my password in plaintext, and they CCed this email to another person!!
I declined my review assignments, asked them to permanently delete my account, and I haven't heard from them since.
I discovered this when on a phone call, the agent asked me what my password was, and when I refused to tell him (but offered any other aspect of my account for identity), it took a lot of convincing to get the rep to serve me. If I were malicious, I could speculate that a little social engineering may have gotten the employee to give me the password.
EDIT : To clarify, it was a comment the rep made about my password indicated that he could see my password in clear text on his screen. I asked him, and he confirmed this.
I tweeted the CTO [1], who advised me they were working on the problem, but it was still several months away from being resolved.
This level of insecurity from a major IT service provider was both shocking, and inexcusable in my humble opinion.
[1] https://twitter.com/marty_pitt/status/223622794490019843
Or they want to avoid the customer service calls "I am in Russia and use a Euro sign in my password, how do I login?!?!?!"/"Help, I have a Macbook from my brother, where is the vertical pipe (|) symbol?" so they restrict the keyspace to azAZ09 for reducing this type of error.
When I see this kind of limitation, I usually assume that they have some old mainframe with a fixed-width 7-bit password field, that would take an enormous engineering effort to change or replace.
The post gave no indication how Cricketer was storing the passwords. They may very well be stored encrypted.
You can send plain text passwords back if you've encrypted them, you just have to decrypt them first. There's no point at all in returning the results of encrypting a password if the clients don't know how to decrypt those results. Given that the API uses plain text HTTP, I doubt that the passwords are encrypted.
What the passwords are not stored as however, are hashes. A hash is not the same as text that was encrypted. A hash is a difficult to reverse unique identifier for bit of text.
Having said all this, it is funny to see your post, and all its replies making fun of security incompetency while also being incompetent in themselves.
Yes, and security-wise that's just a slightly obfuscated version of plain text.
Some modern businesses don't make the best decisions.
There is no excuse --no excuse-- for storing passwords in plain text. Anybody who attempts to justify it deserves a swift thwack in the back of the head.
The copyright is from 2004, that's only 10 years ago. I wouldn't say plaintext passwords were a sensible decision back then.
> Some modern businesses don't make the best decisions.
Some modern businesses don't have the best priorities.
I know that it'a a footnote to the insane brokenness of the rest of it, but ugh indeed. Anyone who remembered SOAP the first time around wouldn't re-invent it badly. Or at all.
What's described in this article indicates a level of incompetence far beyond any hope of forgiveness by those users. If there was any reason at all to trust the API's designers, then what you describe would be the correct response, but this is very much a case where the only rational response is to tell everyone to leave immediately, forever. It's truly an unforgivable lapse of technical judgement.
It's not the way it is because of some honest mistake that someone made, like most security bugs are. This was by design, and it's bad enough that there's no reason to believe that the designers are capable of coming up with a better design.
EDIT: As others have pointed out, he did warn them. Even more WTF then!
I've just checked and you can obtain the password through an API call
after you register a new API user.
Again, this doesn't excuse them, especially since we all know people reuse passwords. I'm just saying that the site is useful even if you know everyone can get in.
http://www.criticker.com/forum/viewtopic.php?f=8&t=2063#p188...
It will also be interesting to see if the company makes any warning that the average user will understand (e.g. "don't reuse your Criticker password on other sites, especially email or financial, because your password here is not secret, at all").
in 2010! It remains unchanged.
*Beat to the point by pille
But I stopped short on #1, as your post points out. You're absolutely right when it comes to designing an API for consumption by apps that will be distributed as packages.
I can't update my original post with a clarification, so here's what the end of #1 should have said:
1 (continued)
If either the clients' source or compiled code can be inspected by attackers (which is true for distributed, i.e. native mobile or desktop, apps), you don't want to make client app developers include their secret authentication key directly in their app. In this case, consider using OAuth 2.0 for authentication instead.
With OAuth, the client app has the user authenticate with their own credentials, where the API will respond with a per-user access token (that can easily be revoked per user if necessary), which the client app will then use for subsequent authorized requests.
See #2 in my original response concerning SSL. And notice the difference in length and complexity between #2 and #1; it was written this way intentionally to highlight the complexity of doing security authentication properly, in order to encourage the use of SSL, given that it is both more "full-proof" and simpler.
[1] https://news.ycombinator.com/item?id=7371259
EDIT: Please also see the point @Rizz pointed out, in that you'd still want to use something like OAuth, since HTTPS doesn't solve the issue of an attacker knowing your client's API key by inspecting its distributed code.
EDIT: Just realized it'd probably be clearer to replace the pluses with commas in my examples, to avoid implying the relation between the parameters of the hash_function.
hash_function( secret_key, api_function_name, datetime )One problem with storing passwords is that there is no good reason to. The other security issue is that people reuse passwords. So everyone should be creating hashes instead of encrypting passwords, but encrypting text, and transmitting it securely is still secure. This API didn't do that, it did a lot of things wrong, but these comments are all pretty ignorant as well.
It's just one inane comment after another in this thread.
If I had to think of an advantage though, it'd be for the sake of any developer who needs to design their first API, and is inspired by yours. If you just used #2 then with plain-text authentication, and a developer copies your API without using SSL, then they'll have a horrible security problem. If you used #1 as well, then they'll still have an okay API, it just won't be suitable for use by packaged/distributed client apps.
In fact, this is purely conjecture, but that could be what happened here in the case of criticker. Who knows?
As skyebook said, use HTTPS. There's no excuse.
Having said that, do use HTTPS when possible, but keep in mind some corporate environments force proxies that can see your traffic anyway.
> hash your secret key together along with other data unique to your HTTP request, in particular the headers and the datetime
So that isn't a straight hash and you can't just trivially replay. It does require you store the secret in the clear (or at least reversibly) on the server, but I see a lot of APIs do that...
I think the best thing is that people writing code just don't understand the internals of how a lot of web attacks work and why the best practices for security prevent them.
I reported two account hijack vulnerabilities on startups this weekend and was met with ``What is CSRF?''.
I think the reason for this is security people keep to themselves and work as consultants. Instead of making my own company, I can go around finding people who need what I know and get easy low-risk money.
Also, there really is no place to hire a ``security person'' at a early stage startup. If a security guy DOES get hired, it's either part of an IR team, an internal pentest team, and if this is the case then there's already way too much code written to even check it for the most basic best practices (you might use some tool for static analysis but are you really going to check out the thousands of issues?)
I don't like bashing PHP, because I think it is actually a phenomenal language for people who know what they are doing, but it is definitely a security death-trap for those who don't.
???
I know there are some pretty obscure edge cases in some successful attacks, but... almost everything I see as a security issue (and stuff I've done myself) usually falls in to XSS, CSRF and SQL injection. Those were the big 3 10+ years ago, and probably still will be. This isn't some magical 'hidden' info that a handful of security consultants hoard to themselves to maximize top dollar.
Have safe password/authentication systems, prevent XSS, prevent CSRF and prevent SQL injection - you'd prevent a HUGE number of attacks for little effort. But... it takes education, and actually caring some about your job/company/product.
"Also, there really is no place to hire a ``security person'' at a early stage startup. " Why not? I don't think they need 'hiring' full time. Many startups spend inordinate amount of time on 'user experience' and 'branding' and whatnot, with the (correct) understanding that you can't easily just 'add on' UX after the fact - it's much easier to develop UX as part of the overall dev process. Why do people not think of security the same way? Regular security audits/reviews by a security consultant (1-3 hours every week or so) would go a long way towards helping inexperienced developers spot gaping/obvious security holes well before they become big problems.
Any language is a security death-trap for those who don't know what they're doing.
Interestingly one of the problems I've faced running an OWASP chapter is how to get more developers along to it.
Also security.stackexchange.com can be quite useful
Problem is PHP is a templating language, not a generic purpose one. Other languages use frameworks for webdevs that usually provide basic security features like auto escaping output,orms by default(so no sql strings),csrf on forms...
PHP doesnt ,so it's easier to shoot yourself in the foot.
Symfony2's form component is one of the best I've ever seen. It has many sane defaults and is locked down out of the box. Read up on their use of data transformers and how they protect users against XSS without any extra effort by the user. Validating automatically looks for a CSRF token.
Whats more is that these are (for the most part) stand-alone components. You don't need to commit entirely to the full Symfony stack - you can just opt into using the components you need -- even the smallest project that only uses PHP as a "templating language".
Rarely do you see PHP developers talking about the pitfalls of big frameworks and other languages.. For example XSS vulnerabilities that recently plagued Rails.
I too have upvoted both your replies to show no ill will. Beautiful day here in Chicago and I took a little time off to cruise the city before coming back and getting back to work. Really puts you in a good mood.
The secret key is only used for signing and is never passed in the request. Used in combination with nonces and time stamps you can make a secure API that isn't susceptible to replay attacks.
It's hard to be specific without knowing what you're doing. If you have an app that connects to a third party API like Twitter, that's one situation. If you have an API that other app developers will connect to - that's a second scenario. And third is if you have an API and you write your own app to connect to it.
OAuth handles all three of these scenarios but in #1 you are a consumer, in #2 you are a provider and #3 you are both.
Check out 3-legged oAuth for an example of how to allow apps to talk to your API on behalf of a user, without that user having to give their password to the app. It's actually pretty interesting, clever and simple all at once!
HTTPS encrypts the traffic - making it difficult to sniff. It doesn't actually provide authentication though.
And you can approach it in the opposite direction, as well: as a programmer who knows what he's doing, you need to choose a language and a platform to run your app on, and PHP is ubiquitous and perfectly capable, and you know which ill-advised language features to avoid, so it's a reasonable choice.
The difference between PHP and most other languages for building web sites is that with most other languages, you simply can't follow the first path. Web servers that let you just drop snippets of ruby into HTML are not everywhere (I assume that exists in some ill-advised apache module, but I haven't personally seen it). You need to know a significant amount up front to get your code running, so the "never even considered programming before" portion of the population is naturally suppressed. It doesn't mean they don't exist or that somehow making a language more difficult to use automatically makes its users better, it just means that a certain type of amateur user is naturally suppressed, so there is proportionally fewer of them.
Note the similarities: ActionScript/Flash is actually a pretty cool piece of technology [let's ignore their poor track record with regard to security holes in the runtime, since that's an orthogonal issue]. And yet it's terrible to program in for a seasoned developer because the community is so chock full of artists and amateurs who just dipped their toe in to add some minimal interactivity to their drawings that you often have a hard time finding docs that are written above the copy/paster level. And well-written ActionScript code is a relative rarity as a result. I'm sure that on at least some level, any seasoned dev who primarily uses PHP can relate.
I agree, but funnily enough, I started at the first path, and if it wasn't for that path in 2001, I wouldn't have made it to the second path.
I dunno about Ruby, but Java certainly does: http://en.wikipedia.org/wiki/JavaServer_Pages
Also, shellscripts and perl are considered programming languages, and these too need a shebang line. Your point is invalid.
But, at least if it's implemented correctly and not maliciously, the app doesn't ever see your password.