收藏本站 收藏本站
积木网首页 - 软件测试 - 常用手册 - 站长工具 - 技术社区
软件测试 > 安全测试 > 正文

首页 | 领域细分: 游戏测试 安全测试 手机测试 Web测试 | 技术研究: 单元测试 入门教程 用例设计 性能测试 功能测试 | 测试职场: 面试精选 职场发展 面试试题

测试管理: 配置及流程 - 需求管理 - 质量验收 - 缺陷管理 - 其它管理相关 | 开发语言: PHP技巧 - PHP基础 - PHP实例 - PHP错误代码

测试工具: LoadRunner JiRa QuickTestPro RoBot WinRunner TestDirector 其它测试工具 | 数据库: Mysql数据库 Oracle数据库 CSS/DIV基础 HTML基础

10大网站安全弱点基本解决方案

来源:互联网 日期:2014-09-07 11:52

  top 10网站安全弱点 基本解决方案

  作者:baiboyang,发布于2012-1-12

  A1 – Injection(注入攻擊)

  網站應用程式執行來自外部包括資料庫在內的惡意指令,SQL Injection與Command Injection等攻擊包括在內。因為駭客必須猜測管理者所撰寫的方式,因此又稱「駭客的填空遊戲」。

  舉例來說,原本管理者設計的登入頁面資料庫語法如下:

  $str = "SELECT * FROM Users WHERE Username='“.$user."' and

  Password=‘”.$pass."'“;

  如果說$user以及$pass變數沒有做保護,駭客只要輸入「’ or ‘‘=’」字串,就會變成以下:

  $str = “SELECT * FROM Users WHERE Username='' or ''='' and Password= '' or

  ‘’=‘’”;

  如此一來,這個SQL語法就會規避驗證手續,直接顯示資料。

  簡述駭客攻擊流程:

  找出未保護變數,作為注入點

  猜測完整Command並嘗試插入

  推測欄位數、Table名稱、SQL版本等資訊

  完整插入完成攻擊程序

  防護建議:

  使用Prepared Statements,例如Java PreparedStatement(),.NET SqlCommand(), OleDbCommand(),PHP PDO bindParam()

  使用Stored Procedures

  嚴密的檢查所有輸入值

  使用過濾字串函數過濾非法的字元,例如mysql_real_escape_string、addslashes

  控管錯誤訊息只有管理者可以閱讀

  控管資料庫及網站使用者帳號權限為何

  A2 – Cross Site Scripting ( XSS )(跨站腳本攻擊)

  網站應用程式直接將來自使用者的執行請求送回瀏覽器執行,使得攻擊者可擷取使用者的Cookie或Session資料而能假冒直接登入為合法使用者。

  此為目前受災最廣的攻擊。簡稱XSS攻擊。攻擊流程如下圖:

  受害者登入一個網站

  從Server端取得Cookie

  但是Server端上有著XSS攻擊,使受害者將Cookie回傳至Bad Server

  攻擊者從自己架設的Bad Server上取得受害者Cookie

  攻擊者取得控制使用受害者的身分

  防護建議:

  檢查頁面輸入數值

  輸出頁面做Encoding檢查

  使用白名單機制過濾,而不單只是黑名單

  PHP使用htmlentities過濾字串

  .NET使用Microsoft Anti-XSS Library

  OWASP Cross Site Scripting Prevention Cheat Sheet

  各種XSS攻擊的Pattern參考

  A3 – Broken Authentication and Session Management(身分驗證功能缺失)

  網站應用程式中自行撰寫的身分驗證相關功能有缺陷。例如,登入時無加密、SESSION無控管、Cookie未保護、密碼強度過弱等等。

  例如:

  應用程式SESSION Timeout沒有設定。使用者在使用公用電腦登入後卻沒有登出,只是關閉視窗。攻擊者在經過一段時間之後使用同一台電腦,卻可以直接登入。

  網站並沒有使用SSL / TLS加密,使用者在使用一般網路或者無線網路時,被攻擊者使用Sniffer竊聽取得User ID、密碼、SESSION ID等,進一步登入該帳號。

  這些都是身分驗證功能缺失的例子。

  管理者必須做以下的檢查:

  所有的密碼、Session ID、以及其他資訊都有透過加密傳輸嗎?

  憑證都有經過加密或hash保護嗎?

  驗證資訊能被猜測到或被其他弱點修改嗎?

  Session ID是否在URL中暴露出來?

  Session ID是否有Timeout機制?

  防護建議:

  使用完善的COOKIE / SESSION保護機制

  不允許外部SESSION

  登入及修改資訊頁面使用SSL加密

  設定完善的Timeout機制

  驗證密碼強度及密碼更換機制

  A4 – Insecure Direct Object References(不安全的物件參考)

  攻擊者利用網站應用程式本身的檔案讀取功能任意存取檔案或重要資料。進一步利用這個弱點分析網站原始碼、系統帳號密碼檔等資訊,進而控制整台主機。

  例如:http://example/read.php?file=../../../../../../../c:oot.ini。

  防護建議:

  避免將私密物件直接暴露給使用者

  驗證所有物件是否為正確物件

  使用Index / Hash等方法,而非直接讀取檔案

  A5 – Cross Site Request Forgery (CSRF)(跨站冒名請求)

  已登入網站應用程式的合法使用者執行到惡意的HTTP指令,但網站卻當成合法需求處理,使得惡意指令被正常執行。

  舉例來說,攻擊者在網站內放置了 ,受害者讀取到此頁面之後,就會去server.com主機執行send.asp惡意行為。

  例如Web 2.0時代的社交網站等等,都是CSRF攻擊的天堂。

  防護建議:

  確保網站內沒有任何可供XSS攻擊的弱點

  在Input欄位加上亂數產生的驗證編碼

  在能使用高權限的頁面,重新驗證使用者

  禁止使用GET參數傳遞防止快速散佈

  使用Captcha等技術驗證是否為人為操作

  或者參考OWASP所提供的CSRF Solution

  OWASP CSRFTester Project

  OWASP CSRFGuard Project

  OWASP CSRF Prevention Cheat Sheet

  A6 – Security Misconfiguration(安全性設定疏失)

  系統的安全性取決於應用程式、伺服器、平台的設定。因此所有設定值必須確保安全,避免預設帳號、密碼、路徑等。甚至被Google Hacking直接取得攻擊弱點。

本周排行

别人正在浏览

强悍的草根IT技术社区,这里应该有您想要的! 友情链接:b2b电子商务
Copyright © 2010 Gimoo.Net. All Rights Rreserved  京ICP备05050695号