文章首發于公眾號 「會玩code」
在黑客攻擊中，資訊收集是進行攻擊的第一步，也是至關重要的一步，資訊泄露發生的途徑有很多，攻擊者可以根據介面回傳資訊，分析前端代碼，分析頁面檔案資訊、甚至是開發人員或用戶在第三方網站上的資料托管，都能進行有效的資訊收集，作為開發人員，我們應該了解常見資訊泄露風險點并謹慎規避，
介面回傳詳細報錯資訊
- 一些框架，如django，允許設定debug=true，在呼叫介面失敗時，會將代碼堆疊資訊和一些環境資訊都列印在頁面上，方便除錯；
- 業務開發時，有些同學可能習慣將err（包含代碼呼叫堆疊資訊）直接回傳給用戶，攻擊者通過這些資訊可以窺探代碼邏輯，造成安全隱患，
以登錄為例子，用戶輸入賬號密碼后，后臺會去資料庫中根據賬號查詢對應密碼，用資料庫中的密碼與請求攜帶的密碼對比，sql大致邏輯是select passwd from t_user where user_name = 'xxx'xxx即為我們傳入的賬號名，
如果后臺是手動拼接構造的sql，就會存在sql注入漏洞，我們在用戶名位置輸入一個單引號(最后構造的sql: select passwd from t_user where user_name = '''),
sql執行報錯...MySQL server version for the right syntax to use near '''')'..., 這時介面把sql報錯資訊一路透傳回傳前端，攻擊者可根據回傳的報錯資訊推導得知系統存在sql注入漏洞，從而發起攻擊，
密碼明文存盤
這是個低級、但后果十分嚴重且普遍的安全問題，Google、FaceBook等大公司都曾被爆過明文存盤用戶密碼，由于明文存盤密碼導致用戶密碼泄露的事故也是屢見不鮮，
密碼應該使用哈希加密保存，這樣即使攻擊者獲取了密碼，也只是一串毫無意義的字符，當然，對于哈希密碼，攻擊者也能通過密碼字典的方式對哈希密碼進行“撞庫”破解，或構造彩虹表對密碼進行破解，
比如123456的哈希值是E10ADC3949BA59ABBE56E057F20F883E,可以在cmd5上很容易反查到哈希值的明文資訊，
所以為了加大密碼破譯難度，可以在哈希時加鹽處理，先密碼的特定位置插入特定的字串(salt)，再進行哈希，
加鹽后的密碼經過哈希加密得到的哈希串與加鹽前的哈希串完全不同，為了進一步增加隨機性，可以每個用戶哈希保存密碼時使用的"鹽值"都不相同，比如使用用戶名或用戶id等用戶不可變屬性當作哈希時的"鹽"，
網站檔案泄露
nginx可用于靜態資源服務器，為了下載資源方便，可能會開啟目錄瀏覽(autoindex = true)的功能，
一旦不小心在目錄下存放了敏感檔案資訊，就容易被用戶下載獲取，
為了避免隨意訪問資源，可以添加身份認證，在訪問前先進行賬號密碼認證，
更安全的做法是同時關掉目錄瀏覽功能，用戶只能通過完整資源路徑獲取指定資源，比如資源根目錄下有"xx.txt", 用戶只能通過"http://huiwan_code.com/xx.txt"獲取，而不能訪問"http://huiwan_code.com"打開目錄頁面，再在頁面上點擊下載"xx.txt"，
過于詳細的robots.txt
許多網站都提供檔案 /robots.txt 和 /sitemap.xml 幫助搜索引擎爬取其網站，搜索引擎可以通過robots檔案可以獲知哪些頁面可以爬取，哪些頁面不可以爬取，
上面是百度的robots.txt內容，可以直接通過網站域名(wwww.baidu.com)后加robots.txt查看，robots可以針對不同的搜索引擎進行不同的頁面規則爬取限制，allow表示允許爬取；disallow表示不允許爬取，
如果robots.txt檔案編輯的太過詳細，會泄露網站的敏感目錄或者檔案，比如disallow: /admin/login、disallow/admin/register等，直接將詳細的后臺路徑寫出來，容易被攻擊者收集利用，
可以通過正則通配符的方式，模糊的進行路徑匹配:
- User-agent:
*這里的代表的所有的搜索引擎種類 - Disallow:
/admin/表示禁止爬尋admin目錄下面的目錄 - Disallow:
/?禁止訪問網站中所有包含問號?的網址 - Disallow:
/.jpg禁止抓取網頁所有的jpg格式的圖片
...
前端保存密鑰資訊
有時候，系統可能需要依賴第三方系統進行一些輔助功能，比如發短信、審批系統等，如果業務架構設計不合理，將這些第三方服務的密鑰key放在前端存盤，前端直接呼叫服務，攻擊者可以分析前端js代碼獲取到密鑰，導致資訊泄露，
介面回傳用戶敏感資訊未進行脫敏處理
當介面需要回傳用戶敏感資訊(如：身份證、手機號、姓名、詳細地址等)時，需要對這些資訊進行脫敏處理，避免被攻擊者獲取利用，
過多回傳用戶敏感資訊
有些時候，可能一個介面會被不同前端模塊呼叫，但各個模塊需要用到的資訊不同，比如A模塊需要展示用戶的名稱，B模塊需要獲取用戶的地址，介面把全部資訊回傳，然后前端獲取介面全部欄位后按需使用，有些同學可能會說敏感資訊都已經脫敏處理了，即使全部回傳也不會有風險了，
只能說too young too simple, 假設攻擊者拿到一個手機號后，根據微博、qq等社交軟體獲取到幾個可能是手機號號主姓名的名單，如何進一步確認呢？
相信大家都用支付寶轉過賬，通過手機號轉賬時，會顯示收款人的脫敏姓名，支付寶是實名驗證的，所以這是用戶的真實姓名脫敏資訊，
「點此驗證」還能輸入收款人的姓，進一步確認用戶姓名，
這里并不是說支付寶有漏洞，畢竟這個泄露風險與用戶未經確認導致轉錯賬相比不值一提，只是想提醒大家，敏感資訊也有可能成為攻擊者的一個有用資訊，所以，介面應盡可能少的回傳敏感資訊，
如果確實想要一個介面滿足多個資料要求，GraphQL是個不錯的選擇，后端先定義好資料格式和欄位，前端可按需請求需要的欄位資訊，
第三方平臺泄露
資訊泄露也會發生在作業時使用的第三方平臺網站上，
公司代碼上傳到github
有意或無意，我們可能會將公司代碼上傳到github上，如果代碼中包含組態檔、資料庫賬號密碼等，會造成嚴重泄露后果，
除了加強培訓員工安全意識，強化公司管理制度，避免員工私自上傳代碼，公司還可以利用Hawkeye等github泄露監控工具對github代碼庫進行監控，及時發現員工托管公司代碼到GitHub行為并預警，降低代碼泄露風險，
作業筆記上傳到云存盤工具
為了方便，有時候會將作業筆記、作業資料存放到網盤、云筆記上，多端直接同步，但由此導致的安全問題也不可忽視，
拿印象筆記舉例，印象筆記提供了郵箱找回密碼的功能，一旦郵箱賬號和密碼被泄露，攻擊者可通過郵箱重置印象筆記賬號密碼，登錄用戶印象筆記，
寫在最后
喜歡本文的朋友，歡迎關注公眾號「會玩code」，專注大白話分享實用技術
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/285678.html
標籤：其他
上一篇：我的十年前端生涯