精巧なセキュリティコード - 大きな櫛のテストを考えます

1はじめに

操作コードと認証コード：セキュリティ分野では、検証コードは2つのカテゴリに分類され

コードがありますが、しかし、責任の両方が完全に異なっています。

このようなログインコードとして操作コードは、主にチューリングテストの方法の一部では、人間と機械との間で区別するために使用します

認証の信頼の問題を解決するために、人々に主に起因するアカウントを決定するために使用されるコード、ので、認証コードのためのより適切な名前

2つの分割位置決め、派生セキュリティ上の問題との間の差が、セキュリティ上の懸念は異なる点です。

すべてのコードに関連する例は、洗練雲の中のこの記事では、分析し、まとめて、いくつかの再利用可能な方法と経験を描きます。

私はあなたがテストや監査のより完全なアイデアを持っているために、検証コード関連事業に遭遇したとき、これは、読者にいくつかの小さな助けを与えることを願っています。

PS：このプロセスでは、私は実際に確認コードの場合には雲、そして症例の種類の主なタイプは、私は通常、基本的にほぼ同じで、発生したことを見出した（8つのカテゴリおよびカテゴリ5）

元プログラマーのミスは、すべての国を超えている似ています:)

2つの安全な操作コード

動作確認コードは、主に3つの問題を解決するには：

1、アカウントのブルートフォース

図2に示すように、高周波インタフェースアクセス

図3に示すように、二次肯定応答敏感操作（CSRF）

実際にはこれらの3つの問題は、すべて、この操作を区別する人間の問題に属し、最後に要求が人為的、自主的に発行されていませんか？

コードセキュリティ、以下の点を中心に展開さ：

図1に示すように、コードの再利用（特定のアカウントのブルート力、CSRF）

2は、確認コードを識別することができる（ブルート特定のアカウント）

図3は、クライアントは、確認コード、表示、確認を生成する（ブルート特定のアカウント、CSRF）

図4に示すように、エアバイパス認証コード（特定のアカウントのブルート力、CSRF）

図5に示すように、確認コード（特定のアカウントのブルートフォース）の限られた数の

6、クライアントを制御するかどうかをチェック（特定のアカウントのブルートフォース、CSRF）

図7に示すように、予測可能な検証コード（特定のアカウントのブルートフォース）

図8に示すように、エラーコード（ヒットライブラリー）を開く前に一定回数以上

私は雲のメタ分析上のすべてのコードのケースを持っている、63の関連例の合計、以下の統計情報を取得します。

再利用可能なコードが0x01

これは、セキュリティ上の問題の最も一般的なタイプのセキュリティコードですが、また、最も簡単には、クラスを欠場します

セッションの生成は、多くの場合、発生と結合検証コードを伴ったときに一般的には、検証コードは、セッションにバンドルされています。

ページにアクセスし、認証コード生成要求インターフェースを可能にする、一般的に非同期であるときに、2つの機能が独立になります。それは我々が唯一のトリガすることなく、インタフェースを要求した場合、確認コードを生成し、コードが変更されないことを意味します。

そして、安全上の懸念を考慮して開発者は、確立されたビジネスプロセスに従ってアクセスし、検証する（インターフェースを行くかどうか、ユーザーを犠牲にしないで再充てんを通じて、ビジネス・プロセスを通って入ることにより、コードを検証する傾向がありますコードジェネレータ同時に）かどうか、確認コードは、複数回使用されます。

理論的には、任意のコードが、それ以外の場合は、セキュリティ上の問題につながる可能性があり、一回または複数回使用することができます

ケース1（コードが正しく入力されている場合、リセットを破壊しません）

ユーザーが正しいコードを入力すると、プログラムは、問題の破壊をリセットするために、コードを無視して、直接ビジネスプロセスに、チェックで考えられています。

私たちは、正しいコードを入力した後、コードを再利用し続けることが、ブルートフォースの問題の特定口座へのリード線

ポイント27でWooYunケース

http://www.anquan.us/static/bugs/wooyun-2015-0116594.html 验证正确，未销毁
http://www.anquan.us/static/bugs/wooyun-2016-0169672.html 正确，未销毁
http://www.anquan.us/static/bugs/wooyun-2015-0164315.html 正确，未销毁
http://www.anquan.us/static/bugs/wooyun-2015-0111128.html 正确，未销毁
http://www.anquan.us/static/bugs/wooyun-2015-0110497.html 校验正确后，未销毁
http://www.anquan.us/static/bugs/wooyun-2015-0102697.html 校验正确后，未销毁
http://www.anquan.us/static/bugs/wooyun-2015-099708.html  校验正确后，未销毁
http://www.anquan.us/static/bugs/wooyun-2015-093065.html  校验正确后，未销毁
http://www.anquan.us/static/bugs/wooyun-2014-087890.html  错误，未销毁，可爆破
http://www.anquan.us/static/bugs/wooyun-2014-085942.html  校验正确后，未销毁
http://www.anquan.us/static/bugs/wooyun-2014-084180.html  同上
http://www.anquan.us/static/bugs/wooyun-2014-083092.html  同上
http://www.anquan.us/static/bugs/wooyun-2014-083274.html  同上
http://www.anquan.us/static/bugs/wooyun-2014-082783.html  同上
http://www.anquan.us/static/bugs/wooyun-2014-074661.html
http://www.anquan.us/static/bugs/wooyun-2014-070959.html
http://www.anquan.us/static/bugs/wooyun-2014-056990.html  输入错误时销毁，正确时不销毁
http://www.anquan.us/static/bugs/wooyun-2014-050862.html
http://www.anquan.us/static/bugs/wooyun-2014-049064.html
http://www.anquan.us/static/bugs/wooyun-2013-046547.html  异步机制请求验证码，未销毁
http://www.anquan.us/static/bugs/wooyun-2013-028024.html  同上
http://www.anquan.us/static/bugs/wooyun-2013-025053.html  未销毁
http://www.anquan.us/static/bugs/wooyun-2013-020460.html
http://www.anquan.us/static/bugs/wooyun-2012-013915.html  未销毁
http://www.anquan.us/static/bugs/wooyun-2012-06226.html
http://www.anquan.us/static/bugs/wooyun-2011-03450.html

ケース2（確認コードの入力エラー、破壊されていません）

ユーザーコードが間違って入力されると、プログラムがコードをリセットしません、また、セキュリティ上のリスク

しかし、確認コードを爆破、それは何ですか？我々はすでにそれを見ることができます

敏感な操作CSRF防衛検証コードと検証コードがある場合は比較的弱く、我々はバイパスに防衛を爆破JSでスクリプトを書くことができます

認識コードが0x02

ケース1（単純すぎる認証コード）

この検証コードは単純すぎる、明確な、識別可能な高の最も簡単な部分は、あなたが識別するためのプログラムを書くことができ、リード防衛システムは、確認コードを失敗しました

7同様の例WooYunの合計：

http://www.anquan.us/static/bugs/wooyun-2016-0204186.html
http://www.anquan.us/static/bugs/wooyun-2016-0194576.html
http://www.anquan.us/static/bugs/wooyun-2016-0176919.html
http://www.anquan.us/static/bugs/wooyun-2015-0120388.html
http://www.anquan.us/static/bugs/wooyun-2012-012722.html
http://www.anquan.us/static/bugs/wooyun-2012-011765.html
http://www.anquan.us/static/bugs/wooyun-2012-010851.html

実際には、より多くの困難は、これよりもさらに複雑な確認コードを識別するために、いくつかの高い認識精度があり、我々はテストにバランスの効果とコストを把握します

0x03のクライアントは/ディスプレイ/チェックを生成し、

ケース1（クライアントが生成したテキストコードし、サーバーのIMG上の要求に対応します）

このプログラムは、クライアントにテキストコードを生成し、サーバIMGへの要求に対応するテキストは、クライアントに直接コードを取得するために私たちを導きます

プログラムコード層生成のimgを追加し、クライアント側でテキストの検証を生成します

ケース2（クライアントは、コードを生成し、HTMLタグを出力します）

クライアントプログラムは、htmlタグの単一のフォームにコード、および出力を生成し、チェックするのに便利かもしれ？

5同様の例WooYunの合計：

http://www.anquan.us/static/bugs/wooyun-2015-0161823.html
http://www.anquan.us/static/bugs/wooyun-2015-0146767.html
http://www.anquan.us/static/bugs/wooyun-2015-099909.html
http://www.anquan.us/static/bugs/wooyun-2012-06634.html
http://www.anquan.us/static/bugs/wooyun-2012-012829.html
https://xz.aliyun.com/t/4487

ケース3（サーバが認証コードが、クライアントにクリアテキストのバックを生成）

验证码生成之后，向客户端返回了验证码文本（Cookie、body）

WooYun中共有6个类似案例：

http://www.anquan.us/static/bugs/wooyun-2013-023090.html
http://www.anquan.us/static/bugs/wooyun-2012-010524.html
http://www.anquan.us/static/bugs/wooyun-2012-05151.html
http://www.anquan.us/static/bugs/wooyun-2012-03967.html
http://www.anquan.us/static/bugs/wooyun-2014-075186.html
http://www.anquan.us/static/bugs/wooyun-2014-073811.html
https://xz.aliyun.com/t/4533

0x04 空验证码绕过

如果你的代码是这样写的，那就会存在安全问题

if isset($_POST['captcha'])
{
    ....
}

login();

当验证码为空时，不进入验证码判断流程，直接进入业务逻辑

WooYun中有6个类似案例：

http://www.anquan.us/static/bugs/wooyun-2015-0150406.html
http://www.anquan.us/static/bugs/wooyun-2013-028061.html
http://www.anquan.us/static/bugs/wooyun-2013-025065.html
http://www.anquan.us/static/bugs/wooyun-2012-014224.html
http://www.anquan.us/static/bugs/wooyun-2012-08287.html
http://www.anquan.us/static/bugs/wooyun-2014-049531.html

0x05 验证码数量有限

当程序使用静态的图片，而不是动态生成验证码时，图片的数量将是有限的。

我们可以将其全部取回并计算md5，以此绕过验证码机制。

WooYun中有2个类似案例，之前的12306也属于这种情况

http://www.anquan.us/static/bugs/wooyun-2015-0102178.html
http://www.anquan.us/static/bugs/wooyun-2012-07413.html

0x06 是否校验可控

天才才能写出来的验证码校验机制，请求中存在一个字段，来决定是否进行校验，修改为 false(0) 即可

WooYun中有5个类似案例

http://www.anquan.us/static/bugs/wooyun-2014-071289.html
http://www.anquan.us/static/bugs/wooyun-2013-034367.html
http://www.anquan.us/static/bugs/wooyun-2013-026219.html
http://www.anquan.us/static/bugs/wooyun-2012-014563.html
http://www.anquan.us/static/bugs/wooyun-2014-082981.html

0x07 超过次数才开启验证码

接口在登录错误超过一定次数后才会开启验证码，这种机制要么是基于ip判断，要么就是基于session判断，要么是基于账号判断

案例1 （基于session）

如果是基于Session判断，我们清空session即可绕过。

WooYun中有1个类似案例

http://www.anquan.us/static/bugs/wooyun-2015-0114450.html

案例2 （基于ip）

如果是基于ip判断，我们可以尝试ip是否可以伪造，或者使用代理池

WooYun中有1个类似案例

http://www.anquan.us/static/bugs/wooyun-2014-080327.html

案例3 （基于账号）

服务端的限制仅针对于特定账号，比如某账户错误5次以上开启验证码。

这种情况下虽然无法暴力破解特定账户，但是仍然可以实施撞库攻击

WooYun中有2个类似案例

http://www.anquan.us/static/bugs/wooyun-2015-0149748.html
http://www.anquan.us/static/bugs/wooyun-2016-0193985.html

0x08 验证码可预测

当验证码与时间戳等因素强相关时，就不再具有随机性的属性，导致验证码形同虚设。

WooYun中有1个类似案例

http://www.anquan.us/static/bugs/wooyun-2015-0115041.html

3 身份验证码安全

身份验证码主要是为了验证操作人身份，然后进行密码修改、账户变更、重要操作等功能。

而这类验证码主要牵扯到5类安全问题：

1、验证码返回给客户端

2、业务流程缺陷

3、验证码无时间间隔限制

4、验证码可爆破

5、验证码在客户端生成

将乌云中的案例去重、去无关案例后，有41个身份验证码的案例，分布如下：

0x01 验证码返回客户端

服务器将验证码明文返回给客户端，本来觉得这种错误比较低级，没想到这样的案例还挺多。

大致有三种可能，一种是验证码校验在客户端进行，这种错误太低级了，可能性不大。

另一种情况：

1、客户点击获取验证码

2、程序生成一个随机验证码，将参数拼接之后，提交给短信API

3、客户端需要判断是否发送成功，所以程序将短信API返回的内容交给了客户端

作为一个短信API，很有可能会在response中包含了发送的短信内容，导致验证码的泄露

最后一种情况，开发写API的时候，为了方便调试，返回了这些信息，后来忘删了...

案例

WooYun中有15个类似案例

http://www.anquan.us/static/bugs/wooyun-2016-0179467.html
http://www.anquan.us/static/bugs/wooyun-2016-0172266.html
http://www.anquan.us/static/bugs/wooyun-2015-0139468.html
http://www.anquan.us/static/bugs/wooyun-2014-085124.html
http://www.anquan.us/static/bugs/wooyun-2014-082114.html
http://www.anquan.us/static/bugs/wooyun-2014-078687.html
http://www.anquan.us/static/bugs/wooyun-2014-066510.html
http://www.anquan.us/static/bugs/wooyun-2014-049813.html
http://www.anquan.us/static/bugs/wooyun-2014-049547.html
http://www.anquan.us/static/bugs/wooyun-2013-042464.html
http://www.anquan.us/static/bugs/wooyun-2013-024195.html
http://www.anquan.us/static/bugs/wooyun-2013-022009.html
http://www.anquan.us/static/bugs/wooyun-2013-019668.html
http://www.anquan.us/static/bugs/wooyun-2014-085124.html
http://www.anquan.us/static/bugs/wooyun-2014-082114.html

0x02 业务流程缺陷

涉及到验证码的业务，通常都分为多步进行，比如修改手机号功能：认证原手机号 -> 填写新手机号

当下一步的业务，没有校验上一步的认证是否成功时，就会存在逻辑缺陷绕过。

案例1 （修改response绕过）

填写手机验证码时填任意值，然后修改请求的response包中的标识字段，将其修改为true，即可绕过

实际上这种问题，本质上也是业务流程的逻辑缺陷问题。

虽然验证码的校验在服务端进行，但是下一步的业务，并没有校验上一步的认证是否成功，两者之间是独立的

这就导致我们可以修改response，让客户端直接跳入下一次逻辑，我们也可以审计源码，直接找出下一步的url

WooYun中有5个类似案例

http://www.anquan.us/static/bugs/wooyun-2015-0151201.html
http://www.anquan.us/static/bugs/wooyun-2015-0120951.html
http://www.anquan.us/static/bugs/wooyun-2015-0119252.html
http://www.anquan.us/static/bugs/wooyun-2015-0104509.html
http://www.anquan.us/static/bugs/wooyun-2015-090379.html

案例2 （手机号合法性）

在验证码校验过程中，程序应严格检查对应关系，即接收验证码的手机号，是否是该账户对应的手机号

如果不存在这处对应关系校验，则会衍生出各种逻辑问题，比如用自己的手机通过验证，然后修改其它人的信息

其实这种情况下，也是存在业务流程缺陷的问题。下一步的业务，并没有校验上一步业务中，手机号是否是属于该账户的

http://www.anquan.us/static/bugs/wooyun-2015-0102205.html
http://www.anquan.us/static/bugs/wooyun-2011-03099.html
http://www.anquan.us/static/bugs/wooyun-2014-080315.html

0x03 验证码无时间间隔限制

服务端对用户请求短信的频次没有时间间隔限制，或者是在客户端限制，可导致短信资源滥用

没有基于session、ip、账户的限制，属于完全无限制的情况

http://www.anquan.us/static/bugs/wooyun-2012-010102.html
http://www.anquan.us/static/bugs/wooyun-2012-010556.html
http://www.anquan.us/static/bugs/wooyun-2012-04876.html
http://www.anquan.us/static/bugs/wooyun-2012-04771.html
http://www.anquan.us/static/bugs/wooyun-2012-04166.html
http://www.anquan.us/static/bugs/wooyun-2012-04022.html
http://www.anquan.us/static/bugs/wooyun-2011-01188.html
http://www.anquan.us/static/bugs/wooyun-2011-03485.html

0x04 验证码可爆破

案例1 （完全无限制）

当验证码太弱（4-6位数字），且服务器没有错误次数限制时，则会存在可爆破的问题

WooYun中有7个类似案例

http://www.anquan.us/static/bugs/wooyun-2015-0155994.html
http://www.anquan.us/static/bugs/wooyun-2013-017242.html
http://www.anquan.us/static/bugs/wooyun-2013-016896.html
http://www.anquan.us/static/bugs/wooyun-2012-016179.html
http://www.anquan.us/static/bugs/wooyun-2013-031605.html
http://www.anquan.us/static/bugs/wooyun-2013-040908.html
http://www.anquan.us/static/bugs/wooyun-2012-012377.html

案例2 （限制覆盖不全）

以重置密码业务为例：用户输入手机验证码 -> 用户提交新密码

为了解决业务流程绑定的问题，通常两个步骤的参数中都会带有验证码。

开发人员往往只注意到第一个接口，而忽视了第二个接口。此时，在第一个页面中使用自己的手机号通过验证，第二个页面中修改为他人手机号并爆破

WooYun中有1个类似案例：

http://www.anquan.us/static/bugs/wooyun-2015-0133289.html

0x05 验证码在客户端生成

这种情况下，客户端生成一个验证码发送给服务端，服务端将这个验证码拼接，然后请求短信API发送短信

天才才能想出来的办法

WooYun中有2个类似案例

http://www.anquan.us/static/bugs/wooyun-2014-086716.html
http://www.anquan.us/static/bugs/wooyun-2013-022378.html

4 参考

几乎所有漏洞案例都来自乌云、个别案例来自先知 :)

pdf版本链接https://xzfile.aliyuncs.com/upload/affix/20190815235348-def019d4-bf74-1.pdf