Web security Development from "black-out GitHub"

Egor Homakov (Twitter: @homakov personal website: egorhomakov.com) is a web-safe monk who has given GitHub black for the last two days and has reported 5 security bugs to GitHub, in his blog-- "How I hacked GitHub again" (wall) explains the 5 security bugs and the idea that he hacked off GitHub. Egor This article is relatively simple, a lot of places a pen, so, I am here in my language for you to explain the black GitHub idea and the original text mentioned in the 5 bug. I hope this article can let the students engaged in web development vigilance . For security matters in Web development, you can look at this article, "What you need to know in web development"

About OAuth

First, this story starts with GitHub OAuth. So, we need to know what OAuth is first. The so-called OAuth means that third-party apps can access your own data or features on a website without having to know your account password through your authorization. Web sites like Google, Facebook, Twitter, etc. provide OAuth services, and websites that provide OAuth services generally have a lot of open APIs, and third-party apps call these APIs to develop their apps to give users more functionality, but When users use these third-party applications, these third-party applications will access the user's account functions and data, so when the third application to do these things, we can not let the third party application pop up a dialog box to ask the user for his account password, or third-party applications will be the user's password to obtain, so , the OAuth protocol jumps to a page where the user authorizes the third party to use certain permissions, and then the record of this permission is saved on the Google/facebook/twitter, and an authorization token is returned to the third-party app, So third-party applications through this token to operate a user account of the function and data, it is unimpeded. A simple explanation of the Twitter's OAuth authorization process.

From the flowchart above, we can see that oauth, whether 1.0 or 2.0, is a more complex protocol, so it's not easy to implement OAuth on the server side, it's always a little bit more or less a mistake. Egor found a couple of GitHub implementations of OAuth's problem.

OAuth's Callback

It is also important to note that because OAuth is required to jump to the main web page to allow the user to authorize, when the user authorization is finished, you need to jump back to the original page, so, in general, the OAuth authorization page will take a redirect_url parameter, used to specify the jump to the original page. This jump parameter used by GitHub is the Redirect_uri parameter. In general, Redirect_uri this parameter needs to be validated on the server side.

You think, if someone can control this redirect_uri parameter, then you can let it jump to another page (it could be a malicious webpage). If you think it doesn't matter if you jump to another page, then you're wrong. Remember, when you authorize this third-party application, the service will return an authorization token to the third-party app, which will be appended to the Redirect_uri parameter and then jump back if the redirect_ After the URI was changed to a malicious URL by someone with an ulterior motive, the token was turned over, and the authorization token was leaked.

Knowing all this, we can understand what Egor's 5 bugs mean.

The first bug-does not check the redirect URL in the/: /

First, we can see a description of this by using GitHub's Redirect_uri documentation:

If the CALLBACK URL is: http://example.com/pathGOOD:https://example.com/pathGOOD:http://example.com/path/subdir/ otherbad:http://example.com/barbad:http://example.com/bad:http://example.com:8080/pathbad:http:// oauth.example.com:8080/pathbad:http://example.org

GitHub, for Redirect_uri, has limited the need to jump back to https://gist.github.com/auth/github/callback/, meaning that the domain name is gist.github.com and the directory is/ auth/github/callback/, the server has made this restriction, it seems to be very safe.

However, Egor found that the server side of GitHub was not validated. /.. /.. /such a situation.

As a result, Egor is equivalent to constructing a redirect URL such as the following:

Https://gist.github.com/auth/github/callback/../../../homakov/8820324?code=CODE

So the above URL is equivalent to:

Https://gist.github.com/homakov/8820324?code=CODE

As you can see, the post-certification jump page goes somewhere else (not the GitHub limit)-we know that GitHub's gist, though it's for you to share snippets of code, can also be used to customize your own stuff (like Markdown), This gist Web page is, of course, controlled by Egor.

The second bug-does not have a check token

The first bug actually does not have anything, if the server to check whether the token is the same as the token generated before the Redirect_uri, as long as the server did this verification, the first bug is completely useless, but the service side of GitHub is not verified.

This is the second bug, so the first and second bugs come together as a fairly powerful security vulnerability.

That is, token generation to consider Redirect_uri, so that when the URL to jump, will be redirect_uri and tokens to the jump page (here is the jump page or github own), jump page of the server program to use Redirect_ URI to generate a token to see if it is the same as the token coming in. This is called signing the URL--to ensure that the URL is not tampered with. In general, the URL signature and signature verification factors include the source IP, the server time to intercept, the session, or add a salt or something.

The third bug-injects a cross-site picture

Now, Redirect_uri with code, safely and successfully jumps to the Egor structure of the webpage:

Https://gist.github.com/homakov/8820324?code=CODE

But this is Gist's Web page, you can't run the front-end (Javascript) or back-end program on this page (Ruby--github is done by Ruby), and now the question is how do we get that code, because that code, although brought to my web page, But that web page is still github and the user's own environment.

Here, in general, hackers will put a link on this page such as the following, to entice users to click,:

<a href=http://hack.you.com/> Private Photo </a>

This way, when the page jumps to the hacker's website, the URL on your previous page will be added to the Refere parameter in the HTTP header, so that I can get your token.

However, on the gist to put a link to the user to click on, this too affect the "user experience", it is best to embed something outside the point. Gist can be embedded in the image of the external station, but the GitHub developers are not daogaoyizhang, for the external site of the picture, it will be the URL of these images to the proxy GitHub's own URL, so you can not get it.

However, we can use a very strange trick:

What the hell is this? This is a relative path to a URL. But why would there be three///? Oh.

Thinking like a programmer

At this point, we need to think "Programmer's programming thinking"--how would you write a program that validates URLs if you're a programmer? You would have thought of using regular expressions, or using programs to match some of the pattern in the URL. So

• For the absolute path: you will match two//, the following may be [email protected] ([email protected] is optional), then there may be:<n> port number, then/, followed by the server path, and then should be? With some parameters in the back.

• For relative paths: there is no absolute path so complex. Just a few. and/or plus? and some parameters.

Well, if the relative path used in or <a href=> in the coolshell.cn Web page is/host.com, then the browser interprets it as: http://coolshell.cn/ Host.com, if it is///host.com, then it should be interpreted by the browser as http://coolshell.cn///host.com.

However, Chrome and Firefox will treat///host.com as an absolute path because it correctly matches the scheme of the absolute path. If you are using Chrome/firefox to read this article, you can look at the following connection (source code below):

Coolshell Test

<a href= "///www.google.com" >coolshell test</a>

The point is, this chrome/firefox problem is marked as won ' t Fix, I'm going to go, basically, the backstage program also has the possibility of having such a problem for Perl,python,ruby, This is a problem with the library of URL checks for node.js,php.

As a result, we can use this way to inject a picture of a third-party site (GitHub's server is unaware (because we've said that most language URLs will be bypass), but the browser gist the link to a third-party site), The HTTP header of the request for this image contains the URL of the user's current page and contains the user-authorized code, refere.

Here, the hacker Egor has got the user gist permission and can modify or view the user's private gist. But the author is not satisfied, he wants more.

The fourth bug–gist put Github_token in a cookie.

So Egor found the Github_token in the user's cookie.

But this token is useless because the scope of authorization is only gists. However, this token should not be placed in the user's cookie, itself is a security incident, this thing can only be placed on the server (on the Web development of security matters, you can look at this article "What you need to know in web development").

So, Egor can only seek another way.

Fifth bug– automatically give gist authorization

Because Gist is GitHub's own, Egor so guess GitHub want to do a little bit, when users visit Gist, will not pop up an OAuth page to allow users to authorize, otherwise, users will be very surprised, are your own things, but also authorized? So, Egor guessed that GitHub should be automatically authorized for gist, so Egor made such a URL (note the scope of the Redirect_uri in it)

https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F% 2fgist.github.com%2fauth%2fgithub%2fcallback/. /.. /.. /homakov/8820324&response_type=code&scope=repo,gists,user,delete_repo,notifications

As a result, the Redirect-uri not only helped hackers get access to the gist token, but also extended the scope of the authorization token to the user's code base and other rights. You can then black into the user's private code area.

Other & Impressions

So, the author gets the USD $4,000 bonus from Github Security Bug Bounty! Egor altogether spent 4 hours from 2 o'clock in the afternoon to 6 to find these bugs, an average of 1000 American knives per hour. Egor also very much said, if GitHub asked him to be a security adviser, he only charge for an hour of USD $ $ $ $ $ $ $ $ $, this 4 hours also $1,600. Oh. Let's see, this is how efficient the way to make money.

It's the bounty hunter on GitHub leaderboard (Https://bounty.github.com/index.html#leaderboard) You can go up and look at the problems they've found, and you'll find that there are a few security problems, Some can only be said to be not very normative problem, GitHub has rewarded hundreds of knives. I looked at GitHub's bounty policy, and the GitHub bounty was at least 100 knives, up to 5000 knives.

Let us ask ourselves how much time we have spent playing those "red envelopes" and how many red envelopes have we got? They found 5 bugs in 4 hours, earning $4000 dollars. God gave you me the same time, we used to smoke a few dollars of red envelopes, others use their skills to earn bonuses. This is the difference between people and men. This is called efficiency -you can take a look at my "overtime and efficiency"

(End of full text)

(Reproduced this site article please indicate the author and source of cool Shell –coolshell.cn, do not use for any commercial use)

--=== visit the Cool Shell 404 page to find lost children. ===--Web Security Development from "black-out GitHub"

Web security Development from "black-out GitHub"