My opinion is that any company building an API should run at least one bug bounty on it before releasing it to the public.
How not to write an API
161–170 of 172 posts
Re: How not to write an API
#162Short version: 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.
Due to a security breach, the Criticker APIs have been taken off-line for an unspecified amount of time.
We apologize for the inconvenience.
Re: How not to write an API
#163If 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/ ) 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…
This 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.
Thanks! 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
Re: How not to write an API
#164Earlier quoted context omitted.
upvoting you despite your inability to take a bit of good-natured ribbing
Sorry, 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 pla…
PHP's public image problem is mostly due to the direction from which you can approach it. You can be the maintainer of a static HTML page who knows nothing at all about programming, and someone can help you dip your toe into PHP by showing you some simple tricks, and suddenly you have the ability to start adding code here and there, copy/paste style, to your content. The results are predictable. And for better or for worse, the language has been given some ill-advised features in order to cater to this type of user.
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.
Re: How not to write an API
#165Earlier quoted context omitted.
Sorry, 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 pla…
PHP's public image problem is mostly due to the direction from which you can approach it. You can be the maintainer of a static HTML page who knows nothing at all about programming, and someone can help you dip your toe into PHP by showing you some simple tricks, and suddenly you have the ability to start adding code here and there, copy/paste style, to your content. The results are predictable. And for better or for…
> 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.
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.
Re: How not to write an API
#166Whenever 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…
kinda like this guy....
http://news.bbc.co.uk/2/hi/uk_news/england/hereford/worcs/75...
Re: How not to write an API
#167In 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-... There should be an OAuth library for the language that you are using.
Ways like HTTPS?
That is a different way. Which is most appropriate when is commented on here: https://news.ycombinator.com/item?id=7371484
Re: How not to write an API
#168Raw 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.
Unless 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?
Re: How not to write an API
#169Re: How not to write an API
#170Earlier quoted context omitted.
I wouldn't say I have a solid security background, but there are four best-practices I can think of that would have prevented the security vulnerabilities outlined by this post: 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…
You can also include an extra random number in the hash, and require that within the window of acceptable timestamps the random numbers have to be unique. 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.
HMAC.