計完整清單與自查教程)
從XSS凈化到OAuth登錄Wri.pe安全設(shè)計完整清單與自查教程【免費下載鏈接】open-wripehttps://wri.pe source code項目地址: https://gitcode.com/gh_mirrors/op/open-wripeWri.pe 是一款開源的 Web 個人筆記應(yīng)用https://wri.pe 的源代碼核心能力包括 Markdown 筆記編輯、多端日歷視圖、頁面分享以及 GitHub、Facebook、Evernote、Dropbox 等第三方登錄與同步。對于筆記里存著敏感內(nèi)容的產(chǎn)品來說安全設(shè)計不是可選項。本文帶你用8 個真實代碼點完整拆解 Wri.pe 的安全機制并附一份可直接抄走的自查清單。 Wri.pe 安全設(shè)計總覽清單先給一張全景表后面逐項展開#安全維度Wri.pe 的做法關(guān)鍵文件1XSS 防護Markdown 渲染后二次凈化 鏈接協(xié)議白名單app/models/page.rb2前端轉(zhuǎn)義模板統(tǒng)一escape_htmlapp/assets/javascripts/shared/utils.js.coffee3CSRF 防護protect_from_forgery 失敗降級處理app/controllers/application_controller.rb4會話管理session 只存用戶 ID登出即重置app/controllers/sessions_controller.rb5OAuth 登錄GitHub/Facebook 走 OAuth2Evernote 走 OAuth1.0alib/ghauth.rb、lib/evernote_auth.rb6密鑰管理敏感配置獨立 YAML按環(huán)境加載config/github-sample.yml7數(shù)據(jù)權(quán)限讀/寫/分享三級權(quán)限越權(quán)返回 403app/models/page.rb8并發(fā)安全lock_version樂觀鎖沖突返回 409app/controllers/pages_controller.rb? 深度一XSS 凈化——先渲染再消毒最后查戶口筆記應(yīng)用最大的風(fēng)險是用戶輸入 Markdown → 渲染成 HTML → 危險標(biāo)簽被瀏覽器執(zhí)行。Wri.pe 在 app/models/page.rb 的body_html方法里做了三道防線第一道渲染。用 Redcarpet 把 Markdown 轉(zhuǎn)成 HTML開啟lax_html_blocks等選項支持富文本。第二道凈化。HTML 交給sanitize庫清洗Sanitize.clean(html, Sanitize::Config::RELAXED)依據(jù)白名單移除script、onerror等危險節(jié)點和屬性依賴聲明在 Gemfile 中升級時建議同步關(guān)注安全公告。第三道鏈接協(xié)議白名單。用 Nokogiri 遍歷所有a標(biāo)簽只保留http/https協(xié)議的 href其余比如javascript:alert(1)這種直接被降級為span并刪掉 href——等于給每個鏈接查戶口。前端也同步轉(zhuǎn)義JS 模板中拼接用戶數(shù)據(jù)前統(tǒng)一走escape_html底層是 lodash 的_.escape見 app/assets/javascripts/shared/utils.js.coffee例如日歷面板里插入標(biāo)題前先轉(zhuǎn)義# app/assets/javascripts/app/calendar_panel.js.coffee li class\page\a href\\##{escape_html(p.key)}/edit\#{escape_html(p.title)}/a/li 自查要點凡是有用戶輸入 → HTML路徑的地方問自己三個問題服務(wù)端凈化了嗎白名單是什么前端拼接轉(zhuǎn)義了嗎 深度二CSRF 與會話——給每個請求發(fā)防偽貼紙Wri.pe 的控制器全部繼承自 app/controllers/application_controller.rb其中兩處設(shè)計很值得借鑒全局開啟 CSRF 防護protect_from_forgery一行代碼所有表單和寫操作都必須攜帶合法 token。失敗的優(yōu)雅降級handle_unverified_request拋出的InvalidAuthenticityToken被統(tǒng)一攔截——HTML 請求重定向回首頁JSON 請求返回412 Precondition Failed。對單頁應(yīng)用SPA的 AJAX 調(diào)用特別友好前端能明確感知token 失效并引導(dǎo)重新登錄。會話本身保持極簡app/controllers/sessions_controller.rb 中 session 里只存authorized_user_id一個整數(shù)用戶信息實時查庫并校驗active?狀態(tài)。登出時調(diào)用reset_session徹底清空sessions_controller.rb避免 session 固定攻擊。同時前端每次啟動都會向服務(wù)端拉取最新的csrf_token用于后續(xù) API 請求。 自查要點會話里是否存了不必要的敏感數(shù)據(jù)token 校驗失敗時接口返回是否能讓前端做正確處理 深度三OAuth 登錄——第三方賬號的安全接入Wri.pe 支持四種第三方登錄源碼分布清晰服務(wù)協(xié)議授權(quán)模塊回調(diào)控制器GitHubOAuth 2.0lib/ghauth.rbapp/controllers/ghauth_controller.rbFacebookOAuth 2.0lib/fbauth.rbapp/controllers/fbauth_controller.rbEvernoteOAuth 1.0alib/evernote_auth.rbapp/controllers/evernote_auth_controller.rbDropboxOAuth見模型 app/models/dropbox_user.rbapp/controllers/dropbox_auth_controller.rb以 GitHub 為例流程只有兩步app/controllers/ghauth_controller.rb發(fā)起授權(quán)302 跳轉(zhuǎn)到 GitHub 的授權(quán)頁只申請最小權(quán)限scope: user:email——這是 OAuth 安全里最小權(quán)限原則的典型示范回調(diào)換 token拿code換取 access_token驗證用戶身份后把user.id寫入 session 并跳轉(zhuǎn)首頁。兩個細節(jié)很見功力控制器頂部rescue_from OAuth::Unauthorized授權(quán)異常統(tǒng)一重定向回首頁不會把堆棧暴露給用戶回調(diào)中的 token 交換用rescue e兜底失敗只記日志 友好提示絕不把 token 或異常細節(jié)渲染到頁面。密鑰管理是 OAuth 安全的另一半client_id/client_secret放在獨立 YAML 中且按環(huán)境隔離——倉庫里只提供 config/github-sample.yml、config/evernote-sample.yml 等模板真實密鑰通過 lib/ghauth.rb 里的YAML.load(...)[Rails.env]按當(dāng)前環(huán)境加載。部署時替換模板即可模板文件本身不含任何秘密。 自查要點OAuth 權(quán)限范圍是否最小化token 是否只出現(xiàn)在日志和內(nèi)存中密鑰是否隨環(huán)境隔離且模板入庫 深度四數(shù)據(jù)權(quán)限與并發(fā)——最后一道門即使前面全部做對誰能看什么也不能失守。Wri.pe 在 app/models/page.rb 定義了三級權(quán)限permit_read?本人、公開頁SHARE_URL或被授權(quán)的協(xié)作者可讀permit_write?/permit_share?本人或顯式授予寫/分享權(quán)限的用戶。控制器里 app/controllers/pages_controller.rb 的show/update/destroy都在第一行就檢查權(quán)限越權(quán)直接403 Forbidden先鑒權(quán)再干活。并發(fā)安全方面頁面表帶lock_version字段樂觀鎖更新時若客戶端提交的版本號落后于服務(wù)端app/controllers/pages_controller.rb直接返回409 Conflict而不是盲目覆蓋——多人協(xié)作場景下避免后寫覆蓋先寫的數(shù)據(jù)丟失。另外用戶的備份導(dǎo)出鏈接靠創(chuàng)建時隨機生成的 96 位export-key保護app/models/user.rb相當(dāng)于URL 即憑證無法被枚舉猜測。? 安全自查教程5 問清單可直接套用到你的項目XSS所有用戶輸入 → HTML的路徑服務(wù)端有白名單凈化嗎前端拼接有統(tǒng)一轉(zhuǎn)義函數(shù)嗎參考body_html的三道防線CSRF全局開了 forgery 防護嗎t(yī)oken 失效時接口返回能驅(qū)動前端重新登錄嗎會話session 里存的最小化嗎登出是否reset_session用戶狀態(tài)失效后舊會話是否立刻作廢OAuthscope 最小化了嗎異常路徑會不會泄露 token/堆棧密鑰是否入庫權(quán)限與并發(fā)每個數(shù)據(jù)接口第一行是鑒權(quán)嗎寫操作有版本號或等價機制嗎 延伸閱讀核心模塊路徑數(shù)據(jù)模型與凈化邏輯app/models/page.rb權(quán)限與會話基類app/controllers/application_controller.rb頁面接口鑒權(quán)/樂觀鎖app/controllers/pages_controller.rbOAuth 模塊lib/ghauth.rb、lib/fbauth.rb、lib/evernote_auth.rb會話管理app/controllers/sessions_controller.rb依賴聲明Gemfile登錄功能測試spec/features/Wri.pe 的安全設(shè)計沒有炫技全是小步到位凈化用白名單、授權(quán)用最小 scope、鑒權(quán)放在接口第一行、密鑰按環(huán)境隔離。這正是開源項目最值得新手抄作業(yè)的地方——每一條防護都有對應(yīng)的具體代碼可以對照學(xué)習(xí)?！久赓M下載鏈接】open-wripehttps://wri.pe source code項目地址: https://gitcode.com/gh_mirrors/op/open-wripe創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 從XSS凈化到OAuth登錄：Wri.pe安全設(shè)計完整清單與自查教程
從XSS凈化到OAuth登錄Wri.pe安全設(shè)計完整清單與自查教程【免費下載鏈接】open-wripehttps://wri.pe source code項目地址: https://gitcode.com/gh_mirrors/op/open-wripeWri.pe 是一款開源的 Web 個人筆記應(yīng)用https://wri.pe 的源代碼核心能力包括 Markdown 筆記編輯、多端日歷視圖、頁面分享以及 GitHub、Facebook、Evernote、Dropbox 等第三方登錄與同步。對于筆記里存著敏感內(nèi)容的產(chǎn)品來說安全設(shè)計不是可選項。本文帶你用8 個真實代碼點完整拆解 Wri.pe 的安全機制并附一份可直接抄走的自查清單。 Wri.pe 安全設(shè)計總覽清單先給一張全景表后面逐項展開#安全維度Wri.pe 的做法關(guān)鍵文件1XSS 防護Markdown 渲染后二次凈化 鏈接協(xié)議白名單app/models/page.rb2前端轉(zhuǎn)義模板統(tǒng)一escape_htmlapp/assets/javascripts/shared/utils.js.coffee3CSRF 防護protect_from_forgery 失敗降級處理app/controllers/application_controller.rb4會話管理session 只存用戶 ID登出即重置app/controllers/sessions_controller.rb5OAuth 登錄GitHub/Facebook 走 OAuth2Evernote 走 OAuth1.0alib/ghauth.rb、lib/evernote_auth.rb6密鑰管理敏感配置獨立 YAML按環(huán)境加載config/github-sample.yml7數(shù)據(jù)權(quán)限讀/寫/分享三級權(quán)限越權(quán)返回 403app/models/page.rb8并發(fā)安全lock_version樂觀鎖沖突返回 409app/controllers/pages_controller.rb? 深度一XSS 凈化——先渲染再消毒最后查戶口筆記應(yīng)用最大的風(fēng)險是用戶輸入 Markdown → 渲染成 HTML → 危險標(biāo)簽被瀏覽器執(zhí)行。Wri.pe 在 app/models/page.rb 的body_html方法里做了三道防線第一道渲染。用 Redcarpet 把 Markdown 轉(zhuǎn)成 HTML開啟lax_html_blocks等選項支持富文本。第二道凈化。HTML 交給sanitize庫清洗Sanitize.clean(html, Sanitize::Config::RELAXED)依據(jù)白名單移除script、onerror等危險節(jié)點和屬性依賴聲明在 Gemfile 中升級時建議同步關(guān)注安全公告。第三道鏈接協(xié)議白名單。用 Nokogiri 遍歷所有a標(biāo)簽只保留http/https協(xié)議的 href其余比如javascript:alert(1)這種直接被降級為span并刪掉 href——等于給每個鏈接查戶口。前端也同步轉(zhuǎn)義JS 模板中拼接用戶數(shù)據(jù)前統(tǒng)一走escape_html底層是 lodash 的_.escape見 app/assets/javascripts/shared/utils.js.coffee例如日歷面板里插入標(biāo)題前先轉(zhuǎn)義# app/assets/javascripts/app/calendar_panel.js.coffee li class\page\a href\\##{escape_html(p.key)}/edit\#{escape_html(p.title)}/a/li 自查要點凡是有用戶輸入 → HTML路徑的地方問自己三個問題服務(wù)端凈化了嗎白名單是什么前端拼接轉(zhuǎn)義了嗎 深度二CSRF 與會話——給每個請求發(fā)防偽貼紙Wri.pe 的控制器全部繼承自 app/controllers/application_controller.rb其中兩處設(shè)計很值得借鑒全局開啟 CSRF 防護protect_from_forgery一行代碼所有表單和寫操作都必須攜帶合法 token。失敗的優(yōu)雅降級handle_unverified_request拋出的InvalidAuthenticityToken被統(tǒng)一攔截——HTML 請求重定向回首頁JSON 請求返回412 Precondition Failed。對單頁應(yīng)用SPA的 AJAX 調(diào)用特別友好前端能明確感知token 失效并引導(dǎo)重新登錄。會話本身保持極簡app/controllers/sessions_controller.rb 中 session 里只存authorized_user_id一個整數(shù)用戶信息實時查庫并校驗active?狀態(tài)。登出時調(diào)用reset_session徹底清空sessions_controller.rb避免 session 固定攻擊。同時前端每次啟動都會向服務(wù)端拉取最新的csrf_token用于后續(xù) API 請求。 自查要點會話里是否存了不必要的敏感數(shù)據(jù)token 校驗失敗時接口返回是否能讓前端做正確處理 深度三OAuth 登錄——第三方賬號的安全接入Wri.pe 支持四種第三方登錄源碼分布清晰服務(wù)協(xié)議授權(quán)模塊回調(diào)控制器GitHubOAuth 2.0lib/ghauth.rbapp/controllers/ghauth_controller.rbFacebookOAuth 2.0lib/fbauth.rbapp/controllers/fbauth_controller.rbEvernoteOAuth 1.0alib/evernote_auth.rbapp/controllers/evernote_auth_controller.rbDropboxOAuth見模型 app/models/dropbox_user.rbapp/controllers/dropbox_auth_controller.rb以 GitHub 為例流程只有兩步app/controllers/ghauth_controller.rb發(fā)起授權(quán)302 跳轉(zhuǎn)到 GitHub 的授權(quán)頁只申請最小權(quán)限scope: user:email——這是 OAuth 安全里最小權(quán)限原則的典型示范回調(diào)換 token拿code換取 access_token驗證用戶身份后把user.id寫入 session 并跳轉(zhuǎn)首頁。兩個細節(jié)很見功力控制器頂部rescue_from OAuth::Unauthorized授權(quán)異常統(tǒng)一重定向回首頁不會把堆棧暴露給用戶回調(diào)中的 token 交換用rescue e兜底失敗只記日志 友好提示絕不把 token 或異常細節(jié)渲染到頁面。密鑰管理是 OAuth 安全的另一半client_id/client_secret放在獨立 YAML 中且按環(huán)境隔離——倉庫里只提供 config/github-sample.yml、config/evernote-sample.yml 等模板真實密鑰通過 lib/ghauth.rb 里的YAML.load(...)[Rails.env]按當(dāng)前環(huán)境加載。部署時替換模板即可模板文件本身不含任何秘密。 自查要點OAuth 權(quán)限范圍是否最小化token 是否只出現(xiàn)在日志和內(nèi)存中密鑰是否隨環(huán)境隔離且模板入庫 深度四數(shù)據(jù)權(quán)限與并發(fā)——最后一道門即使前面全部做對誰能看什么也不能失守。Wri.pe 在 app/models/page.rb 定義了三級權(quán)限permit_read?本人、公開頁SHARE_URL或被授權(quán)的協(xié)作者可讀permit_write?/permit_share?本人或顯式授予寫/分享權(quán)限的用戶。控制器里 app/controllers/pages_controller.rb 的show/update/destroy都在第一行就檢查權(quán)限越權(quán)直接403 Forbidden先鑒權(quán)再干活。并發(fā)安全方面頁面表帶lock_version字段樂觀鎖更新時若客戶端提交的版本號落后于服務(wù)端app/controllers/pages_controller.rb直接返回409 Conflict而不是盲目覆蓋——多人協(xié)作場景下避免后寫覆蓋先寫的數(shù)據(jù)丟失。另外用戶的備份導(dǎo)出鏈接靠創(chuàng)建時隨機生成的 96 位export-key保護app/models/user.rb相當(dāng)于URL 即憑證無法被枚舉猜測。? 安全自查教程5 問清單可直接套用到你的項目XSS所有用戶輸入 → HTML的路徑服務(wù)端有白名單凈化嗎前端拼接有統(tǒng)一轉(zhuǎn)義函數(shù)嗎參考body_html的三道防線CSRF全局開了 forgery 防護嗎t(yī)oken 失效時接口返回能驅(qū)動前端重新登錄嗎會話session 里存的最小化嗎登出是否reset_session用戶狀態(tài)失效后舊會話是否立刻作廢OAuthscope 最小化了嗎異常路徑會不會泄露 token/堆棧密鑰是否入庫權(quán)限與并發(fā)每個數(shù)據(jù)接口第一行是鑒權(quán)嗎寫操作有版本號或等價機制嗎 延伸閱讀核心模塊路徑數(shù)據(jù)模型與凈化邏輯app/models/page.rb權(quán)限與會話基類app/controllers/application_controller.rb頁面接口鑒權(quán)/樂觀鎖app/controllers/pages_controller.rbOAuth 模塊lib/ghauth.rb、lib/fbauth.rb、lib/evernote_auth.rb會話管理app/controllers/sessions_controller.rb依賴聲明Gemfile登錄功能測試spec/features/Wri.pe 的安全設(shè)計沒有炫技全是小步到位凈化用白名單、授權(quán)用最小 scope、鑒權(quán)放在接口第一行、密鑰按環(huán)境隔離。這正是開源項目最值得新手抄作業(yè)的地方——每一條防護都有對應(yīng)的具體代碼可以對照學(xué)習(xí)?！久赓M下載鏈接】open-wripehttps://wri.pe source code項目地址: https://gitcode.com/gh_mirrors/op/open-wripe創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考