Browsing: WAF

    相信對於有建立網站提供對外服務的公司來說,如何強化網站的防護一直都是重要的課題,除了基本的防火牆、定期更新和維護、安全漏洞掃描,有些公司也會額外採購 WAF(Web Application Firewall),以強化網站在 SQL injection,XSS 攻擊的額外保護。 但是如果要防止爬蟲或是使用機器人與自動化程式進行的惡意行為,就需要使用人機辨識對連線來源作區分,分辨合理連線,並只允許合法使用者進行操作。 在網站上使用的人機辨識為 CAPTCHA(Completely Automated Public Turing test to tell Computers and Humans Apart),中文翻譯為「全自動區分計算機與人類的圖靈測試」,…

    作為一個雲服務供應商嘅技術支援人員,平時都收到唔少企業客戶投訴,問點解搬咗啲嘢上我哋嚿雲之後,竟然仲俾人入侵到去佢個 database?其實而宜好多企業管理者都以為將虛擬機、應用服務或數據搬上雲,我哋就會幫你守穩大門,唔會俾黑客入侵,但其實條款一早已寫明係「共同責任」模式(Shared Responsibility Model)嚟㗎! 呢個謬誤其實相當普遍,一來個客未必理解雲端服務嘅運作原理,二來幫襯時亦可能遊咗魂無聽清楚我哋提供嘅保障內容。事實上,公司一早已喺服務條款內寫明,只會確保提供嘅基礎架構、服務嘅安全性,而客戶必須負責自己嘅數據防護。 咁樣做絕對唔係「卸膊」,而係因為幫襯嘅客來自各行各業,採用嘅應用方案亦五花百門,試問我哋點可以一個 settings 招呼晒所有客呢?以 Web Application Firewall 為例,e-commerce 平台同一般企業客戶嘅設定已好唔同,前者要考慮準確過濾惡意連線之餘而唔會擋埋正常顧客,後者基本上就只會俾員工訪問數據庫,所以只可以留返俾客戶自己搞。仲有嘅係如果企業員工嘅安全意識不足,唔小心中咗釣魚電郵俾黑客攞到登入帳戶權限(最新鮮例子係 Twitter),雲供應商又點擋到呢啲表面上屬於合法登入嘅入侵? 另一方面,Web Application 同背後用到嘅 API 絕對係對外開放,而最終目的地自然係客戶嘅數據庫,莫講話我哋照顧唔到各企業採用嘅工具同設定,就算係企業自己,亦會因工具同工具之間嘅數據無法溝通,而掌握唔到出入嘅數據有無可疑,試問我哋又點樣幫你守穩門口呢?講出嚟你都唔應該信啦! 所以話,企業喺採用雲端服務嘅時候,態度亦要好似管理傳統…