1. 程式人生 > >伺服器端應用安全

伺服器端應用安全

SQL注入

盲注

Web伺服器關閉了錯誤回顯,對於攻擊者就缺少了重要的除錯資訊,所以攻擊者知道一個方法來驗證SQL語句是否執行
比如

http://xxxx.com/items.php?id=2
構造
http://xxxx.com/items.php?id=2 and 1=2
如果頁面是空的,或者出差,可以猜測這可能存在注入的機會
再次修改
http://xxxx.com/items.php?id=2 and 1=1
如果正常返回,就可以判斷注入成功

BENCHMARK函式

BENCHMARK函式用來測試函式效能

BENCHMARK(10000000,ENCODE('msg','by 5 seconds'
)
)
encode(xxx,xxx)執行xxxx次數

利用BENCHMARK函式,可以讓同一個行數執行若干次,使得結果返回的時間比平時長,通過時間長度變化,可以判斷注入語句是否執行成功

防禦sql注入

  • 預編譯語句,繫結變數
  • 使用儲存過程,呼叫存在資料庫裡的函式
  • 檢查資料型別,如果輸入是數字,就用integer做檢驗,如果是郵箱則正則表示式去做校驗等
  • 使用定義好的安全函式來轉義。
  • 設定資料庫使用者的最小許可權。

檔案上傳漏洞

檔案上傳後導致的常見安全問題一般有:

  • 上傳檔案是Web指令碼語言,伺服器的Web容器解釋並執行使用者上傳的指令碼,導致程式碼執行
  • 上傳檔案是Flash的策略檔案crossdomain.xml,黑客用以控制Flash在該域下的行為(其他通過類似行為控制策略檔案的情況類似)
  • 上傳檔案是病毒,木馬檔案,用以誘惑使用者或者管理員下載執行
  • 上傳檔案是釣魚圖片或為包含指令碼的圖片,在某些版本瀏覽器中會被作為指令碼執行,被用於釣魚和欺詐

設計安全的檔案上傳功能

  • 檔案上傳的目錄設定為不可執行:只要Web容器無法解析該目錄下的檔案,即使上傳了指令碼檔案也不收影響
  • 判斷檔案型別:可以結合MIME Type,字尾檢查等方式。
  • 使用隨機數改寫檔名和檔案路徑:只要修改路徑,上傳的檔案查詢的不容易
  • 單獨設定檔案伺服器的域名:同源策略的關係,一系列客戶端攻擊將生效

使用者資訊管理

密碼強度
  • 普通應用要求長度為6位以上
  • 重要應用要求長度為8位以上,並考慮雙因素認證
  • 密碼區分大小寫字母
  • 密碼為大寫字母,小寫字幕、數字、特殊符號中兩種以上的組合
  • 不要有連續性的字元
  • 儘量避免出現重複的字元
  • 密碼儲存:必須以不可逆的加密演算法,或者是單向雜湊函式演算法,加密後儲存在資料庫中
  • 在計算密碼明文的時候加一個salt MD5(salt+password),避免password 單一容易被彩虹表收集到

Session注意點

  • Seesion在登陸完成後,重寫SessionId,避免SessionFixation攻擊
  • 伺服器設定固定時間強制銷燬Session,因為客戶端可以修改使用者的存活時間,定時拿seesionId去請求。
  • 降低SSO的風險,在一些敏感的系統,在單獨實現額外的認證機制。

訪問控制

  • 垂直許可權管理:現在應用廣泛的一種方法是基於角色的範圍控制:RBAC,Java中的Spring Security 許可權管理,就是RBAC模型的一個實現
  • 水平許可權管理,RBAC只能驗證使用者A屬於角色RoleX,但不會判斷使用者A是否能訪問只屬於使用者B的資料B,發生了越權訪問,這種問題一般是具體問題具體解決,至今仍是一個難題,它難以發現
  • 設計方案時,都應該滿足“最小許可權原則”

加密演算法與隨機數

略。。。

記下結論

  • 不要使用ECB模式
  • 不要使用流密碼(RC4)
  • 使用HMAC-SHA1替代MD5(甚至是替代SHA1)
  • 不要使用相同的key做不同的事情
  • salts與IV需要隨機生成
  • 不要自己實現加密演算法,儘量使用安全專家已經實現好的庫
  • 不要依賴系統的保密性
  • 使用CBC模式的AES256加密
  • 使用HMAC-SHA512用於完整性檢查
  • 使用帶salt的SHA-256或SHA-512用於Hash

DDOS

DDOS又稱為分散式拒絕服務利用合理的請求造成資源過載,導致服務不可用

SYN flood攻擊

  1. 客戶端向伺服器端傳送一個SYN包,包含客戶單使用的埠號和初始序列號X
  2. 伺服器端接受到客戶單傳送的SYN包後,向客戶端傳送一個SYN包和ACK都置位的TCP報文,包含確認號x+1和伺服器端的初始序列號y
  3. 客戶端收到伺服器端返回的SYN+ACK報文後,向伺服器端返回一個確認號為y+1、序號為x+1的ACK報文,一個標準的TCP連線

SYN flood攻擊,首先偽造大量的源IP地址,分別向伺服器端傳送大量的SYN包,此時伺服器端會返回SYN/ACK包,因為源地址是偽造的,所以偽造的IP並不會應答,伺服器端沒有收到偽造IP的迴應,會重試3-5次並且等待一個SYN Time(一般為30秒至2分鐘),如果超時則丟棄連線。攻擊者大量傳送這種偽造源地址的SYN請求,伺服器會消耗非常多的資源來處理這種半連線。

對抗SYN flood的主要策略有SYN Cookie/SYN Proxy,safereset等演算法,SYN Cookie 主要思想是為每一個IP地址分配一個 cookie,並統計每個ip地址的訪問頻率,如果短時間收到大量的請求,則丟棄這些ip地址的包

應用層DDOS

由於發生在應用層,tcp三次握手已經完成,連線建立,發起的ip都是真實的,這種ddos逼網路層ddos更可怕
CC攻擊
CC攻擊原理非常簡單,就是對一些消耗資源較大的應用頁面不斷髮起正常的請求,以達到消耗伺服器資源的目的。在Web應用中,查詢資料庫,讀/寫硬碟檔案等操作,相對都會消耗成比較多的資源
應用層的攻擊還可以通過一下方式:黑客入侵了一個流量大的網站後,通過篡改頁面,將巨大的使用者流量分流到目標網站

<iframe src="target" width=0,height=0/>

資源耗盡攻擊

Slowloris攻擊
其原理是以極低的速度往伺服器傳送HTTP請求。由於Web Server對於併發的連線數有一定的上限,因此若是惡意地佔用住這些連線不釋放。那麼無法接收到正常的請求
實現是構造一個畸形的HTTP請求

Content-Length:42\r\n\r\n

由於WebServer只收到一個\r\n,因此將認為Http Headers部分沒有結束,並保持

優化伺服器效能的方式

  • 將使用頻率高的資料放到memcache中,將資料庫的壓力轉移到記憶體中,此外及時釋放資源
  • 在針對每個客戶端做一個請求頻率的限制(但是如果對方使用代理伺服器通過不斷變化IP地址,如果伺服器對單個IP地址的請求就無效了)
  • 在網路架構上做好優化,善於利用負載均衡,避免使用者流量集中在單臺伺服器上,同時可以充分利用好CDN和映象站點的分流作用,緩解主站的壓力
  • 驗證碼,為了識別人與機器的互動
  • 可以在Http頭中的User-Agent欄位來識別客戶端,讓客戶端解析一段JavaScript,並給出正確的執行結果等
  • 在WebServer做出一些處理,其好處在於請求尚未到達後端,在Apache的配置檔案中,有一些引數可以緩解DDOS攻擊,比如調小Timeout,KeepAliveTimeout值,增加MaxClients的值

垃圾處理

如何防範垃圾註冊和垃圾訊息,垃圾處理離不開
兩個步驟:‘識別’和‘攔截’
“批量”和“自動化”的特點意味著:

  1. 同一客戶端會多次請求同樣的URL地址
  2. 頁面與頁面直接的跳轉流程不支援
  3. 同意客戶端兩次請求時間短
  4. 客戶端的UserAgent看起來不像瀏覽器
  5. 客戶端可能無法解析JavaScript和Flash
  6. 在大多數情況下驗證碼是有效的

如果在從垃圾註冊和垃圾訊息的內容分析,發現的特點

  1. 註冊時填寫的使用者名稱可能是隨機生成的字串,而非自然語言
  2. 不同賬號的資料可能出現同樣的內容
  3. 可能含有一些敏感詞
  4. 可能出現文字變形,比如全形變半形

與業務結合,更多的特徵

  1. 如果某個使用者給多個使用者傳送訊息,但是接受者不會,這個人可能在傳送訊息
  2. 如果某個使用者加入IM群中,傳送的訊息是相同的內容,不說其他話,可能也是在傳送垃圾訊息

有了這些特徵,可以建立規則和模型