一个“登录框“引发的安全问题
前言
搞安全的小伙伴只有一個登錄框你都能測試哪些漏洞？
通常大家測試的都會測試關鍵部分，為了有更好的測試效果，小廠會提供給你用戶名密碼；但是一些比較重要的企業(yè)，而這個環(huán)境卻是正式環(huán)境，里面存放著一些數(shù)據(jù)不希望被你看到的時候，是不會提供給你登錄賬號的。這個時候，考研你基礎知識是否扎實的時刻來臨了。
用戶名枚舉
漏洞描述：
存在于系統(tǒng)登錄頁面，利用登錄時輸入系統(tǒng)存在的用戶名錯誤密碼和不存在的用戶名錯誤密碼，返回不同的出錯信息可枚舉出系統(tǒng)中存在的賬號信息。
測試方法:
找到網(wǎng)站或者web系統(tǒng)登錄頁面。在web系統(tǒng)登錄頁面，通過手工方式，利用系統(tǒng)中存在的用戶名和不存在的用戶名，密碼隨意，嘗試登陸，查看其回顯內(nèi)容。例如:輸入存在的用戶名admin,回顯如下: 密碼錯誤; 輸入不存在的用戶名test, 回顯如下: 用戶不存在。
示例:
風險分析:
攻擊者根據(jù)Web應用程序返回的上述提示信息即可枚舉系統(tǒng)中存在的登錄用戶名，然后針對枚舉出來的登錄用戶名，對其密碼進行暴力破解。
修復方案:
建議對網(wǎng)站登錄頁面的判斷回顯信息修改為一致: 用戶名或密碼錯誤。
弱口令
漏洞描述：
認證登錄環(huán)節(jié)存在弱口令
測試方法：
1.找到網(wǎng)站登錄頁面，嘗試輸入常見弱口令；
2.根據(jù)網(wǎng)站所使用的第三方組件，尋找特定的弱口令或默認口令進行登錄。
示例：
通常很多廠商后臺默認賬戶為“admin”，密碼為”admin”或“123456”，大家可以通過暴力破解去嘗試
風險分析：
攻擊者可利用互聯(lián)網(wǎng)公開的常見弱口令嘗試登錄管理后臺，對網(wǎng)站造成一定的影響。
修復方案：
禁止使用弱口令，口令應滿足一定的復雜度。
空口令
漏洞描述：
認證登錄環(huán)節(jié)允許空口令
測試方法：
找到網(wǎng)站登錄頁面，嘗試輸入用用戶名，密碼為空進行登錄。
示例：暫無
風險分析：
攻擊者可利用該漏洞登錄網(wǎng)站后臺，操作敏感數(shù)據(jù)，甚至上傳webshell，從而控制服務器。
修復方案：
判斷輸入密碼是否為空，禁止空口令登錄。
登錄認證繞過
漏洞描述：
能夠繞過應用認證，直接登錄系統(tǒng)。
測試方法：
繞過認證主要有幾下幾種途徑：
1.網(wǎng)絡嗅探。通過網(wǎng)絡嗅探工具探測局域網(wǎng)中傳輸?shù)拿魑挠脩裘兔艽a。有些應用程序采用GET方式發(fā)送登錄請求，可能導致GET的URL請求內(nèi)容被緩存在代理服務器活著Web服務器端，導致用戶名和密碼泄漏。
2.默認或可猜測的用戶賬號。大多數(shù)開源軟件或商業(yè)軟件提供的基于網(wǎng)絡配置和管理的接口，通常都會有一些默認的用戶名和密碼。例如，一般默認的用戶名是：admin，administrator、root、system、guest等，而默認的秘密嗎也根據(jù)硬件和軟件的不同而不同，可嘗試一下這些密碼：password、admin、guest、12345等。
3.直接訪問內(nèi)部URL。使用Spider工具找到含有admin、manager、administrator、login等詞語的路徑，嘗試使用普通的登錄用戶訪問這些URL。從而獲得管理員的權限。
4.修改參數(shù)繞過認證。應用程序可能會會使用一個參數(shù)或一個隱藏的域表示一個用戶是否經(jīng)過驗證了，通過修改這些參數(shù)，從而被認為是已經(jīng)認證過的用戶。例如：http://www.xxx.xom/userinfo.jsp?authenticated=no，通過修改authenticated參數(shù)為yes，http://www.xxx.xom/userinfo.jsp?authenticated=yes，然后就可以通過認證，直接訪問內(nèi)部頁面。
5.可猜測的SessionID。利用規(guī)律，猜測到一個有效的SessionID，然后通過修改請求中的SessionID為一個預測到的有效的SessionID，從而冒充會話的真正擁有著，繞過認證環(huán)節(jié)。
6.注入問題。利用萬能密碼登錄系統(tǒng)，繞過認證環(huán)節(jié)。
7.CSRF。利用CSRF漏洞在用戶不知情的情況下，利用用戶的會話進行敏感操作，從而繞過認證。
示例：
Apache shiro cve-2020-17523 Apache shiro較新的登錄認證繞過，大概的方式就是使用空字符繞過
www.xxx.com/admin/%20/
www.xxx.com/admin/%2e/
示例用戶名密碼可以亂寫
點擊登陸按鈕同時使用抓包工具進行數(shù)據(jù)包攔截
將數(shù)據(jù)包返回至當前頁面，修改code值
登錄成功
風險分析：
如果應用程序在認證上沒有做好，可以導致惡意用戶或者攻擊者繞過認證，訪問內(nèi)部資源，這類漏洞通過防火墻和入侵檢測系統(tǒng)很難預防。
修復方案：
可從以下幾個方面預防認證繞過：
1.對于每一個訪問的URL都首先檢查是否已經(jīng)登錄（不需要認證的URL除外，例如，幫助頁面、免費下載頁面等），如果沒有登錄，則跳轉到登錄頁面。對于已經(jīng)登錄的用戶，在退出的時候或者在會話很長時間處于idle狀態(tài)的時候，需要保證原來的會話被正確的銷毀并且不會再被重利用。
2.規(guī)定密碼強度要求，防止密碼被猜測到。
3.對于用戶是否已經(jīng)認證，禁止依賴客戶端傳過來的參數(shù)標識，而應將是否登錄的標識保存在服務器端的會話中，當接收到該會話的請求時，從會話保存的狀態(tài)判斷是否登錄。
4.對于SessionID一定要使用安全的隨機數(shù)生成算法，使得SessionID不可預測。
5.對于暴力破解攻擊，建議在嘗試3次左右失敗之后，使用圖形驗證碼。
存在暴力破解
漏洞描述：
暴力破解的基本思想是根據(jù)題目的部分條件確定答案的大致范圍，并在此范圍內(nèi)對所有可能的情況逐一驗證，直到全部情況驗證完畢。若某個情況驗證符合題目的全部條件，則為本問題的一個解；若全部情況驗證后都不符合題目的全部條件，則本題無解。常常存在于網(wǎng)站的登錄系統(tǒng)中，通過對已知的管理員用戶名，進行對其登錄口令的大量嘗試。
測試方法：
找到網(wǎng)站登錄頁面。
利用burp對登錄頁面進行抓包，將其發(fā)送到Intruder,并設置其密碼參數(shù)，如pwd=為變量，添加payload（字典），進行攻擊，攻擊過程中查看其返回的字節(jié)長度，來判斷是否成功。
一般情況下，暴力破解有三種形式：
固定賬號對密碼暴力破解。
在得知賬號具有規(guī)律性，或者通過某種方式獲取到大量賬號的前提下，固定密碼對賬號暴力破解。
使用網(wǎng)上流傳的賬號密碼庫進行撞庫攻擊。
示例：
風險分析：
攻擊者一般會使用自動化腳本組合出常見的用戶名和密碼，即字典，再結合軟件burpsuite的intruder功能進行暴力破解。
修復方案：
防止暴力攻擊的一些方法如下：
1、賬戶鎖定
賬戶鎖定是很有效的方法，因為暴力破解程序在5-6次的探測中猜出密碼的可能性很小。但是同時也拒絕了正常用戶的使用。如果攻擊者的探測是建立在用戶名探測成功之后的行為，那么會造成嚴重的拒絕服務攻擊。對于對大量用戶名只用一個密碼的探測攻擊賬戶鎖定無效。如果對已經(jīng)鎖定的賬戶并不返回任何信息，可能迷惑攻擊者。
2、返回信息
如果不管結果如何都返回成功的信息，破解軟件就會停止攻擊。但是對人來說很快就會被識破。
3、頁面跳轉
產(chǎn)生登錄錯的的時候就跳到另一個頁面要求重新登錄。比如126和校內(nèi)網(wǎng)都是這樣做的。局限性在于不能總是跳轉頁面，一般只在第一次錯誤的時候跳轉，但是第一次之后又可以繼續(xù)暴力探測了。
4、適當?shù)难訒r
檢查密碼的時候適當?shù)牟迦胍恍和?#xff0c;可以減緩攻擊，但是可能對用戶造成一定的影響。
5、封鎖多次登錄的IP地址
這種方法也是有缺點的，因為攻擊者可以定時更換自己的IP。
6、驗證碼
驗證碼是阻止暴力攻擊的好方法，但設計不好的驗證碼是可以繞過的，而且對于特定目標的手工探測來說驗證碼是沒有作用的。
圖形驗證碼不失效
漏洞描述：
有些網(wǎng)站登錄框存在圖形驗證碼，防止暴力破解攻擊，但是正常的邏輯是前端輸入驗證碼之后進行校驗圖形驗證碼的正確性，而后若是為真則進行登錄操作，為假則返回驗證碼輸入錯誤，而使用一次的驗證碼應該立即失效。然而有些網(wǎng)站驗證碼可能是可控的，輸入一些特殊字符可能就能打到欺騙服務器或驗證碼使用一次之后并沒有及時刷新（所謂的驗證碼可以被自動識別這個問題，我個人覺得沒啥卵用，就不寫了）
測試方法：
輸入用戶名、密碼、驗證碼后，點擊登陸按鈕同時將數(shù)據(jù)包使用burpsuite進行攔截，并使用Repeater模塊或Intruder模塊進行數(shù)據(jù)重放，重新發(fā)送五次觀察頁面變化，是否會提示驗證碼輸入錯誤等信息
示例：
此登錄功能時存在圖形驗證碼的，在輸入了正確的圖形驗證碼之后進行數(shù)據(jù)重放，發(fā)現(xiàn)圖形驗證碼沒有做到及時失效
風險分析：
圖形驗證碼一般是防止使用程序惡意注冊、暴力破解用戶名密碼或者批量發(fā)帖而設置的。在頁面初始化時服務器向頁面發(fā)送一個隨機字符串，同時在Session里也保存一份，當用戶提交時將隨機數(shù)一起post到后臺，通過與Session中保存的值對比，如果不相同，則有可能是惡意攻擊。
修復方案：
1、系統(tǒng)在開發(fā)時注意驗證識別后銷毀session中的驗證碼。
2、限制用戶提交的驗證碼不能為空
3、判斷提交的驗證碼與服務器上存儲的是否一致
4、禁止將驗證碼明文信息發(fā)送至客戶端
短信驗證碼繞過
漏洞描述：
一些網(wǎng)站使用手機短信登錄，短信驗證碼可被繞過，執(zhí)行其他操作。
測試方法：
1.請求發(fā)送短信，填寫任意驗證碼，然后提交其他操作請求，將驗證碼參數(shù)置空或刪除，測試是否可繞過檢測；
2.嘗試特權驗證碼，如000000、111111等；
3.同一個短信驗證碼是否能使用多次；
示例：
正確的邏輯應當是，短信驗證碼獲取后，服務器校驗短信驗證碼的來源以及有效性，使用一次后應該立即失效。但是我遇到的這個就是使用驗證碼登錄后，注銷用戶登錄后再一次使用驗證碼發(fā)現(xiàn)依然登陸成功，也就是短信驗證碼沒有被刪除
風險分析：
修改／重置密碼、交易操作等功能通常需要短信驗證碼，若驗證碼可繞過，攻擊者可利用該漏洞進行重置他人密碼或轉賬等危險操作。
修復方案：
1.若存在特權驗證碼，建議將其刪除；
2.應用服務端應嚴格校驗驗證碼參數(shù)是否為空，格式是否正確；
3.關鍵操作每提交一次請求，應發(fā)送新的短信驗證碼，并且不可繼續(xù)使用舊的驗證碼。
短信驗證碼可暴力破解
漏洞描述：
短信驗證碼位數(shù)太短或有效期太長導致可暴力破解
測試方法：
點擊發(fā)送短信驗證碼，輸入任意驗證碼，提交請求，使用burpsuite攔截請求，在intruder模塊設置驗證碼參數(shù)為枚舉變量，這是payload類型為numbers，對驗證碼進行暴力破解。
示例：
這里的短信驗證碼可被暴力破解，是因為并沒有設置短信驗證碼使用錯誤幾次后失效，故可被暴力破解
風險分析：
修改／重置密碼、交易操作等功能通常需要短信驗證碼，若驗證碼可暴力破解，攻擊者可利用該漏洞進行重置他人密碼或轉賬等危險操作。
修復方案：
1.短信驗證碼不少于6位；
2.有效期不超過1分鐘；
3.驗證碼錯誤次數(shù)超過上限應采取賬戶鎖定策略。
短信攻擊
漏洞描述：
短信攻擊時常見的一種攻擊，攻擊者通過網(wǎng)站頁面中所提供的發(fā)送短信驗證碼的功能處，通過對其發(fā)送數(shù)據(jù)包的獲取后，進行重放，如果服務器短信平臺未做校驗的情況時，系統(tǒng)會一直去發(fā)送短信，這樣就造成了短信轟炸的漏洞。
測試方法：
1、手工找到有關網(wǎng)站注冊頁面，認證頁面，是否具有短信發(fā)送頁面，如果有，則進行下一步。
2、通過利用burp或者其它抓包截斷工具，抓取發(fā)送驗證碼的數(shù)據(jù)包，并且進行重放攻擊，查看手機是否在短時間內(nèi)連續(xù)收到10條以上短信，如果收到大量短信，則說明存在該漏洞。
示例：
點擊獲取驗證碼同時攔截數(shù)據(jù)包
使用burpsuite進行數(shù)據(jù)重放
風險分析：
攻擊者通過填寫他人的手機號，使用軟件burpsuite的intruder功能重復提交發(fā)送短信的請求包，達到短時間內(nèi)向他人的手機上發(fā)送大量垃圾短信的目的。
修復方案：
1、合理配置后臺短信服務器的功能，對于同一手機號碼，發(fā)送次數(shù)不超過3-5次，并且可對發(fā)送的時間間隔做限制。
2、頁面前臺代碼編寫時，加入禁止針對同一手機號進行的次數(shù)大于N次的發(fā)送，或者在頁面中加入驗證碼功能，并且限制發(fā)送的時間間隔。
惡意鎖定問題
漏洞描述：
通過不斷的輸入錯誤的密碼可惡意鎖定任意賬號
測試方法：
針對測試賬戶，不斷輸入錯誤的密碼，直至將其鎖定
示例：
風險分析：
若系統(tǒng)認證功能無防自動化處理模塊，攻擊者可編寫腳本批量鎖定系統(tǒng)賬號。
修復方案：
1.賬戶鎖定之后應不能繼續(xù)使用認證功能
2.認證功能防自動化操作，如添加圖形驗證碼。
密碼明文傳輸
漏洞描述：
認證過程中傳輸未加密（用戶名密碼等敏感數(shù)據(jù)明文傳輸）。
測試方法：
通過對網(wǎng)站登錄頁面的請求進行抓包，工具可用burp、wireshark、filder、等等，分析其數(shù)據(jù)包中相關password（密碼）參數(shù)的值是否為明文。如圖利用wireshark抓包分析的密碼：
示例：
1.輸入用戶名密碼
2. 使用burpsuite進行數(shù)據(jù)包攔截
風險分析：
攻擊者通過在局域網(wǎng)中嗅探網(wǎng)絡流量，獲取明文傳輸?shù)恼J證憑證，如用戶名密碼、SESSIONID等敏感信息。
修復方案：
建議按照網(wǎng)站的密級要求，需要對密碼傳輸過程中進行加密得使用加密的方式傳輸，如使用HTTPS， 但加密的方式增加成本，或許會影響用戶體驗。如果不用 HTTPS，可以在網(wǎng)站前端用 Javascript 做密碼加密，加密后再進行傳輸。
反射型跨站腳本攻擊
漏洞描述：
跨站腳本攻擊的英文全稱是Cross Site Script，為了和樣式表區(qū)分，縮寫為XSS。發(fā)生的原因是網(wǎng)站將用戶輸入的內(nèi)容輸出到頁面上，在這個過程中可能有惡意代碼被瀏覽器執(zhí)行。跨站腳本攻擊,它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web里面的html代碼會被執(zhí)行，從而達到惡意用戶的特殊目的。已知的跨站腳本攻擊漏洞有三種：1）存儲式；2）反射式；3）基于DOM。
測試方法：
1、GET方式跨站腳本：
在輸入的參數(shù)后逐條添加以下語句，以第一條為例，輸入http://www.exmaple.com/page.xxx?name=
文本輸入框：需要對頁面上所有可以提交參數(shù)的地方進行測試。具體跨站腳本的測試語句根據(jù)實際情況的不同而不同，可自行構造，以及觸發(fā)事件等切換，這里只列出了一些最常見構造語句。
示例：登錄窗口用戶名處存在反射型XSS注入
點擊登陸，成功彈出內(nèi)容
風險分析：
攻擊者可以使用該漏洞構造釣魚鏈接，誘騙受害者訪問并填寫用戶名和密碼，從而竊取用戶的認證憑據(jù)
修復方案：
1、總體修復方式：驗證所有輸入數(shù)據(jù)，有效檢測攻擊；對所有輸出數(shù)據(jù)進行適當?shù)木幋a，以防止任何已成功注入的腳本在瀏覽器端運行。具體如下 ：
2、輸入驗證：某個數(shù)據(jù)被接受為可被顯示或存儲之前，使用標準輸入驗證機制，驗證所有輸入數(shù)據(jù)的長度、類型、語法以及業(yè)務規(guī)則。
3、輸出編碼：數(shù)據(jù)輸出前，確保用戶提交的數(shù)據(jù)已被正確進行entity編碼，建議對所有字符進行編碼而不僅局限于某個子集。
4、明確指定輸出的編碼方式：不要允許攻擊者為你的用戶選擇編碼方式(如ISO 8859-1或 UTF 8)。
5、注意黑名單驗證方式的局限性：僅僅查找或替換一些字符(如”<” “>“或類似”script”的關鍵字)，很容易被XSS變種攻擊繞過驗證機制。
警惕規(guī)范化錯誤：驗證輸入之前，必須進行解碼及規(guī)范化以符合應用程序當前的內(nèi)部表示方法。請確定應用程序對同一輸入不做兩次解碼。對客戶端提交的數(shù)據(jù)進行過濾，一般建議過濾掉雙引號（”）、尖括號（<、>）等特殊字符，或者對客戶端提交的數(shù)據(jù)中包含的特殊字符進行實體轉換，比如將雙引號（”）轉換成其實體形式”，<對應的實體形式是<，<對應的實體形式是>以下為需過濾的常見字符
萬能密碼
漏洞描述：
其實我覺得萬能密碼和sql注入應當區(qū)分開來，所以我就分開寫了。
眾所周知，登錄處是一條查詢操作，一些程序可能是沒有注意到，就寫成了
- ?
- ?
- ?
- ?
- ?
- ?
- ?
- ?
這個時候就可以構造特殊的sql語句進行截斷，造成永真，這樣的話就可以越過查詢完成登錄
測試方法：
(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(chǎn)’=‘a(chǎn) 密碼輸入：任意
(5) 用戶名輸入：‘ or 1=1 - -
(6) 用戶名輸入：admin‘ or 1=1 - - 密碼輸入：任意
(7) 用戶名輸入：1’or’1’=‘1’or’1’=’1 密碼輸入：任意
示例：
這里的案例與上述的不太相同，他的查詢多了一個判斷動作，就是先判斷用戶名是否存在，存在的 時候才會進行下一步判斷，判斷用戶名密碼是否匹配，所以這里必須輸入正確的用戶名才行
admin’ or 1 #
點擊登陸，成功登錄
風險分析：
攻擊者可通過萬能密碼直接登錄后臺，獲取后臺權限
修復方案：
1)對用戶輸入的特殊字符進行嚴格過濾，如’、”、<、>、/、*、;、+、-、&、|、(、)、and、or、select、union。
2)使用參數(shù)化查詢（PreparedStatement），避免將未經(jīng)過濾的輸入直接拼接到SQL查詢語句中。
3)Web應用中用于連接數(shù)據(jù)庫的用戶與數(shù)據(jù)庫的系統(tǒng)管理員用戶的權限有嚴格的區(qū)分（如不能執(zhí)行drop等），并設置Web應用中用于連接數(shù)據(jù)庫的用戶不允許操作其他數(shù)據(jù)庫。
4)設置Web應用中用于連接數(shù)據(jù)庫的用戶對Web目錄不允許有寫權限。
5)使用Web應用防火墻。
sql注入
漏洞描述：
所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執(zhí)行惡意的SQL命令。具體來說，它是利用現(xiàn)有應用程序，將（惡意）SQL命令注入到后臺數(shù)據(jù)庫引擎執(zhí)行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個存在安全漏洞的網(wǎng)站上的數(shù)據(jù)庫，而不是按照設計者意圖去執(zhí)行SQL語句。造成SQL注入漏洞原因有兩個：一個是沒有對輸入的數(shù)據(jù)進行過濾（過濾輸入），還有一個是沒有對發(fā)送到數(shù)據(jù)庫的數(shù)據(jù)進行轉義（轉義輸出）。
測試方法：
1.通過web漏洞掃描工具進行對網(wǎng)站爬蟲后得到的所有鏈接進行檢測，或者手工判斷是否存在注入點，一旦確認存在漏洞，可利用自動化工具sqlmap去嘗試注入。幾種常見的判斷方法：
1)數(shù)字型。
http://host/test.php?id=100?and 1=1 返回成功
http://host/test.php?id=100?and 1=2 返回失敗
2)字符型。
http://host/test.php?name=rainman?’ and ‘1’=‘1 返回成功
http://host/test.php?name=rainman?’ and ‘1’=‘2 返回失敗
3)搜索型。
搜索型注入：簡單的判斷搜索型注入漏洞是否存在的辦法是：
先搜索（’），如果出錯，說明90%存在這個漏洞。
然后搜索（%），如果正常返回，說明95%有洞了。
然后再搜索一個關鍵字，比如（2006）吧，正常返回所有2006相關的信息。
再搜索（2006%‘a(chǎn)nd 1=1 and ‘%’=’）和（2006%‘a(chǎn)nd 1=2 and ‘%’=’）
不同的SQL服務器連結字符串的語法不同，比如MS SQL Server使用符號+來連結字符串，而Oracle使用符號||來連結：
http://host/test.jsp?ProdName=Book’ 返回錯誤
http://host/test.jsp?ProdName=B’+’ook 返回正常
http://host/test.jsp?ProdName=B’||’ook 返回正常說明有SQL注入
2.如果應用程序已經(jīng)過濾了’和+等特殊字符，我們?nèi)匀豢梢栽谳斎霑r過把字符轉換成URL編碼（即字符ASCII碼的16進制）來繞過檢查。
示例：暫無
此處常常伴隨著萬能密碼漏洞，故不做展示
風險分析：在輸入URL和表單處，攻擊者通過輸入精心構造的SQL語句，對數(shù)據(jù)庫記錄進行增刪改查，或直接獲取服務器權限。攻擊者實施SQL注入攻擊時大多借助自動化注入工具，如穿山甲、明小子、sqlmap、Havij等。
修復方案：
SQL注入的主要原因是程序沒有嚴格過濾用戶輸入的數(shù)據(jù)，導致非法數(shù)據(jù)侵入系統(tǒng)。
1)對用戶輸入的特殊字符進行嚴格過濾，如’、”、<、>、/、*、;、+、-、&、|、(、)、and、or、select、union。
2)使用參數(shù)化查詢（PreparedStatement），避免將未經(jīng)過濾的輸入直接拼接到SQL查詢語句中。
3)Web應用中用于連接數(shù)據(jù)庫的用戶與數(shù)據(jù)庫的系統(tǒng)管理員用戶的權限有嚴格的區(qū)分（如不能執(zhí)行drop等），并設置Web應用中用于連接數(shù)據(jù)庫的用戶不允許操作其他數(shù)據(jù)庫。
4)設置Web應用中用于連接數(shù)據(jù)庫的用戶對Web目錄不允許有寫權限。
5)使用Web應用防火墻。
任意用戶密碼修改/重置
漏洞描述：
可通過篡改用戶名或ID、暴力破解驗證碼等方式修改/重置任意賬戶的密碼。
測試方法：
密碼修改的步驟一般是先校驗用戶原始密碼是否正確，再讓用戶輸入新密碼。修改密碼機制繞過方式大概有以下三種：
1.如果輸入新密碼的接口可以直接訪問，那么在未知原始密碼的的情況下即可直接修改密碼，通常知道了他人的用戶名即可任意修改他人的密碼。
2.如果系統(tǒng)未校驗修改密碼的用戶身份，那么在提交修改密碼請求時，攻擊者通過輸入密碼，將用戶名或者用戶ID修改為其他人的，即可成功修改他人的密碼。
3.當修改密碼時系統(tǒng)需要電子郵件或者手機短信確認，而應用程序未校驗用戶輸入的郵箱和手機號，那么攻擊者通過填寫自己的郵箱或手機號接收修改密碼的鏈接和驗證碼，以此修改他人的密碼。
密碼重置機制繞過攻擊方式主要有以下兩種：
1.通過正常手段獲取重置密碼的鏈接，猜解鏈接的組成結構和內(nèi)容（如用戶名或者時間戳的MD5值）。在得知他人郵箱的情況下，構造重置他人密碼的鏈接。
2.在得知他人手機號的情況下，通過窮舉手機驗證碼重置他人的密碼。
示例：
我遇到的密碼重置漏洞，是忘記密碼的時候會自動發(fā)送一條手機短信至綁定用戶的手機中，而我做的則是在他發(fā)送之前攔截，而后修改手機號碼，成功的接受到了手機短信，而后重置用戶密碼。
還有一種是手機短信驗證成功后，重新設置密碼時攔截數(shù)據(jù)包，通過修改類似username、userid等方式修改他人的賬戶密碼。
風險分析：
密碼修改功能常采用分步驟方式來實現(xiàn)，攻擊者在未知原始密碼的情況下繞過某些檢驗步驟修改用戶密碼。
重置密碼過程一般是首先驗證注冊的郵箱或者手機號，獲取重置密碼的鏈接（一般會包含一串唯一的字符串）或者驗證碼，然后訪問重置密碼鏈接或者輸入驗證碼，最后輸入新密碼。密碼重置機制繞過攻擊是指在未知他人的重置密碼鏈接或手機驗證碼的情況下，通過構造重置密碼鏈接或窮舉手機驗證碼的方式直接重置他人的密碼。
修復方案：
1.一次性填寫校驗信息（原始密碼、新密碼等）后再提交修改密碼請求。
2.對客戶端提交的修改密碼請求，應對請求的用戶身份與當前登錄的用戶身份進行校驗，判斷是否有權修改用戶的密碼并對原始密碼是否正確也進行判斷。
3.不應將用于接收驗證信息的手機、郵箱等信息全部明文傳到客戶端，應對手機、郵箱等信息進行屏蔽處理，或不將此類信息返回到客戶端。
4.對原始密碼進行了驗證的情況下，限制輸入原始密碼的錯誤次數(shù)，防止攻擊者暴力破解原始密碼。
5.重置密碼鏈接中的關鍵信息應隨機化，不可預測（例如token機制），且禁止將關鍵信息返回到客戶端。
目錄遍歷
漏洞描述：
目錄瀏覽漏洞是由于網(wǎng)站存在配置缺陷，存在目錄可瀏覽漏洞，這會導致網(wǎng)站很多隱私文件與目錄泄露，比如數(shù)據(jù)庫備份文件、配置文件等，攻擊者利用該信息可以更容易得到網(wǎng)站權限，導致網(wǎng)站被黑。
測試方法：
可以利用web漏洞掃描器掃描web應用進行檢測，也可通過搜索，網(wǎng)站標題包含“index of”關鍵詞的網(wǎng)站進行訪問。
示例：
一般目錄遍歷都是輸入…/…/這種，或者通過御劍進行目錄掃描，有的時候會有一些路徑可以遍歷里面的目錄內(nèi)容
風險分析：
攻擊者通過訪問網(wǎng)站某一目錄時，該目錄沒有默認首頁文件或沒有正確設置默認首頁文件，將會把整個目錄結構列出來，將網(wǎng)站結構完全暴露給攻擊者；攻擊者可能通過瀏覽目錄結構，訪問到某些隱秘文件（如PHPINFO文件、服務器探針文件、網(wǎng)站管理員后臺訪問地址、數(shù)據(jù)庫連接文件等）。
修復方案：
目前存在該漏洞的常見中間件為apache和IIS,以下列出其相關的修復方式：
1、 IIS中關閉目錄瀏覽功能：在IIS的網(wǎng)站屬性中，勾去“目錄瀏覽”選項，重啟IIS。
2、 Apache中關閉目錄瀏覽功能：打開Apache配置文件httpd.conf，查找“Options Indexes FollowSymLinks”，修改為“ Options -Indexes”(減號表示取消，保存退出，重啟Apache。
3、 Nginx中默認不會開啟目錄瀏覽功能，若您發(fā)現(xiàn)當前已開啟該功能，可以編輯nginx.conf文件，刪除如下兩行：autoindex on;autoindex_exact_size on;重啟Nginx。
敏感文件信息泄漏
漏洞描述：
敏感數(shù)據(jù)包括但不限于：口令、密鑰、證書、會話標識、License、隱私數(shù)據(jù)（如短消息的內(nèi)容）、授權憑據(jù)、個人數(shù)據(jù)（如姓名、住址、電話等）等，在程序文件、配置文件、日志文件、備份文件及數(shù)據(jù)庫中都有可能包含敏感數(shù)據(jù)。（這里的信息泄露，我包含了常見的已經(jīng)類似于robots文件等等，包括入侵痕跡殘留、打包備份文件遺留等等）
測試方法：
1、檢測形式多樣，工具爬蟲掃描得到敏感文件的路徑，從而找到敏感數(shù)據(jù)，
2、手工挖掘，根據(jù)web容器或者網(wǎng)頁源代碼的查看，找到敏感信息。
示例：
這里我給大家?guī)砹俗罱容^火的銳捷信息泄露，在源代碼中泄露了用戶名密碼信息
泄露了用戶名以及MD5加密的密碼
當然了還有一些奇葩的，會直接彈出來測試用戶名密碼、甚至是用戶名密碼自動填充等等我覺得只有這些才配成為信息泄露，剩下的泄露個什么加密方式、中間件版本信息啥的太邊緣了，懶得測
風險分析：攻擊者可通過上述方式獲取網(wǎng)站敏感文件，收集網(wǎng)站敏感信息，從而有針對性的進行利用。
修復方案：
1、禁止在代碼中存儲敏感數(shù)據(jù)：禁止在代碼中存儲如數(shù)據(jù)庫連接字符串、口令和密鑰之類的敏感數(shù)據(jù)，這樣容易導致泄密。用于加密密鑰的密鑰可以硬編碼在代碼中。
2、禁止密鑰或帳號的口令以明文形式存儲在數(shù)據(jù)庫或者文件中：密鑰或帳號的口令必須經(jīng)過加密存儲。例外情況，如果Web容器的配置文件中只能以明文方式配置連接數(shù)據(jù)庫的用戶名和口令，那么就不用強制遵循該規(guī)則，將該配置文件的屬性改為只有屬主可讀寫。
3、禁止在 cookie 中以明文形式存儲敏感數(shù)據(jù)：cookie信息容易被竊取，盡量不要在cookie中存儲敏感數(shù)據(jù)；如果條件限制必須使用cookie存儲敏感信息時，必須先對敏感信息加密再存儲到cookie。
4、禁止在隱藏域中存放明文形式的敏感數(shù)據(jù)。
5、禁止用自己開發(fā)的加密算法，必須使用公開、安全的標準加密算法。
6、禁止在日志中記錄明文的敏感數(shù)據(jù)：禁止在日志中記錄明文的敏感數(shù)據(jù)（如口令、會話標識jsessionid等）， 防止敏感信息泄漏。
7、禁止帶有敏感數(shù)據(jù)的Web頁面緩存：帶有敏感數(shù)據(jù)的Web頁面都應該禁止緩存，以防止敏感信息泄漏或通過代理服務器上網(wǎng)的用戶數(shù)據(jù)互竄問題。
框架漏洞
漏洞描述：
開發(fā)框架存在的漏洞，如Struts2框架漏洞、shiro等（weblogic反序列化中間件的就不寫了）
測試方法：
以Struts2遠程命令執(zhí)行為例：
1.在了解網(wǎng)站所采用的結構框架后，除去偽靜態(tài)頁面，抓包或者讀取頁面源代碼方式，查找到網(wǎng)站系統(tǒng)url為.do和.action結尾類型后，添加相應的遠程命令執(zhí)行代碼進行判斷。
例如用戶可以在http://host.com/X.action?后添加相對應struts2 漏洞的遠程命令執(zhí)行代碼，或者直接利用工具K8 Struts2 Exploit.exe進行檢測
或使用shiro檢測工具進行檢測
示例：
使用burp插件進行被動檢測
風險分析：
Struts 2是在struts 和WebWork的技術基礎上進行了合并的全新的框架。Struts2漏洞類型分為兩種，一種是使用縮寫的導航參數(shù)前綴時的遠程代碼執(zhí)行漏洞，另一種是使用縮寫的重定向參數(shù)前綴時的開放式重定向漏洞。Struts2遠程命令執(zhí)行，屬于高危安全漏洞，可使黑客取得網(wǎng)站服務器的權限。這里我們重點描述相關遠程命令執(zhí)行漏洞。Struts2的DefaultActionMapper支持一種方法，可以使用”action:”, “redirect:”, “redirectAction:”對輸入信息進行處理，從而改變前綴參數(shù)，這樣操作的目的是方便表單中的操作。在2.3.15.1版本以前的struts2中，沒有對”action:”, “redirect:” , “redirectAction:”等進行處理，導致ongl表達式可以被執(zhí)行，如s2-020的漏洞中，利用ognl的class.xx這種方式來遍歷屬性
修復方案：
建議及時更新struts2的版本到最新
SSO認證缺陷
漏洞描述：
SSO認證存在缺陷，可越權登錄他人賬戶。
測試方法：
1.信息傳輸缺乏安全保證
SSO認證通信過程中大多數(shù)采用明文形式傳送敏感信息，這些信息很容易被竊取，致使重要信息泄露。另外，在通信過程中大多數(shù)方案也沒有對關鍵信息進行簽名，容易遭到偽裝攻擊。
2.Web服務的安全缺陷
由于單點登錄基本上是基于Web服務實現(xiàn)的，所以也不可避免的存在Web服務的安全缺陷，如跨站腳本攻擊、越權攻擊等。
示例：暫無
風險分析：
因為只需要登錄一次，所有的授權的應用系統(tǒng)都可以訪問，可能導致一些很重要的信息泄露。
修復方案：
建議從以下幾個方面進行防御：
1.建議在不影響業(yè)務的前提下，使用HTTPS協(xié)議傳輸
2.嚴格校驗SSO認證過程中的用戶身份
3.過濾用戶傳入的參數(shù)，對特殊符號進行轉義或屏蔽。
暫時就這些吧，一些不是很重要的或者測試方式相似的就不寫了
中間件漏洞如weblogic反序列化、jboss的和框架漏洞測試方式一樣，都是用工具掃出來的，我就不寫了，端口層次、主機漏洞層次的不計入到web漏洞中。
創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎總結
以上是生活随笔為你收集整理的一个“登录框“引发的安全问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 别致的上传思路导致getshell的案例
- 下一篇： CTF之一次曲折获取Flag的过程