TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

How not to write an API

407 点作者 gebe大约 11 年前

28 条评论

Mithaldu大约 11 年前
Short version: <a href="http://criticker.com" rel="nofollow">http:&#x2F;&#x2F;criticker.com</a> 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.<p>There are so many WTFs in this whole situation that it&#x27;s a wonder criticker has managed to keep the website online. Which is a shame, as it looks like a really useful website.
评论 #7370400 未加载
评论 #7370274 未加载
评论 #7370478 未加载
评论 #7375390 未加载
评论 #7370305 未加载
评论 #7370306 未加载
damon_c大约 11 年前
Whenever I get that plaintext password &quot;vibe&quot; on a site, I like to make my password something somewhat degrading go the site; like &quot;thisSiteSux!&quot;, but slightly more vulgar. It&#x27;s not my fault if they see it.<p>Once after having gotten the vibe, I ended up on phone support with the site in question. At some point I was instructed to &quot;log back in with ummmm that uhhh same password you signed up with....&quot; I could tell that my plaintext-dar hadn&#x27;t failed me that time :)
评论 #7371860 未加载
评论 #7376057 未加载
Osiris大约 11 年前
Could someone with a solid security background provide a example of how to properly handle the issues that this API fails so badly at?<p>While some developers may be able to clearly identify <i>bad</i> practices, <i>best</i> practices may not always be so clear.<p>I&#x27;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.
评论 #7371135 未加载
评论 #7371699 未加载
评论 #7371196 未加载
评论 #7370772 未加载
评论 #7370813 未加载
评论 #7371251 未加载
mercurial大约 11 年前
Somebody is trying to outshine Mt. Gox in terms of amateurism. I wouldn&#x27;t be surprised to find a number of other vulnerabilities (SQL injection ?). Who the hell thinks it&#x27;s OK to store non-encrypted passwords in this day and age? It&#x27;s not like you don&#x27;t have a major security breach every month...<p>Also, I like the &#x27;handler.php&#x27; endpoint returning some kind of ugly pseudo-SOAP. Ugh.
评论 #7370332 未加载
评论 #7370925 未加载
评论 #7370284 未加载
评论 #7371913 未加载
PythonicAlpha大约 11 年前
It 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.<p>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.<p>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.
_dztf大约 11 年前
I don&#x27;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, &quot;how appaling!&quot; - then I saw the word &quot;PHP&quot; - and went &quot;oh, well, that figures&quot;.
评论 #7370708 未加载
minimaxir大约 11 年前
<i>&lt;RequestProcessingTime&gt;-0.036264&lt;&#x2F;RequestProcessingTime&gt;</i><p>Wait, did their API return a negative processing time?
评论 #7370207 未加载
评论 #7370285 未加载
d64f396930663ee大约 11 年前
It&#x27;s a felony in the US to do what the author did here, right? Not that there&#x27;s any indication where they&#x27;re from, I&#x27;m just curious.
评论 #7371358 未加载
评论 #7370633 未加载
philjackson大约 11 年前
Despite the warning to the company back in 2010, I&#x27;m not sure he should be publishing this. He&#x27;s putting the 2000-odd users at risk by teaching us how to get their passwords and usernames like that, it&#x27;s even worse if we can get at email addresses too. I would bet the majority of those registered reuse the passwords.
评论 #7370252 未加载
评论 #7371832 未加载
评论 #7370524 未加载
victorhooi大约 11 年前
Well, it seems they took the entire API down in response:<p><a href="http://api.criticker.com/" rel="nofollow">http:&#x2F;&#x2F;api.criticker.com&#x2F;</a><p>Due to a security breach, the Criticker APIs have been taken off-line for an unspecified amount of time.<p>We apologize for the inconvenience.<p>And here I was, looking forward to actually verifying if this stuff was true...
评论 #7372350 未加载
austinz大约 11 年前
Wait, 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?
评论 #7370250 未加载
dgarrett大约 11 年前
From <a href="http://api.criticker.com/" rel="nofollow">http:&#x2F;&#x2F;api.criticker.com&#x2F;</a><p>&gt; Due to a security breach, the Criticker APIs have been taken off-line for an unspecified amount of time.<p>&gt; We apologize for the inconvenience.
octatone2大约 11 年前
What the, why? Who thought this matched any sane API authentication pattern?
jbeja大约 11 年前
It give me chills when i read this quote:<p><i>Returns the password for a user associated with the API account. Note, this can&#x27;t be used to lookup just any user&#x27;s password – the user must have been created by the API account.</i>
rdegges大约 11 年前
If anyone from the Criticker team is here on HN, I&#x27;d be happy to help you guys get this resolved -- my company Stormpath (<a href="https://stormpath.com/" rel="nofollow">https:&#x2F;&#x2F;stormpath.com&#x2F;</a>) provides a really secure way to handle user accounts.<p>I&#x27;ll help you guys integrate, or -- if you prefer, I&#x27;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&#x27;re all more than happy to help.<p>I&#x27;m randall@stormpath.com if you&#x27;d like to chat.
评论 #7371631 未加载
评论 #7370553 未加载
SideburnsOfDoom大约 11 年前
In case anyone is wondering, there are ways to use API keys securely, i.e. without sending them in plaintext on each request.<p>One common way is OAuth signed requests: <a href="http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/" rel="nofollow">http:&#x2F;&#x2F;hueniverse.com&#x2F;2008&#x2F;10&#x2F;beginners-guide-to-oauth-part-...</a> There should be an OAuth library for the language that you are using.
评论 #7373251 未加载
LukeB_UK大约 11 年前
I 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.
评论 #7370253 未加载
评论 #7370202 未加载
评论 #7370218 未加载
Sami_Lehtinen大约 11 年前
Well, bad APIs and security is the norm, unfortunately. As example DigitalOcean doesn&#x27;t use signatures, and uses static API key. Would you consider that to be secure? Especially if we aknowledge all the weakness of SSL&#x2F;TLS&#x2F;HTTPS. <a href="https://plus.google.com/+SamiLehtinen/posts/1qFhf9fAbU6" rel="nofollow">https:&#x2F;&#x2F;plus.google.com&#x2F;+SamiLehtinen&#x2F;posts&#x2F;1qFhf9fAbU6</a>
tyrick大约 11 年前
Raw 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 &#x27;NORAWPW&#x27; image in the footer perhaps. it would ease my worries, especially with cryptocurrency related webapps.
评论 #7380108 未加载
评论 #7373507 未加载
akfanta大约 11 年前
Despite all the plaintext password nonsense, I still can&#x27;t wrap my head around the fact that there is an API call for getting passwords. What legitimate use could it possibly be?
faazshift大约 11 年前
Wow... storing passwords in plain text? Even worse, non-encrypted data transport and client accessible credentials? Those &quot;programmers&quot; should be shot!
评论 #7372495 未加载
famo大约 11 年前
My opinion is that any company building an API should run at least one bug bounty on it before releasing it to the public.
thailehuy大约 11 年前
I&#x27;m not sure what is worse, the bad API&#x2F;app design, or the blog post publicly sharing how to abuse it...
评论 #7371029 未加载
agapos大约 11 年前
I am waiting for an API for a specifically designed API-maker software named &quot;Yo dawg&quot;.
Kiro大约 11 年前
How should an app utilizing an API send the API key so it can&#x27;t be hijacked with tcpdump?
评论 #7374875 未加载
评论 #7372337 未加载
joetech大约 11 年前
Someone please change the title to &quot;How not to disclose a vulnerability&quot;
teemo_cute大约 11 年前
To those of your interested on the topic, leanpub has an ebook you can get for free here:<p><a href="https://leanpub.com/yourapiisbad" rel="nofollow">https:&#x2F;&#x2F;leanpub.com&#x2F;yourapiisbad</a>
评论 #7371664 未加载
digitalpacman大约 11 年前
This post is more about security than just APIs... dislike title. Also.. I don&#x27;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&#x27;s a big deal if someone steals your key... but if you always do it over SSL, they have to steal the &quot;phone&quot; or the &quot;app&quot; that you use. And if they steal the phone... they can use things like &quot;email reset password&quot;, because email will most likely be logged in anyway.
评论 #7370535 未加载
评论 #7370490 未加载