1. 信息傳輸加密

https 使用對稱加密還是非對稱加密？

對稱加密使用 DES 還是 AES？

非對稱加密使用 RSA 還是 DSA？

• 使用什么加密算法，在購*書的時(shí)候就要確定。一般是用 RSA 2048 位。

SSL 證書需要不需要購買？

• 不需要購買的理由 - 我們使用HTTPS的目的就是希望服務(wù)器與客戶端之間傳輸內(nèi)容是加密的，防止中間監(jiān)聽泄漏信息，去證書服務(wù)商那里申請證書不劃算，因?yàn)槭褂梅?wù)的都是固定客戶和自己內(nèi)部人士，所以我們自己給自己頒發(fā)證書，忽略掉瀏覽器的不信任警報(bào)即可；
• 需要購買的理由 - 用戶體驗(yàn)好、專業(yè)性強(qiáng)。

雙向驗(yàn)證還是單向驗(yàn)證？

• 單向驗(yàn)證驗(yàn)證的是服務(wù)器；雙向驗(yàn)證服務(wù)器客戶端互相驗(yàn)證。
• 對于服務(wù)器來講，單向驗(yàn)證能夠保證傳輸?shù)臄?shù)據(jù)加密過了；雙向驗(yàn)證不僅保證傳輸數(shù)據(jù)加密，還能夠保證客戶端來源的安全性。
• 如果使用雙向驗(yàn)證的話，需要客戶端瀏覽器導(dǎo)入證書。
• 出于客戶體驗(yàn)的考慮，大部分 https 網(wǎng)站使用的都是單向驗(yàn)證(比如 CSDN 登錄)，一些安全性要求高的使用的是雙向驗(yàn)證(比如招行網(wǎng)上銀行、支付寶)。

證書是和域名綁定的，服務(wù)開放之前，域名確定、購買，https 證書的購買需要先搞定。

2. 文件存儲(chǔ)加密

非對稱加密使用什么加密算法，RSA 還是 DSA？

非對稱加解密的話，加解密比較慢，實(shí)現(xiàn)上使用 java 實(shí)現(xiàn)還是 c？

3. 防御 XSS 攻擊

服務(wù)前臺(tái)客戶端，對用戶輸入進(jìn)行 js 表單驗(yàn)證；

目前，我們服務(wù)前臺(tái)的客戶端的表單驗(yàn)證也要交互一下后臺(tái)，增加了后臺(tái)負(fù)載，而且還留下了 XSS 攻擊隱患；

應(yīng)該是接受指定長度范圍內(nèi)、采用適當(dāng)格式、采用所預(yù)期的字符的內(nèi)容提交；

對于對其他的特別是 javascript 相關(guān)的特殊字符一律過濾；

對于某些 html 危險(xiǎn)字符進(jìn)行轉(zhuǎn)義，比如 > 轉(zhuǎn)義為 &gt，< 轉(zhuǎn)義為 &lt；

對于存放敏感信息的 Cookie，對該 Cookie 添加 HttpOnly 屬性，避免被攻擊腳本竊?。?/h2>

服務(wù)前臺(tái)服務(wù)器端，對用戶輸入再次驗(yàn)證；

進(jìn)行服務(wù)器端表單級(jí)驗(yàn)證，防止惡意用戶模擬瀏覽器繞過 js 代碼進(jìn)行攻擊；

建議對于服務(wù)器端表單驗(yàn)證統(tǒng)一系統(tǒng)異常碼，結(jié)合系統(tǒng)異常處理機(jī)制?？蛻舳烁鶕?jù)服務(wù)器端返回異常碼顯示相應(yīng)信息，而不是將異常報(bào)告赤裸裸地展現(xiàn)給客戶：一是用戶體驗(yàn)不好，二者給惡意用戶帶來可趁之機(jī)；

程序中使用 ESAPI 庫預(yù)防 XSS：

4. 防御 SQL 注入

同 3 防御 XSS 攻擊中"建議對于服務(wù)器端表單驗(yàn)證統(tǒng)一系統(tǒng)異常碼"條；

服務(wù)前臺(tái)客戶端在進(jìn)行表單級(jí)驗(yàn)證的需要對 drop、update、delete 等 SQL 進(jìn)行消毒；

服務(wù)前臺(tái)服務(wù)器端再次進(jìn)行服務(wù)器表單級(jí)驗(yàn)證的時(shí)候，需要再次對 drop、update、delete 等 SQL 進(jìn)行消毒，防止惡意用戶繞過 js 進(jìn)行攻擊；

對敏感字符進(jìn)行轉(zhuǎn)義，比如 ' 轉(zhuǎn)義為 \'；

傳統(tǒng) jdbc 進(jìn)行參數(shù)綁定，如

hibernate 進(jìn)行參數(shù)綁定，如

iBATIS/MyBatis 進(jìn)行參數(shù)綁定，在 SQL 語句的節(jié)點(diǎn)中，設(shè)置 parameterClass = "java.util.Map"即可，程序里把參數(shù)封裝到 Map 中;

5. 防御 CSRF 攻擊

使用 Struts2 的表單標(biāo)簽，其中需要增加 token 標(biāo)簽；

重要的節(jié)點(diǎn)如復(fù)核，加一個(gè)驗(yàn)證碼驗(yàn)證；

檢查 HTTP 請求頭的 Referer 域，驗(yàn)證是否合法；

6. 劃款環(huán)節(jié)的安全加強(qiáng)

服務(wù)前臺(tái)登錄需要?jiǎng)討B(tài)口令；

每一筆劃款請求需要?jiǎng)討B(tài)口令；

每一筆劃款短信、郵件通知客戶；

設(shè)定限額等風(fēng)險(xiǎn)規(guī)則，超過就預(yù)警，需額外人工授權(quán)才能審核通過；

7. 避免表單重復(fù)提交

使用 Struts2 的表單標(biāo)簽，其中需要增加 token 標(biāo)簽；

對上傳文件進(jìn)行哈希庫記錄驗(yàn)證，如有重復(fù)詢問客戶是否繼續(xù)；

關(guān)鍵接口的冪等性設(shè)計(jì)；

每次表單提交后，客戶端禁用”提交”按鈕；

8. nginx 反向代理

nginx 是我們服務(wù)器對外的*層屏障；

• 通過它我們可以輕松進(jìn)行各種安全設(shè)定，比如禁止 IP、限制 IP 并發(fā)數(shù)(這個(gè)可以預(yù)防 DOS 攻擊)、設(shè)置 timeout 時(shí)間(這個(gè)也可以預(yù)防 DOS 攻擊)、限制用戶帶寬等等；
• nginx 還能對外屏蔽服務(wù)器接口路徑、靜態(tài)文件真實(shí)路徑，避免路徑遍歷攻擊；
• nginx 有個(gè)專門預(yù)防 XSS、注入攻擊的模塊 naxsi；

動(dòng)靜分離，加快響應(yīng)速度，降低 tomcat 負(fù)載；

負(fù)載均衡；

9. 及時(shí)更新 Struts2 框架

10. 設(shè)置文件上傳白名單，或者干脆限制為 xls、xlsx，以避免上傳文件攻擊

根據(jù)上傳文件名后綴進(jìn)行文件類型驗(yàn)證；

根據(jù)上傳文件的文件頭進(jìn)行文件類型驗(yàn)證；

11. nginx 漏洞利用和安全加固

nginx 配置錯(cuò)誤而導(dǎo)致目錄遍歷漏洞;

nginx 版本的選擇;

• 關(guān)于 nginx 的安全漏洞可以關(guān)注 nginx 官方發(fā)布的安全公告 或到其他一些漏洞發(fā)布平臺(tái)上查找。
• 在安裝 nginx 時(shí)建議使用自定義安裝路徑，如果采用默認(rèn)安裝路徑，很容易被攻擊者和一些自動(dòng)化攻擊工具猜測到，為其進(jìn)行下一步的攻擊提供便利。
• 在選擇 nginx 版本時(shí)，需要關(guān)注是否存在安全漏洞和版本的穩(wěn)定性。一般選擇*的穩(wěn)定版本，這樣可以在穩(wěn)定性和安全之間取得一個(gè)平衡。

修改/隱藏 Nginx Banner 信息;

日志安全;

• 修改日志的默認(rèn)保存路徑，然后設(shè)置只允許管理員有日志存放目錄的安全控制權(quán)限。

nginx 權(quán)限設(shè)置;

• 給 nginx 一個(gè)權(quán)限比較低的身份運(yùn)行，可以通過修改 nginx.conf 進(jìn)行調(diào)整。應(yīng)用服務(wù)器、數(shù)據(jù)庫也應(yīng)該遵循這個(gè)原則。

關(guān)閉服務(wù)器標(biāo)記;

• 如果開啟的話(默認(rèn)為開啟)，所有錯(cuò)誤頁面都會(huì)顯示服務(wù)器的版本和信息。

設(shè)置自定義緩存以預(yù)防緩存區(qū)溢出攻擊;

12. web 服務(wù)器和應(yīng)用服務(wù)器目錄權(quán)限設(shè)置原則

如果目錄有寫入權(quán)限，一定不要分配執(zhí)行權(quán)限；

• 比如網(wǎng)站上傳目錄和數(shù)據(jù)庫目錄一般需要分配寫入權(quán)限，但一定不要分配執(zhí)行權(quán)限。

如果目錄有執(zhí)行權(quán)限，一定不要分配寫入權(quán)限；

一般目錄只需分配讀取權(quán)限即可；

應(yīng)用服務(wù)器和數(shù)據(jù)庫部署在不同的服務(wù)器上；

文件屬主與應(yīng)用服務(wù)器進(jìn)程屬主不同(一般設(shè)置文件屬主為 root)；

控制腳本只運(yùn)行訪問應(yīng)用項(xiàng)目目錄下的文件;

13. 代碼混淆

靜態(tài) js 代碼混淆；

應(yīng)用程序 java 代碼混淆；