8 ms·
How not to write an API
- octatone2 13y agoWhat the, why? Who thought this matched any sane API authentication pattern?
- Mithaldu 13y agoShort version: http://criticker.com http://criticker.com sells access to their API for apps. Any API account can retrieve a list of all users it registered on the site, then retrieve the cleartext password for each user it created. 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.
- euank 13y agoI think you got a detail wrong. 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."
- Mithaldu 13y agoDammit, thanks, i corrected that.
- matthewmacleod 13y agoHowever, the API key for any app can be discovered with zero effort, because it's included in each request. So you can retrieve the plaintext passwords for any user who has signed up with any app using the API. Whoever created this monstrosity should be ashamed of themselves.
- rmc 13y agoTo reiterate: Any user of an app can look at the passwords of any user created with that app.
- sauerbraten 13y agoCorrection: an API account can see all users that registered through the API with that account's key. Still, WTF!?
- sauerbraten 13y agoCorrection: an API account can see all users that registered through the API with that account's key. Still, WTF!?
- theboss 13y agoI dont think you realize how common the WTFs in this situation are. If you are dealing with a reputable company, this is super super WTF. 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.
- Mithaldu 13y agoMy day job is web developer and i sit in an IRC channel where roughly half the traffic is making fun of security issues of sites. Such a glorious combination of fuckups doesn't come about that often. I'm honestly more apalled that the passwords are in plaintext than that they expose them like that. 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.
- theboss 13y agoI'm not sure I agree with ``carelessness, undeserved self-confidence'' but I definitely agree with ignorance. 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.
- Killswitch 13y ago
- icebraining 13y agoAs a user, I can say it is a useful site, and the score prediction engine is very accurate, in my experience. Shame about this, it's truly a security clusterfuck.
- elwell 13y agoDue to a security breach, the Criticker APIs have been taken off-line for an unspecified amount of time. We apologize for the inconvenience. [0] - http://api.criticker.com/ http://api.criticker.com/
- LukeB_UK 13y agoI hope that the author notified Criticker about these issues before putting them out there on the internet. Not doing so would be extremely irresponsible and is sort of screwing over the users of Cricketer.
- pille 13y agoHe claims to have notified Criticker in 2010, and links to a post on their forum (username teario): http://www.criticker.com/forum/viewtopic.php?f=8&t=2063#p18825 http://www.criticker.com/forum/viewtopic.php?f=8&t=2063#p188...
- LukeB_UK 13y agoThanks for that, I skipped over that paragraph.
- CatMtKing 13y agoI don't think his post was blatant enough for the devs to pick up on it. Seems like the only guy that responded tl;dr'd it. He should have stated very clearly that this is a MAJOR security issue.
- makaveli8 13y agoAgreed - He didn't even say that it was an issue at all. He seemed more concerned that the users are scoped to particular API keys and that he will lose his reviews.
- 6cxs2hd6 13y agoFrom a quick glance at their forums, there are no posts about this (yet). It will be interesting to see how users feel about this. 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").
- 13y ago
- minimaxir 13y ago<RequestProcessingTime>-0.036264</RequestProcessingTime> Wait, did their API return a negative processing time?
- greglindahl 13y agoWhen you trade security for speed, amazing things can happen!
- viraptor 13y agoWhat are the chances of code reviews for free time? (processing_time = start - end ?)
- jschmitz28 13y agoThe Math.abs is run client side.
- austinz 13y agoWait, just to be clear - so anyone who downloads this app can trivially retrieve the username and password for all 2000+ users of the app? Did I misunderstand the article?
- k1kingy 13y agoBasically yes. As he did, he managed to get the API key by doing a TCP dump. From there he was able to use the key to get the users and plaintext passwords. Very much wtf.
- philjackson 13y agoDespite the warning to the company back in 2010, I'm not sure he should be publishing this. He's putting the 2000-odd users at risk by teaching us how to get their passwords and usernames like that, it's even worse if we can get at email addresses too. I would bet the majority of those registered reuse the passwords.
- Kequc 13y agoIt's a timebomb. If the company won't fix it then the problem gets worse and worse, waiting 4 years before setting it off is long enough.
- bm1362 13y agoIt's not particularly sensitive data being jeopardized- isn't it just movie reviews?
- choult 13y agoGiven the prevalence of password reuse, exposing user passwords is never a good idea.
- mikeash 13y agoJust to drive this home a little more: a lot of your users will use the exact same e-mail address and password on your site that they use for their bank. And while they shouldn't do that, they will, and that's why you should use best practices to protect your users' credentials even if their account on your site is completely unimportant.
- bm1362 13y agoAh, yes, I missed the "I would bet the majority of those registered reuse the passwords." from parent.
- danielharan 13y agoBesides choult's point, users can often be de-anonymized based on just a few ratings. Someone did this by cross-referencing dates in the Netflix data set and those available on one of the bigger sites. Suddenly the fact that you were watching documentaries or movies that let you infer their political or sexual proclivities could be determined by outsiders.
- mercurial 13y agoSomebody is trying to outshine Mt. Gox in terms of amateurism. I wouldn't be surprised to find a number of other vulnerabilities (SQL injection ?). Who the hell thinks it's OK to store non-encrypted passwords in this day and age? It's not like you don't have a major security breach every month... Also, I like the 'handler.php' endpoint returning some kind of ugly pseudo-SOAP. Ugh.
- minimaxir 13y agoNon-encrypted passwords are an artifact of legacy systems, and some modern businesses believe that the risk of plain-text passwords being leaked is lower than the risk of systems breaking due to updating passwords/authentication to an encrypted schema. Some modern businesses don't make the best decisions.
- mercurial 13y ago> Non-encrypted passwords are an artifact of legacy systems 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.
- vrybas1 13y ago↑ This!
- wldlyinaccurate 13y agoNo, non-encrypted passwords are an artefact of poor design and incompetent programmers. Cryptographic hashing has been around since the 70's, and cryptography itself pre-dates history. 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.
- scoot 13y ago"Who the hell thinks it's OK to store non-encrypted passwords in this day and age?" You'd be surprised: http://plaintextoffenders.com/ http://plaintextoffenders.com/ ...and an amazing number of finance organisations who can't handle non alpha-numeric characters in passwords, indicating failure to hash.
- d64f396930663ee 13y agoIt's a felony in the US to do what the author did here, right? Not that there's any indication where they're from, I'm just curious.
- rpedela 13y agoFelony for what?
- msost 13y agoAssuming the user "Injustice" isn't the blog post author's account, yeah they shouldn't be logging into it, even just to prove the legitimacy of an exploit.
- feralmoan 13y agoI'm going to say FU to the industry and buy a horse ranch if it is! These were all public documented endpoints and 'worked as intended'. criticker is next-level incompetence, that's pretty much the point.
- jamestnz 13y agoWell saddle-up, my friend ;-) 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. [1] https://news.ycombinator.com/item?id=4808676 https://news.ycombinator.com/item?id=4808676
- feralmoan 13y ago
- rdegges 13y agoIf anyone from the Criticker team is here on HN, I'd be happy to help you guys get this resolved -- my company Stormpath (https://stormpath.com/ https://stormpath.com/) provides a really secure way to handle user accounts. 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.
- iconjack 13y agoDoes Stormpath have a painless way to extract user data? I worry about lock-in.
- rdegges 13y agoYah -- you can use the API to export stuff really easily. We also have export scripts and stuff. Furthermore, we'll go out of our way to help you move off the platform if you want.
- austinz 13y agoThis looks like something a lot of startups could benefit from, even those who can't be arsed to care one whit about security otherwise. By the way, the alt-text for the portraits on your "About" page needs to be fixed.
- chunsaker 13y agoThanks! The website is shiny new, and I added this to our list of bugs to squash. Any and all bugs/suggestions welcome --> claire@stormpath.com
- jbeja 13y agoIt give me chills when i read this quote: 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.
- PythonicAlpha 13y agoIt seems to me, that many companies think, that computer science is just plainly simple. You can just put any task to a new bachelor or even student that claims he can program. 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.
- digitalpacman 13y agoThis post is more about security than just APIs... dislike title. Also.. I don't see how this is an issue. If the user signs up via your app... and you wanted their password. You have it. Sure it's a big deal if someone steals your key... but if you always do it over SSL, they have to steal the "phone" or the "app" that you use. And if they steal the phone... they can use things like "email reset password", because email will most likely be logged in anyway.
- ancarda 13y ago>I don't see how this is an issue 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.
- makaveli8 13y agoThe problem is that the app uses the same API key no matter what device it is installed on. If you download the app today you can find the API key and use it to retrieve the passwords for any users that have signed up to Criticker using the app - just as the author has done.
- aashishkoirala 13y agoI don't care if this comes off as trolling, but here it is: as I read through this, I thought to myself, much like the author, "how appaling!" - then I saw the word "PHP" - and went "oh, well, that figures".
- Killswitch 13y agoI don't care if this comes off as trolling, but here it is: as I read through this, I thought to myself, much like the author, "how appaling!" - then I saw the word "PHP" - and went "oh, well that means there's gonna be a bunch of people hating on a language because one developer doesn't know what he's doing and happens to be using that language".
- hamburglar 13y agoAll the php hate I've seen over the years is because of one guy who doesn't know what he's doing? ;)
- Killswitch 13y agoOh yeah, I forgot, because of the low barrier of entry, PHP is the only language in the history of all programming languages where there are people who don't know what they are doing. Forgot that all Python, Ruby, etc devs are gods gift to programming and don't make mistakes. My good, your bad.
- hamburglar 13y agoupvoting you despite your inability to take a bit of good-natured ribbing
- Killswitch 13y agoSorry, just as a PHP developer who understands his language isn't perfect but is growing and fixing pains, it annoys me to see people who don't use or haven't used the language since PHP4 talk trash about it as if they've been a PHP developer for years and use it daily. 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.
- thailehuy 13y agoI'm not sure what is worse, the bad API/app design, or the blog post publicly sharing how to abuse it...
- ephemeralgomi 13y agoFor future reference, the bad API/app design is worse.
- Osiris 13y agoCould someone with a solid security background provide a example of how to properly handle the issues that this API fails so badly at? 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.
- deleted 13y ago[deleted]
- cjfont 13y agoWhen I have a simple app send a password to the server, I like to generate a hash on the client side and then rehash again on the server for storing. 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 https://github.com/LearnBoost/knox
- viraptor 13y ago> I like to generate a hash on the client side I'm confused. What do you do with that hash then?
- deleted 13y ago[deleted]
- damon_c 13y agoWhenever I get that plaintext password "vibe" on a site, I like to make my password something somewhat degrading go the site; like "thisSiteSux!", but slightly more vulgar. It's not my fault if they see it. 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 :)
- dgarrett 13y agoFrom http://api.criticker.com/ http://api.criticker.com/ > Due to a security breach, the Criticker APIs have been taken off-line for an unspecified amount of time. > We apologize for the inconvenience.
- teemo_cute 13y agoTo those of your interested on the topic, leanpub has an ebook you can get for free here: https://leanpub.com/yourapiisbad https://leanpub.com/yourapiisbad
- Killswitch 13y agoHere's another good one, mainly in PHP https://leanpub.com/build-apis-you-wont-hate https://leanpub.com/build-apis-you-wont-hate
- faazshift 13y agoWow... storing passwords in plain text? Even worse, non-encrypted data transport and client accessible credentials? Those "programmers" should be shot!
- nyrina 13y agoIf we started killing people for making mistakes, none of us would be alive.
- victorhooi 13y agoWell, it seems they took the entire API down in response: http://api.criticker.com/ http://api.criticker.com/ 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...
- deleted 13y ago[deleted]
- deleted 13y ago[deleted]
- Sami_Lehtinen 13y agoWell, bad APIs and security is the norm, unfortunately. As example DigitalOcean doesn't use signatures, and uses static API key. Would you consider that to be secure? Especially if we aknowledge all the weakness of SSL/TLS/HTTPS. https://plus.google.com/+SamiLehtinen/posts/1qFhf9fAbU6 https://plus.google.com/+SamiLehtinen/posts/1qFhf9fAbU6
- SideburnsOfDoom 13y agoIn case anyone is wondering, there are ways to use API keys securely, i.e. without sending them in plaintext on each request. One common way is OAuth signed requests: http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/ http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-... There should be an OAuth library for the language that you are using.
- jcromartie 13y agoWays like HTTPS?
- SideburnsOfDoom 13y agoThat is a different way. Which is most appropriate when is commented on here: https://news.ycombinator.com/item?id=7371484 https://news.ycombinator.com/item?id=7371484
- Kiro 13y agoHow should an app utilizing an API send the API key so it can't be hijacked with tcpdump?
- CornishPasty 13y agoBy using HTTPS/SSL. But the onus of that is on the API provider...
- thedufer 13y agoIt also doesn't help that much - you can still look up the api key in the package, which isn't a whole lot harder. You could probably sign your own cert, tell your device to trust it, and MITM it, too.
- astral303 13y agoYou can't really avoid it. If the API key is hardcoded in the client, it's just a matter of time and patience until it's extracted. Never trust the client.
- joetech 13y agoSomeone please change the title to "How not to disclose a vulnerability"
- akfanta 13y agoDespite all the plaintext password nonsense, I still can't wrap my head around the fact that there is an API call for getting passwords. What legitimate use could it possibly be?
- dancecodes 13y agoLook also about howto write good API: http://theamiableapi.com/2012/01/16/java-api-design-checklist/ http://theamiableapi.com/2012/01/16/java-api-design-checklis... found that nice article in: http://stackoverflow.com/questions/10323622/java-api-design-internal-design http://stackoverflow.com/questions/10323622/java-api-design-...
- tyrick 13y agoRaw password storage is more common than we like to believe. A simple way for webapps to communicate that raw passwords are not being stored would be convenient. A small 'NORAWPW' image in the footer perhaps. it would ease my worries, especially with cryptocurrency related webapps.
- aphistic 13y ago"Designed for IE" "Designed for Netscape" "Designed in Notepad" No thanks!
- psquid 13y agoUnless the footer image in question was awarded by some kind of auditing body (with links back to their page so a visitor could verify the site really was audited), an idea like that has no fangs - for example, what's to stop a site storing them in plaintext because "it's easier, and we'll fix it when we have time" but throwing the image in the footer anyway to ensure they don't lose users in the meantime?
- tyrick 13y agoRaw password storage is more common than we like to believe. A simple way for webapps to communicate that raw passwords are not being stored would be convenient. A small 'NORAWPW' image in the footer perhaps. it would ease my worries, especially with cryptocurrency related webapps.
- agapos 13y agoI am waiting for an API for a specifically designed API-maker software named "Yo dawg".
- famo 13y agoMy opinion is that any company building an API should run at least one bug bounty on it before releasing it to the public.