web安全問題越來越受到重視,特別是各大型網際網路公司,如**網，支付寶，拍拍網，各大網銀，及電子商務**，安全和作弊問題以被提高為產品的第一道衡量標準。
在網際網路的世界裡面，自己家安全防衛沒做到位，而受到損失的話，除非是國家銀行，其他還真是自己得受著，沒有任何挽回機會，甚至還會造成自己企業名譽和使用者認知度的下降。
這篇就主要在整體上觀摩一下web的安全問題，主要視角則是從從使用者端到server的核心資料的路徑上的安全環節問題的一些**。
首先我們看下web訪問的請求路徑圖，如下：
使用者都是通過瀏覽器來訪問我們的**，而瀏覽器本身也是乙個程式，如果程式在設計的時候，未考慮周全，當遇到異常情況，引發出不可預見的錯誤。如果這個漏洞，被不良使用者利用，會造成資訊洩漏，如黑客攻擊**，導致的後果是不堪設想。這方面主要是提醒使用者及時更新瀏覽器的新版本。
(2)firewall
這個階段一般公司都會採用運維維護和專人負責的形式負責這塊。當然這裡會延伸出黑紅客角色，但是作為開發者尚且是不太用關注這裡的，術業有專攻，防火牆是乙個web應用的安全防盾，交給專業的黑紅客相關負責人員研究，感興趣的話也可單獨研究防火牆的安全技術
（3)webserver
這個關口主要是從以下幾個方面看安全問題：
更新伺服器版本----更新server的新版本，保證應用的母體是安全的
安全配置----保證root使用者的許可權不能開放到網路應用中，角色和許可權設定要清晰明確，容不得半點差錯，否則就是養虎為患了
比如：別人有可能會覆蓋httpd可執行檔案，那麼下一次啟動時，就會執行惡意**。如果日誌目錄(對非root使用者)是可寫的，別人就有可能用乙個指向其他敏感檔案的連線來覆蓋日誌檔案，使那個檔案被改寫為雜亂的資料。如果日誌檔案本身(對非root使用者)是可寫的，別人就可能偽造日誌。這些所有的所有都會混亂試聽，從而把應用的所有證據搞的一團糟。
觀察日誌檔案----這個是個亡羊補牢的手段拉，是總結教訓的地方，但是如果上乙個環節上已經被偽造了日誌的話，就悲劇了
cgi安全----web server一般都會呼叫cgi來響應使用者的互動，而cgi對web server上的檔案和目錄是也有訪問許可權的，但是如果訪問許可權控制不合理，就可能導致安全隱患，舉個例子來說：使用者提交乙個使用者名稱到後台，後台cgi就把使用者名稱對應的檔案讀出來，並顯示到頁面上
如果對使用者名稱沒有做過濾，使用者提交了乙個「的使用者名稱，那麼伺服器上的使用者名稱資訊就暴露給了hacker，可想而知這是多麼地危險。這個階段還有一些資訊洩漏等安全問題。這個階段也是開發者尤其需要關注的乙個環節。我們開發的cgi一定要充分關注本身cgi的安全，並且不能相信該環節前面的環節的安全已經做到位，而要從自己這邊一樣重新安全防範一遍，bs兩端都要做。
（5）db的安全
這裡大家都不陌生的，乙個最最嚴重的問題就是sql inj，其次就是db的授權問題。
sql inj 相信大家已經很熟悉了，也是最起碼的資料庫應用會考慮到的一種安全問題，這裡就不贅述了。
預告：根據owasp組織公布的2023年十大web安全漏洞，其中十大安全漏洞主要有：
1、注入漏洞(包括sql/xpath等)；
2、跨站指令碼xss；
3、認證攻擊和會話操縱；
4、非安全物件直接引用；
5、跨站請求偽造；
6、部署安全；
7、非安全加密儲存；
8、失敗的**訪問缺陷限制；
9、不充足的傳輸層保護；
10、jump跳轉
後續會繼續跟大家一起分享每個詳細的安全問題的廬山真面目。
web開發之資料安全
關於介面安全，一般非常簡單的作用，只是使用者驗證，即合法性檢查。我乙個老同事一直這樣用 個人感覺也未嘗不可 每次請求 介面的時候 驗證下access token，比如這個token是個 md5值，再在這個值上面加幾個隨機數，這這值就不是md5的值了，可破解的難道就大大增加了。if post acce...
Web安全之CSRF攻擊
csrf是什麼？csrf cross site request forgery 中文是跨站點請求偽造。csrf攻擊者在使用者已經登入目標 之後，誘使使用者訪問乙個攻擊頁面，利用目標 對使用者的信任，以使用者身份在攻擊頁面對目標 發起偽造使用者操作的請求，達到攻擊目的。舉個例子 簡單版 假如有個加關注...
Web安全之CSRF攻擊
源文位址 csrf是什麼？csrf cross site request forgery 中文是跨站點請求偽造。csrf攻擊者在使用者已經登入目標 之後，誘使使用者訪問乙個攻擊頁面，利用目標 對使用者的信任，以使用者身份在攻擊頁面對目標 發起偽造使用者操作的請求，達到攻擊目的。舉個例子 簡單版 假如...