ネットワーク セキュリティ | ペネトレーション テストのエントリ ケース分析、基本的なエントリから習得まで - ログイン ボックス ページへの迅速な侵入のための一般的な検出方法

目次

序章

1. 弱いパスワード

2. ユニバーサルパスワードのバイパス

編集

3. ログイン認証回避

3.1. トークンリフレッシュターミナルの設定ミス

3.2. 間違った SSO 設定

 3.3.CMSケースアクセスの問題

3.4. JWT トークンの解析エラー

3.5. 認証の暴力的な改ざん

4. グラフィック認証コードは無効ではありません

5.SMS認証コードは無効ではありません

6.SMS攻撃

7. 反射型クロスサイトスクリプティング攻撃

8. SQLインジェクション

9. ユーザーパスワードの変更/リセット

10. 機密情報の漏洩

11. ディレクトリトラバーサル

12. フレームワークの抜け穴


序章

今日は、Web サイトの背景のログインページで一般的に使用される侵入方法を共有したいと思います。これにより、誰もが日常的に Web サイトを維持するときにさまざまな利便性で防御に注意を払うことができます。

 

1. 弱いパスワード

テスト方法:
次のような、使用頻度の高い弱いパスワードを手動でテストできます。 2. Web サイトで使用されているサードパーティ コンポーネントに従って、特定の弱いパスワードまたはログイン用のデフォルト パスワードを探します。または、BP に直接アクセスしてください。Poly を使用して 6 桁の純粋なデジタル パスワードを解読するには、3S だけが必要です。

admin:123456
admin:admin
admin:admin@123
admin:12345
test:test

2022 年にセキュリティ部門の統計によって発表された脆弱なパスワードのランキング トップ 20 は次のとおりです。

2. ユニバーサルパスワードのバイパス

試験方法:

(1) 用户名输入: ‘ or 1=1 or ‘  密码:任意
(2)Admin’ - -(或‘ or 1=1 or ‘ - -)(admin or 1=1 --) (MS SQL)(直接输入用户名,不进行密码验证)
(3)用户名输入:admin   密码输入:’ or  ‘1’=’1 也可以
(4) 用户名输入:admin' or 'a'='a    密码输入:任意
(5) 用户名输入:‘ or 1=1 - -
(6) 用户名输入:admin‘ or 1=1 - -  密码输入:任意
(7) 用户名输入:1'or'1'='1'or'1'='1   密码输入:任意

 asp aspx ユニバーサル パスワード
  1: "または "a"="a
   2: ')or('a'='a
   3: または 1=1--
   4: 'または 1=1--
   5: a'or' 1 =1--
   6: "または 1=1--
   7: 'または'a'='a
   8: "または"="a'='a
   9: 'または'='
   10: 'または'=' or'
   11: 1 または '1'='1'=1
   12: 1 または '1'='1' または 1=1
   13: 'OR 1=1%00
   14: "または 1=1%00
   15: 'xor
   16: 新しいユニバーサル ログイン パスワード
   ユーザー名' UNION Select 1,1,1 FROM admin Where ''=' (テーブル名 admin を置き換えます)
   パスワード 1
   Username=-1%cf' Union select 1,1,1 をパスワードとして 1 、1、1 %23
   Password=1
   17..admin' または 'a'='a パスワードはオプションです


   PHP マスターパスワード
   'or'='or'
   'or 1=1/* 文字タイプ GPC はオンかオフかに関係なく使用できます
   ユーザー: 何か
   Pass: ' OR '1'='1

   jsp マスターパスワード
   1'or'1 '='1
   admin' OR 1=1/*
   ユーザー名: admin は、このユーザーがシステムに存在する場合にのみ使用できます
   パスワード: 1'or'1'='1

 

 

3. ログイン認証回避

試験方法:

1)直接访问内部URL。使用扫描工具找到含有admin、manager、administrator、login等词语的路径,尝试使用普通的登录用户访问这些URL。从而获得管理员的权限。
2)修改参数绕过认证。应用程序可能会会使用一个参数或一个隐藏的域表示一个用户是否经过验证了,通过修改这些参数,从而被认为是已经认证过的用户。例如:http://www.xxx.xom/userinfo.jsp?authenticated=no,通过修改authenticated参数为yes,http://www.xxx.xom/userinfo.jsp?authenticated=yes,然后就可以通过认证,直接访问内部页面。
3)可猜测的SessionID。利用规律,猜测到一个有效的SessionID,然后通过修改请求中的SessionID为一个预测到的有效的SessionID,从而冒充会话的真正拥有着,绕过认证环节。
4)CSRF。利用CSRF漏洞在用户不知情的情况下,利用用户的会话进行敏感操作,从而绕过认证。
5)前端验证绕过:修改返回码,一般可以尝试true、success、200、0、1等

3.1. トークンリフレッシュターミナルの設定ミス

この場合、ユーザーが有効な資格情報を使用してアプリケーションにログインすると、認証用の認証トークンが作成されます。そして、この認証トークンはしばらくすると期限切れになります。有効な認証トークンは、有効期限が切れる直前に endpoint/refresh/tokenlogin パラメータを含むリクエストをサーバーに送信する ことによって、戻りパケットに表示されます。username

3.2. 間違った SSO 設定

プラットフォームの多様性とユーザー ニーズの継続的な改善に伴い、ユーザーが 1 回限りのユーザー認証を通じて複数のアプリケーションや Web サイトにログインできるようにするために、ほとんどのプラットフォームで SSO システムが使用されています。ただし、SSO を使用するだけではシステムが自動的に保護されるわけではありません。SSO 構成も保護されている必要があります。

ここで、アプリケーションは Microsoft SSO システムを使用して認証します。internal.test.comURL を表示すると、ブラウザはシングル サインオン システムにリダイレクトされます。

 3.3.CMSケースアクセスの問題

WordPress、Drupal、Hubspot などの CMS も、このような脆弱性を回避するために安全に構成する必要があります。

これも偶然の出会いに基づいた Liferay の例です。アプリには、認証なしでアクセスできるログイン ページがあります。

Liferay は、数値 id にパラメータを持つポートレットをアプリケーションの sso として使用します p _ p _ idポートレットの場合、パラメータを値 58 に変更することでログイン ポートレットにアクセスできます。通常のログインページでは、ログインページのみにアクセスできます。ただし、ポートレットに直接アクセスすると、Create Account関数にアクセスでき、そのself-registration関数は承認を必要とせずにバックグラウンド コンテンツにアクセスできるようになります。

 

3.4. JWT トークンの解析エラー

JWT トークンまたは JSON Web トークンは Web で広く使用されています。ただし、鍵となるセキュリティ機構はデフォルトで備わっていますが、バックエンドサーバーの解決機構が十分に安全であるかどうかは不明です。

JWT を使用している Web サイトがあり、直接アクセスすると、アプリケーションによってユーザーが Microsoft SSO Web ページにリダイレクトされました。

ただし、一部の JS ファイルは認証なしでアクセスできます。テスト中に、アプリケーションが安全なログイン後にシステムを通じて送信される JWT トークンを使用していることが判明しましたMicrosoft SSOバックエンド メカニズムに、JWT トークンが特定のアプリケーション用に生成されたかどうかをチェックしないセキュリティ構成の誤りがあり、代わりに、有効な署名を持つすべての JWT トークンを受け入れていました。Microsoft の Web サイトからの JWT トークンを使用する例を次に示します。

 

3.5. 認証の暴力的な改ざん

この場合、base64 でエンコードされた XML リクエストが検証のためにバックエンドに送信されます。ログインメカニズムでは、ユーザー名とパスワードを別々に送信します。Scode パラメータの値は、パスワードの md5 値です。リクエストには別の興味深いフラグがあります。scode の値は 2 です。

 ユーザー名と空のパスワードを入力するだけで認証を回避できることが判明しました。

 

4. グラフィック認証コードは無効ではありません

試験方法:

输入用户名、密码、验证码后,点击登陆按钮同时将数据包使用burpsuite进行拦截,并使用Repeater模块或Intruder模块进行数据重放,重新发送五次观察页面变化,是否会提示验证码输入错误等信息

5.SMS認証コードは無効ではありません

試験方法:

1)请求发送短信,填写任意验证码,然后提交其他操作请求,将验证码参数置空或删除,测试是否可绕过检测;
2)尝试特权验证码,如000000、111111等;
3)同一个短信验证码是否能使用多次;

6.SMS攻撃

試験方法:

1)手工找到有关网站注册页面,认证页面,是否具有短信发送页面,如果有,则进行下一步。
2)通过利用burp或者其它抓包截断工具,抓取发送验证码的数据包,并且进行重放攻击,查看手机是否在短时间内连续收到10条以上短信,如果收到大量短信,则说明存在该漏洞。

 

 

7. 反射型クロスサイトスクリプティング攻撃

試験方法:

1、GET方式跨站脚本:
在输入的参数后逐条添加以下语句,以第一条为例,输入http://www.exmaple.com/page.xxx?name=
文本输入框:需要对页面上所有可以提交参数的地方进行测试。具体跨站脚本的测试语句根据实际情况的不同而不同,可自行构造。
2、POST方式
例如:抓包对输入的参数进行构造语句触发XSS

8. SQLインジェクション

試験方法:

1)通过web漏洞扫描工具进行对网站爬虫后得到的所有链接进行检测,或者手工判断是否存在注入点,一旦确认存在漏洞,可利用自动化工具sqlmap去尝试注入。几种常见的判断方法:
a、数字型。
http://host/test.php?id=100 and 1=1 返回成功
http://host/test.php?id=100 and 1=2 返回失败
b、字符型。
http://host/test.php?name=rainman ’ and ‘1’=‘1 返回成功
http://host/test.php?name=rainman ’ and ‘1’=‘2 返回失败
c、搜索型。
搜索型注入:简单的判断搜索型注入漏洞是否存在的办法是:
先搜索(’),如果出错,说明90%存在这个漏洞。
然后搜索(%),如果正常返回,说明95%有洞了。
然后再搜索一个关键字,比如(2006)吧,正常返回所有2006相关的信息。
再搜索(2006%‘and 1=1 and ‘%’=’)和(2006%‘and 1=2 and ‘%’=’)

または、ログイン ボックスにユーザー名を直接入力し、「データベース エラーが報告されるかどうかを確認する」と入力します。

9. ユーザーパスワードの変更/リセット

テスト方法:
パスワード変更の手順は通常、最初にユーザーの元のパスワードが正しいかどうかを確認し、次にユーザーに新しいパスワードの入力を求めます。パスワード変更メカニズムをバイパスするには、大まかに 3 つの方法があります。

1)如果输入新密码的接口可以直接访问,那么在未知原始密码的的情况下即可直接修改密码,通常知道了他人的用户名即可任意修改他人的密码。
2)如果系统未校验修改密码的用户身份,那么在提交修改密码请求时,攻击者通过输入密码,将用户名或者用户ID修改为其他人的,即可成功修改他人的密码。
3)当修改密码时系统需要电子邮件或者手机短信确认,而应用程序未校验用户输入的邮箱和手机号,那么攻击者通过填写自己的邮箱或手机号接收修改密码的链接和验证码,以此修改他人的密码。

10. 機密情報の漏洩

試験方法:

1)如果比较有耐心的话可以找一下页面源码、JS文件,全局搜索password,userlogin等一些敏感词等可能存在意想不到的收获
2)查找URL信息是为了找到账号密码验证成功后跳转的URL地址,然后尝试访问此地址,看是否出现未授权访问漏洞
此处已显示账号密码验证成功后的跳转地址,直接访问此地址看是否可以未授权访问。

11. ディレクトリトラバーサル

試験方法:

可以利用web漏洞扫描器扫描web应用进行检测,也可通过搜索,网站标题包含“index of”关键词的网站进行访问。

12. フレームワークの抜け穴

フレームワークの一般的な脆弱性は次のとおりです。ここでは 1 つずつ説明しません。

Spring框架漏洞
Struts2框架漏洞
ThinkPHP 框架漏洞
shiro框架漏洞

おすすめ

転載: blog.csdn.net/qq_22903531/article/details/131329832