1.sql注入：這個很常規了，不要拼字符串以及過濾關鍵字都可以防住，需要注意的是，Cookie提交的參數也是可以導致注入漏洞的。
2.旁注：就是說在保證自己的程序沒問題的同時，也要保證同臺服務器的其他站點沒問題。至少要設置好系統權限，即使別人的站點出問題也不能影響自己的站點。
3.上傳：盡量不要有上傳功能，如果必須有上傳功能。也要做到以下方面：不能讓用戶定義路徑、文件名，限制好可上傳的文件類型。同時要限制好權限，基本規則：執行和可寫是互斥權限，不應同時存在。
4.口令強度：在設置密碼之類的功能上應加入密碼強度要求。服務器上線部署的時候，應該立即把默認密碼修改掉。
5.防窮舉機制：適當的加入驗證碼，防止別人用程序窮舉賬戶密碼。
6.第三方控件：使用第三方控件，應經過嚴格的審核（很多第三方控件上作者故意留有缺陷），并且剔除不必要的功能再使用。
7.權限最小化：能給只讀就給只讀，盡量具體到每一個子目錄。
8.目錄非常規化：得到管理員賬戶密碼，但是找不到后臺登錄地址也是很難***的。后臺路徑不要動不動就是 http://xxxxx/admin、manager、gl之類的，很容易猜解。
10.XSS：俗稱跨站腳本***。用戶把HTML、JS之類的標簽輸入到編輯框，入庫之后，再顯示的時候可以導致版面錯誤、JS能解析執行之類的都屬于XSS的范疇。如果***者插個Iframe連的是個***網頁，那查看這個內容的人就悲劇了。解決方法：過濾大于小于號即可
11.CSRF URL跳轉未驗證漏洞：類似于XSS，只是把代碼寫在URL里，如
http://xxxx/logout.aspx?preURL=aaaa.html
即經常出現在登錄退出的頁面，通過參數的preURL決定完成動作的時候跳向哪個頁面，如果照樣
http://xxxx/logout.aspx?preURL=javascript:alert('test')
就可以彈框，說明我們的js代碼已經被執行起來了。

總之一句話，開發過程中，不要相信用戶提交的任何數據，規劃好目錄，做到權限最小化，關閉、刪除不必要的東西，就相對會安全很多了。

cert 安全編碼建議：
1、驗證輸入：從不可信任的數據源中進行的輸入需要驗證。合適的輸入驗證能減少大量軟件的弱點。必須對大部分的數據源持懷疑的態度，包括命令行參數，網絡接口，環境變量及用戶文件。
2、留言編譯器警告：編譯代碼時使用編譯器的最高警告級別，通過修改代碼來減少警告。
3、針對安全策略的架構和設計：構建軟件架構和設計軟件時采用安全策略。例如：如果系統在不同的時間需要不同的權限，則考慮將系統分成不同的互相通信的子系統，每個系統擁有合適的權限。
4、保持簡單性：設計越簡單越好，復雜的設計提高了實現時錯誤的可能性。
5、默認拒絕：默認的訪問策略建立在允許的基礎上。也就是說，默認的訪問是拒絕的，除非標明是允許的。
6、最小權限原則：每個進程擁有完成工作所需的最小權限。任何權限的擁有時間要盡可能的短。這一方法能阻止***者利用權限提升執行任意代碼的機會。
7、清潔發送給其他系統的數據：清潔所有發送給復雜子系統的數據，例如：命令外殼（shells），關系數據庫，商用組件。***者可能通過SQL命令或者注入進行***。這不是靠子系統通過輸入驗證來避免的問題，因為子系統不清楚調用的上下文，而調用過程指導上下文，所以有責任在調用子系統時清潔數據。
8、縱深防御：這是一個通用的安全原則，從多個防御策略中規避風險，如果一層防御失效，則另一層防御還在發揮作用。
9、使用有效的安全質量保證技術：好的質量保證技術能有效的發現和消除弱點。***測試、Fuzz測試，以及源代碼審計都能作為一種有效的質量保證措施。獨立的安全審查能夠建立更安全的系統。
10、采用安全編碼標準：為開發語言和平臺指定安全編碼標準，并采用這些標準。
?

轉載于:https://blog.51cto.com/infosec/801492

總結

以上是生活随笔為你收集整理的Web安全开发注意事项的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。