[Mithaldu]

Short 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.

[theboss]

I 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.

[lbarrow]

Security is definitely hard, but security challenges are often proportional to your apps' surface area. If you just have a simple token-based API, your language probably has libraries that can get you started with a reasonably designed security story. It's the same with passwords: at this point, you shouldn't be rolling your own password management system unless you have very specific needs.

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.

[Mithaldu]

My 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]

I'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.

[mgkimsal]

"I think the reason for this is security people keep to themselves and work as consultants."

???

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.

[Killswitch]

> 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.

Any language is a security death-trap for those who don't know what they're doing.

[raesene3]

If you're worried about not being able to get access to "security people", I'd recommend looking at OWASP (http://www.owasp.org) which has a lot of good free information and also chapter meet-ups which are free.

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

[camus2]

@Killswitch

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.

[mikegirouard]

You've almost got a point there except PHP has quite a few frameworks to choose from. Mainstream ones all include, as you put it, "basic security features like auto escaping output,orms by default(so no sql strings),csrf on forms".

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".

[jimlei]

You mean like Symfony, Laravel, etc? Frameworks that a lot of PHP developers use these days...

[camus2]

You dont need a framework to do PHP webdev, in every other languages,you do.That's my point, PHP IS a templating language,no Symfony,Zend or Laravel can change that. If i write "print" in Python it wont output the result back to HTTP like PHP does. Ruby or Java dont have <?ruby or <?java tags, you get my point.

[woah]

What channel is that? As an app developer, it sounds useful.

[Mithaldu]

Find me on irc.perl.org, same name. :)

[corwinstephen]

Rails + Devise = answer to all these problems.

[euank]

I 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."

[matthewmacleod]

However, 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]

To reiterate: Any user of an app can look at the passwords of any user created with that app.

[Mithaldu]

Dammit, thanks, i corrected that.

[icebraining]

As 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]

  Due 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/

[sauerbraten]

Correction: an API account can see all users that registered through the API with that account's key.

Still, WTF!?