Web安全專家訪談

Web安全專家訪談

作者:Rob Kenworthy(羅布·肯沃)

翻譯:紫郢劍俠,2015-09-28第1版

 

  Web安全專家謝里夫·庫薩(Sherif Koussa)的觀點可能會改變你對web應用程序安全性的許多想法。


  大多數開發人員可能都知道一些安全常識,他們天真地認爲憑這些就足以保障自己開發的應用程序安全。直到大約一年前我還不願承認這一點。除非開放Web應用安全項目(Open Web Application Security Project,OWASP),跨站腳本(Cross-site Scripting),注入(Injection),緩解因素(Mitigating Factors),動態和靜態代碼分析(Dynamic and Static Code Analysis)和滲透測試(Penetration Testing)等諸如此類的術語經常從你的嘴裏冒出來,你可能也不願承認。
  在近期的網絡安全話題中,黑客醜聞甚囂塵上,其中就包括Impact Team的黑客,他們竊取了AshleyMadison.com的數據並在互聯網上發佈。在剛剛過去的這個星期裏,我獲得了與我的同事、網絡安全專家謝里夫·庫薩交流的機會。謝里夫從事安全業務已有8年,爲富國銀行(Wells Fargo),德信銀行(Desjardins),卡爾頓大學(Carleton University),發現(Discover)這樣的大客戶和大量加拿大政府客戶提供服務。他也是GIAC的GSSP-JAVA和GSSP-NET考試指導委員會的一員。此外,謝里夫曾撰寫過一些SANS課程和GIAC考試的課件。如果這些仍然不夠份量,謝里夫還領導着OWASP的渥太華分會,並且是OWASP的WebGoat5.0的主力。換句話說,當謝里夫會談論安全時,我需要聚精會神地傾聽......你也應該這麼做。爲此,我將我們的交流對話整理發表出來,以便其他人可以從中受益。
  
最常見的攻擊是什麼?
  這實際上取決於你看問題的角度。從應用程序安全的角度來看,OWASP漏洞列表top 10似乎仍是我們在不同應用程序中發現的漏洞的真實反映。與.NET之類的其它語言平臺不同,SQL注入和命令注入攻擊,特別是跨站點腳本注入攻擊,對Java應用程序影響很少,這是因爲Java平臺不像.NET或Ruby-on-Rails那樣自動支持其他平臺。
  換一個角度來看,惡意軟件似乎是一個日益危險和日益複雜化的問題。攻擊者使用常見的方式來投遞惡意軟件載體,如電子郵件附件,電子郵件中的鏈接,遊戲等,而這些載體通常攻擊那些尚未修補的知名漏洞或沒有可用補丁的零日漏洞。
  
是不是任何一個語言/平臺都有軟肋?
  是的,有些平臺提供了更多的開即用的安全保護和功能。新平臺似乎比舊的好。例如,node.js提供的堆棧似乎超過了Ruby on Rails,Ruby on Rails的似乎超過了.NET,.NET的似乎又超過了Java等。但這並不是真正的優勢,因爲總有辦法來關閉這些功能,或者繞過這些限制。因此,更進一步來看,.NET附帶了一些防止跨站點腳本的開即用保護。這項保護不是很大,卻足以讓一些跨站點腳本攻擊源失效,但我們看到許多開發者禁用這項保護,因爲它打亂了他們的一些特性。另外一個例子,.NET提供了一個非常簡單的CSRF緩解功能,但沒有吸引到多少開發者來使用。即使在Java中,PreparedStatement使用非常普遍,99%的開發者都在用,但你猜怎麼着,攻擊者會發現使用串連接語句而不PreparedStatement的那1%,並充分利用這一點,訪問未經授權的敏感信息,甚至危及整個網絡。請記住,防禦者始終處於劣勢。因爲防禦者必須解決所有的漏洞,而攻擊者只需要一個漏洞。當開發者知道他們正在保護什麼,爲此需要做些什麼,什麼平臺提供了與此相關的開即用功能,以及需要做什麼來彌補差距時,開發者們開始具有優勢。這結合對攻擊者的方法和思維方式的瞭解,如此他們才能奪回優勢,並掌控他們的應用程序和數據,而不是被控制。
  你對沒有應用安全專家的IT企業有什麼建議?
  雖然不是所有的IT企業都擁有內部應用程序的安全專業知識,這並不意味着他們不能編寫安全的應用程序。安全的代碼可以與高質量代碼媲美。要發佈沒有錯誤的高質量代碼,你不僅必須擁有可以編寫出好代碼的開發人員,而且必須擁有好的質量保證工程師來測試代碼,或一個真正堅實廣泛的測試用例集,而不僅僅只是編寫和發佈代碼。你不能只依賴於質量保證工程師來發現一切。這同樣適用於安全性。軟件開發人員必須編寫安全的代碼 - 使用預備語句,過濾器,並淨化用戶輸入等。然後由應用程序安全專家來查缺補漏。安全專家的作用是找出那些漏網的漏洞或測試應用程序對最新出現的威脅和攻擊的防禦能力。爲了營造內部穩固的安全實踐,企業應該從提高安全攻擊和企業風險意識開始。隨後,遵循下列這些簡單的步驟:
  1.爲SDLC(Systems Development Life Cycle 系統開發生命週期 或 Software Development Life Cycle軟件開發生命週期) 增加低維護成本的安全接觸點,例如安全設計審查,可以是輕量級的安全檢查列表或安全特性靜態代碼分析工具。
  2.逐步地提高安全漏洞的門檻,這可以通過自定義安全準則或公司的常規代碼審查來實現。
  3.Appointing someone as a security champion for people to ask questions helped a lot of organizations.
  3.將提出的問題對組織幫助很大的人任命爲安全捍衛者(security champion)。
  這些都只是一些例子,企業組織不需要額外招聘工作人員或預算撥款就能實施。當然,具體措施取決於每個組織當前的進展以及目標。
  
在做好諮詢工作之餘,你還從事其他研究嗎?
  我們目前正在研究的工作中有一個很酷的東西,是一個幫助企業對使用不同開源組件和庫帶來的風險進行比較的工具。如果你要選擇一個新的開放源代碼段,它也可以幫助你選出最安全的軟件,讓你瞭解其中的風險來自何處,最終如何處理它。
  
最後,你可以描述一下作爲一名安全顧問,一天的生活通常是怎麼樣呢?
  作一名安全顧問的樂趣和挑戰之一是各種各樣的工作。大多數客戶要求做評估工作,但他們都有不同的技術數據(即不同的基礎架構,編程語言,框架,網絡與手機等)。評估工作通常包括安全代碼審查(其中包括靜態代碼分析和手工代碼審查)和動態評估(包括漏洞掃描和滲透測試)。除了評估工作,我還進行了自己的安全研究,創建和更新培訓材料,當然也發表這些培訓材料。
  英文來源:
https://dzone.com/articles/web-security-interview-with-an-expert

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章