企業應用的Web程序的安全性

提起安全性這個話題，你們恐怕依稀還記得Sony的PSP帳戶信息泄露的事故形成的重大損失。可是又隱隱以爲這事兒離我很遠，無需過多考慮。也有的人會想，咱們作的是企業內部系統因此沒必要太在乎。可是，Web程序的安全性已經悄然來到你我身邊，咱們在使用的系統太多的並無充分考慮安全性。這樣的系統只是還沒有發生事故。一旦發生事故後果至關嚴重。

輕者數據泄露，重者商業損失，更嚴重的致使商譽損失，甚至是企業倒閉。這毫不是危言聳聽，且看看這些年來報道的安全門話題，哪一個不是損失慘重？

今天就來講一說這個話題：企業應用的Web程序的安全性。

不少企業的應用程序喜歡使用Web來開發，一者開發相對簡單，兩者部署容易，三者升級方便。因此，Web每每成爲企業應用開發的首選。可是因爲是企業內部應用，只要不到互聯網上就不會把安全當成一會事兒，並且，即便連到互聯網上，開發的時候也不會過多考慮安全性。

功能永遠在首位，其次是性能，安全~~花錢又多，又看不到效果，反正沒出事兒...等等思惟方式的影響下，安全話題就在企業開發中被一再擱置，成爲一個極少被說起的話題。

然而，企業應用真的就能夠忽略安全嗎？真的就能夠沒必要在乎安全嗎？

 

若是一套工資管理系統，查看工資的代碼能夠不須要權限就可以直接經過URL訪問的話，工資數據就所有泄露了。

若是一套經銷商管理系統，按期向經銷商發送郵件的服務器並無設置密碼，那麼任何人均可以經過這個服務器發送一些匿名郵件。

若是一套銷售管理系統，生成訂單的URL中沒有驗證碼識別，那麼一個機器人就能夠生成無數的無效訂單。

 

一套不安全的餐飲管理系統，在一個有WIFI的餐廳裏，可能會被某個食客攻擊。

一套不安全的生產管理系統（ERP），可能會被工廠裏的一臺手機控制。

 

如今的黑客技術愈來愈多，並不僅是銀行系統才須要安全機制，也不是加了數字證書Web應用就牢不可破了。

企業Web應用的安全問題不容忽視，也並不容易解決。

 

那麼如何在開發的時候就可以很好地規避安全問題呢？(需求與報價階段就應該和客戶談清楚，本文從略)

下面從幾個可以被攻擊的角度進行說明：

 

1. SQL注入

    A. 採用preparedSQL的方式傳遞參數。

    B. 避免社會學猜想，好比密碼字段名不叫作password,pswd等容易被猜想的名稱。

 

2. 垃圾數據

    A. 後臺對於全部的可輸入項的數據進行校驗，包括採用Radio和DropDown構建的組件。

 

3.防止URL濫用

    A.明確標記GET和POST

 

4.防止批量刪除數據

     A. 採用權限校驗

     B.只提供每次刪除一條數據的操做

 

5. CSRF攻擊

    A.在HTML代碼中書寫CSRF禁用代碼

          <meta content="authenticity_token" name="csrf-param" />
          <meta content="<<略>>" name="csrf-token" />

 

6.WebService匿名訪問

   A. WebService的每一個訪問都須要通過認證

   B. 每次認證須要有時效性

   C. 認證經過認證碼進行

 

7.防止密碼泄露

   A. 不在頁面顯示密碼，不在隱含域，HTML註釋，JavaScript中顯示密碼

   B. 不用明文傳輸密碼

   C. 採用較強的密碼策略

   D. 不用員工編號做爲ID，或者姓名全拼、簡拼的方式

   E. 每一個人的初試密碼不一樣，並採起暗文抄送的方式

   F. 不提供取回密碼功能，只提供更改密碼功能，經過有時效的URL進行處理

   G. 不會將密碼發送到郵件中去

   H. 不要在Log中記錄密碼

 

8. 郵件服務器濫用

    A. 必須有用戶名密碼

    B. 只容許來自固定IP的訪問

 

9. 數據庫泄露

     A. 刪除默認帳戶

     B. 修改數據庫端口

     C. 數據庫名稱不容易被猜想

     D. 只容許來自固定IP的訪問

 

10. 文件未經受權下載

     A. 下載文件的目錄不可以經過URL直接訪問

     B. 文件下載前必須通過權限認證

 

11. URL泄露

    A. 沒有權限操做的按鈕不顯示出來，而且相關的JavaScript也應該不出現

 

12. StackTrace泄露

   A.不要爲了維護方便而將Exception的StackTrace輸出到頁面上