<?php /* *mysql表結(jié)構(gòu)處理類 *創(chuàng)建數(shù)據(jù)表，增加，編輯，刪除表中字段 * */ classMysqlManage{ /* *table要查詢的表名 */ functioncreateTable($table){ $sql="CREATETABLEIFNOTEXISTS`$table`(`aid`INTNOTNULLprimarykey)ENGINE=InnoDB;"; M()->execute($sql); $this->checkTable($table); } /* *檢測表是否存在，也可以獲取表中所有字段的信息 *table要查詢的表名 *return表里所有字段的信息 */ functioncheckTable($table){ $sql="desc`$table`"; $info=M()->execute($sql); return$info; } /* *檢測字段是否存在，也可以獲取字段信息(只能是一個字段) *table表名 *field字段名 */ functioncheckField($table,$field){ $sql='desc`$table`$field'; $info=M()->execute($sql); return$info; } /* *添加字段 *table表名 *info字段信息數(shù)組array *return字段信息array */ functionaddField($table,$info){ $sql="altertable`$table`add"; $sql.=$this->filterFieldInfo(); M()->execute($sql); $this->checkField($table,$info['name']); } /* *修改字段 *不能修改字段名稱，只能修改 */ functioneditField($table,$info){ $sql="altertable`$table`modify"; $sql.=$this->filterFieldInfo($info); M()->execute($sql); $this->checkField($table,$info['name']); } /* *字段信息數(shù)組處理，供添加更新字段時候使用 *info[name]字段名稱 *info[type]字段類型 *info[length]字段長度 *info[isNull]是否為空 *info['default']字段默認值 *info['comment']字段備注 */ privatefunctionfilterFieldInfo($info){ if(!is_array($info)) return $newInfo=array(); $newInfo['name']=$info['name']; $newInfo['type']=$info['type']; switch($info['type']){ case'varchar': case'char': $newInfo['length']=empty($info['length'])?100:$info['length']; $newInfo['isNull']=$info['isNull']==1?'NULL':'NOTNULL'; $newInfo['default']=empty($info['default'])?'':'DEFAULT'.$info['default']; $newInfo['comment']=empty($info['comment'])?'':'COMMENT'.$info['comment']; case'int': $newInfo['length']=empty($info['length'])?7:$info['length']; $newInfo['isNull']=$info['isNull']==1?'NULL':'NOTNULL'; $newInfo['default']=empty($info['default'])?'':'DEFAULT'.$info['default']; $newInfo['comment']=empty($info['comment'])?'':'COMMENT'.$info['comment']; case'text': $newInfo['length']=''; $newInfo['isNull']=$info['isNull']==1?'NULL':'NOTNULL'; $newInfo['default']=''; $newInfo['comment']=empty($info['comment'])?'':'COMMENT'.$info['comment']; } $sql=$newInfo['name'].''.$newInfo['type']; $sql.=(!empty($newInfo['length']))?($newInfo['length'])."":''; $sql.=$newInfo['isNull'].''; $sql.=$newInfo['default']; $sql.=$newInfo['comment']; return$sql; } /* *刪除字段 *如果返回了字段信息則說明刪除失敗，返回false，則為刪除成功 */ functiondropField($table,$field){ $sql="altertable`$table`dropcolumn$field"; M()->execute($sql); $this->checkField($table,$filed); } /* *獲取指定表中指定字段的信息(多字段) */ functiongetFieldInfo($table,$field){ $info=array(); if(is_string($field)){ $this->checkField($table,$field); }else{ foreach($fieldas$v){ $info[$v]=$this->checkField($table,$v); } } return$info; } } |
好久沒有寫博客了，最近忙的要死，搞微信平臺，偶爾遇到需要模型管理，前臺表單直接修改表結(jié)構(gòu)的，就自己簡單寫了一下，也不是很難，給大家一個思路
下面我就來介紹一個可以在
linux系統(tǒng)上架設(shè)的專業(yè)的VPN產(chǎn)品，派克斯VPN，這是一款純軟件的VPN，適合各種系統(tǒng)。傳輸速度很快。管理部署都很方便。
派克斯VPN能夠?qū)崿F(xiàn)企業(yè)分部局域網(wǎng)到總部局域網(wǎng)的VPN連接，以及
移動用戶到總部局域網(wǎng)的遠程訪問。
現(xiàn)在派克斯VPN功能十分強大，支持動態(tài) DNS 功能、VPN Azure 云服務(wù)、支持OpenVPN協(xié)議、支持手機VPN連接、支持證書認證、AD認證等等。
1、首先，到網(wǎng)站下載Linux 系統(tǒng)版的派克斯VPN Server安裝包， 派克斯VPN下載he更詳細的教程：www.softether.cn
2、把下載后的文件放到linux系統(tǒng)的/use/local/目錄下。
用tar命令符來解壓縮。命令如下：
[root@machine root]# tar xzvf vpnserver-5070-rtm-linux-x86.tar.gz
vpnserver/
vpnserver/vpnserver.a
vpnserver/vpncmd.a
vpnserver/hamcore.se2
vpnserver/libcrypto.a
解壓后，會出現(xiàn)一個‘vpnserver’的文件夾，所需要的文件都在里面了。
3、然后進到該文件夾下，運行‘make’的命令：
安裝VPN Server時，需要進行叫做“make”的操作，生成vpnserver可運行文件。（如果make命令無法執(zhí)行，請安裝GCC及相關(guān)的軟件包）。
運行‘make’命令時，畫面上會出現(xiàn)‘您想閱讀本軟件的授權(quán)許可協(xié)議嗎？’的英文，在這選擇‘1’。
[root@machinevpnserver]# make ./.install.sh PacketiX VPN Software Install Utility Copyright (C) 2004-2005 SoftEther Corporation. All Rights Reserved. Do you want to read the License Agreement for this software ? 1. Yes 2. No Please choose one of above number: 1 |
然后，畫面上出現(xiàn)‘PacketiX VPN Server Version 3.0 授權(quán)許可協(xié)議’。
繼續(xù)選擇‘1’。
Did you read and understand the License Agreement ?
(If you couldn't read above text, Please read License_ReadMe.txt
file with any text editor.)
1. Yes
2. No
Please choose one of above number:
1
接下來，畫面上出現(xiàn)‘您同意授權(quán)許可協(xié)議的內(nèi)容嗎’的英文，仍然選擇‘1’。
Did you agree the License Agreement ?
1. Agree
2. Do Not Agree
Please choose one of above number:
1
即可生成vpnserver程序。這時安裝就基本完成了。
vpnserver程序的配置就算完成了。
這時就可以手動啟動PacketiX VPN服務(wù)了，在VPNserver目錄下，使用下面命令啟動:
[root@machinevpnserver]#./vpnserver start
4、如何開機自動啟動PacketiX VPN服務(wù)：
按照上述方法將vpnserver安裝到/usr/local/vpnserver/目錄后，如果要讓VPN服務(wù)隨系統(tǒng)開機啟動，需要創(chuàng)建以/usr/local/vpnserver/的名字的啟動項目。（以下只是舉例，根據(jù)您使用的系統(tǒng)，有可能需要更改一部分）。
您可以用text editor或cat 命令符來書寫下面的腳本文件。以vpnserver命名：
#!/bin/sh # chkconfig: 2345 99 01 # description: PacketiX VPN Server 3.0 DAEMON=/usr/local/vpnserver/vpnserver LOCK=/var/lock/subsys/vpnserver test -x $DAEMON || exit 0 case "$1" in start) $DAEMON start touch $LOCK ;; stop) $DAEMON stop rm $LOCK ;; restart) $DAEMON stop sleep 3 $DAEMON start ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 esac exit 0 |
然后把vpnserver腳本文件拷貝到/etc/init.d中
添加開機啟動服務(wù)，并把狀態(tài)設(shè)置為開啟：
[root@machine root]#sbin/chkconfig –add vpnserver
[root@machine root]#Sudo sysv –rc –conf vpnserver on
在啟動VPN之前，您可能還需要安裝apt-get install sysv-rc-conf和apt-get install chkconfig
此時，派克斯VPN服務(wù)就安裝好了，你可以通過命令行的方式進行配置，創(chuàng)建用戶賬戶，或者在一臺windows電腦上安裝一個管理端進行配置，進行遠程管理，圖形界面的。
然后就可以讓遠程客戶端進行連接，或者手機用戶創(chuàng)建VPN連接，用手機訪問內(nèi)網(wǎng)的資源。
派克斯VPN功能強大，管理簡單，配置方便，安全性高，使用非常穩(wěn)定。
bug這個詞，對我們來說從入行起，就形影不離。然而親密如此，你真的了解他嘛？今日我不想窮究bug的全部屬性，也不想談多少理論。我們的足跡從一場實戰(zhàn)開始。
試想，我們做了個
移動端的app，一個是啟動后，首頁，有個明顯的文字錯誤。一個是你點了十多步之后，發(fā)現(xiàn)一個邏輯錯誤（比如1+1算錯了）。如果是
測試人員會覺得哪個bug最有價值？我相信，八成的人會認為后者，為何？
1)傳統(tǒng)意義上說后者嚴重級別高；
2)發(fā)現(xiàn)步驟“復(fù)雜”顯得有技術(shù)含量；
3)有成就感被人稱為大牛。
曾幾何時，我也極力追求后者。可是一些事情本來就可遇不可求。且世間永恒的二八法則告訴我們，有些百分之二十的問題往往需要花費超過百分之八十的時間。然而很長一段時間，我依舊執(zhí)著著。因為不愿輕言放棄，不愿被他人說成知難而退……
可后來我發(fā)現(xiàn)，事實并非這樣。那些所謂的價值觀，只因我們只當我們自己是測試人員。在一次次的和用戶交流過程中。慢慢的我發(fā)現(xiàn)其實前者的價值更大：
1)用戶不是測試人員，不管你發(fā)現(xiàn)問題的步驟，只管明顯程度。
2)越是“低級”的錯誤，越容易成為用戶的笑柄，越容易成為用戶放棄你的理由。
3)真正的測試大牛不是孤芳自賞，而是換位思考。
所以，我們我們有必要重新審視一下自己關(guān)于bug的價值觀。何為有價值？出現(xiàn)頻率最高，最明顯，最能成為用戶笑柄，和競爭對手崩擊對象的就是最有價值的。再有，在測試過程中我們該如何自處？于此，我有些淺見：
1)時間有限時，深度和廣度取廣度；時間充裕時，先廣度后深度。
2)換位思考，用戶體壇至上，影響用戶體驗，用戶“
心情”的問題，最大。
3)建立量化分析體系，以數(shù)據(jù)為支撐。不斷的
學(xué)習(xí)調(diào)整用戶關(guān)心點。所謂的狠抓“痛點”
其實，這個時代，也算是
互聯(lián)網(wǎng)的大爭之世，于此。我們怎么才能凸顯價值？簡單的需求驗證，那叫做check,執(zhí)著于很深很深的問題，或許也能算個不錯的tester。但這個時代最需要的并非checker和tester而是QA。QA——質(zhì)量保證。一切以品質(zhì)為出發(fā)點。而用戶是品質(zhì)的最終裁判。就算是投其所好，是否我們也需要重新審視下曾經(jīng)的種種呢……
版權(quán)聲明：本文出自 qishaorain 的51Testing軟件測試博客：http://www.51testing.com/?15050050
原創(chuàng)作品，轉(zhuǎn)載時請務(wù)必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責(zé)任。
“數(shù)獨”（sudoku）一詞來自日語，意思是“單獨的數(shù)字”或“只出現(xiàn)一次的數(shù)字”。概括來說，它就是一種填數(shù)字游戲。但這一概念最初并非來自日本，而 是源自拉丁方塊，它是十八世紀的瑞士數(shù)學(xué)家歐拉發(fā)明的。數(shù)獨把填字游戲和棋盤游戲巧妙地結(jié)合在一起，采用填字游戲式的棋盤，解題時在空格中填上1-9的數(shù) 字。這種游戲不僅需要邏輯思維能力，還需要一點加法運算。
規(guī)則
數(shù)獨的游戲規(guī)則很簡單，9x9個格子里，已有若干數(shù)字，其它宮位留白，玩家需要自己按照邏輯推敲出剩下的空格里是什么數(shù)字，使得每一行與每一列都有1到9的數(shù)字，每個小九宮格里也有1到9的數(shù)字，并且一個數(shù)字在每個行列及每個小九宮格里都只能出現(xiàn)一次。
這次介紹的，是一個
Java版的數(shù)獨游戲?qū)崿F(xiàn)，轉(zhuǎn)載于[url]http://mcsudoku.sourceforge.net/[/url]，作者collomb,是一個基于Swing的javaSE應(yīng)用。
應(yīng)該說這是一個中規(guī)中矩的程序，既沒有別出心裁的創(chuàng)意，也沒有明顯的敗筆存在，把它作為熟悉Swing各個組件功能或者Java游戲入門的案例都可以，適合中到初級用戶
學(xué)習(xí)。
游戲界面如下：
軟件生產(chǎn)人員和用戶的最佳選擇是承認軟件不可能沒有缺陷的現(xiàn)實，在生產(chǎn)和使用中都引入軟件“容錯”的理念和機制，并把有限的時間和精力放在“關(guān)鍵”部位上，而不是一味追求最少的缺陷和不分重點地使用
軟件開發(fā)力量，這樣才能達到總體最優(yōu)的結(jié)果。
為了了解軟件質(zhì)量的現(xiàn)狀，從1994年開始，一個名叫 Standish Group 的智囊團用了十年的時間研究了多達三萬五千個開發(fā)項目，用了多種方法對這些項目進行了評估，其對于項目成功的定義如下：
軟件開發(fā)按時完成。
預(yù)算未超出。
軟件功能涵蓋了預(yù)定的要求。
軟件沒有被缺陷致殘。
軟件已被使用，而且產(chǎn)生了積極的效果。
最初的結(jié)果顯示符合上述定義的成功軟件項目只有16%。Standish 每年都會更新這一數(shù)字。之后的結(jié)果顯示，該比例沒有太大的改變。
多年來，軟件業(yè)界采用了多種方法企圖改善軟件質(zhì)量的現(xiàn)狀。雖然 Standish Group 的研究指出成功軟件的比例變化不大，卻并不代表軟件業(yè)界的努力沒有成果。
因為用戶對于軟件的要求越來越高，導(dǎo)致軟件越來越來復(fù)雜，失敗的概率也相應(yīng)地越來越大。雖然一些有識之士例如 Ben Chelf 認識到人的因素對于軟件產(chǎn)生缺陷至關(guān)重要，但是面對這一現(xiàn)實，多數(shù)還是朝著使人減少犯錯誤機會的方向去改進。這無疑是必要的。
但是在短期不能奏效的局面下，在軟件生產(chǎn)和使用中“容忍”缺陷是軟件業(yè)得以生存和發(fā)展的關(guān)鍵一環(huán)，通俗地說，要與缺陷共舞。
公司在組建
配置管理團隊（主要是項目級的配置管理員）時，通常有兩種選擇。
1）兼職項目CM。即開發(fā)人員兼任項目CM。選擇研發(fā)人員兼職的好處是項目CM了解項目進展和研發(fā)流程，能夠與項目經(jīng)理等一起合作，溝通無障礙。缺點是研發(fā)人員以開發(fā)任務(wù)為主，
工作量大時可能難以兼顧配管工作，易導(dǎo)致配管工作延遲。這個方案的另外一個缺點是兼職配管的人員流動性大，項目內(nèi)任務(wù)的調(diào)配，人員離職等都會造成配管更換的問題。從就職資格的角度來說。每位新任的配管都需要經(jīng)過培訓(xùn)。這就加大了培訓(xùn)的難度。盡管，硬幣的另一面是更多的開發(fā)人員接受了較為正式的配管培訓(xùn)。
2）專職項目配管。比如一條產(chǎn)品線設(shè)一個專職配管，負責(zé)該產(chǎn)品線下所有項目的配管工作。這種做法有利于配管人員的專業(yè)化發(fā)展，長期對公司來說也是有利的。但是這種模式的前提是公司的配置管理體系已經(jīng)較為完善，對于項目配管的工作流程比較清楚，權(quán)責(zé)界定也較為明確。對于新加入的項目配管，企業(yè)能夠很快通過培訓(xùn)讓其上崗。確保公司的配管流程正常運轉(zhuǎn)。
有人可能會問，第二種方案顯然比第一種好，第一種方案還有存在必要嗎？問題是現(xiàn)在很多企業(yè)在面臨管理問題時，由于一些原因不能給足夠的資金購買商業(yè)軟件，也不會招聘正式的專職人員（這兩點是企業(yè)配置管理三大誤區(qū)中的兩點）。背后的深層次根源還是對配管工作沒有引起足夠的重視。在領(lǐng)導(dǎo)還未能對配管引起足夠重視的前提下，第一種方案就成了曲線救國的辦法。至少解決了有無問題。慢慢的研發(fā)人員就會開始抱怨，任務(wù)重，事情雜。第二種方案也就順理成章地成為領(lǐng)導(dǎo)自主自發(fā)的要求。
此外，配置管理團隊（這里主要指組織級配置管理工程師）的定位和匯報機制也比較關(guān)鍵。由于該崗位與研發(fā)關(guān)系密切，最好是歸屬研發(fā)部門或
項目管理部。向研發(fā)部經(jīng)理或項目管理部的leader匯報。必須獲得對配管工作的完全授權(quán)，避免出現(xiàn)研發(fā)部不認可、不配合的情況，甚至無法觸及研發(fā)流程和數(shù)據(jù)的問題（聽起來奇怪，但你見多了國內(nèi)企業(yè)的亂象就會理解什么叫”見怪不怪”）。
MantisBT介紹:
是一個缺陷跟蹤系統(tǒng)具有多特性包括：易于安裝，易于操作，基于
Web，支持任何可運行PHP的平臺(
Windows,Linux,Mac,Solaris,AS400/i5等)，已經(jīng)被翻譯成68種語言，支持多個項目，為每一個項目設(shè)置不同的用戶訪問級別，跟蹤缺陷變更歷史，定制我的視圖頁面，提供全文搜索功能，內(nèi)置報表生成功能(包括圖形報表)， 通過Email報告缺陷，用戶可以監(jiān)視特殊的
Bug，附件可以保存在web服務(wù)器上或
數(shù)據(jù)庫中(還可以備份到FTP服務(wù)器上)，自定義缺陷處理
工作流，支持輸出格包括csv、Microsoft Excel、 Microsoft Word，集成源代碼控制(SVN與CVS )，集成wiki知識庫與聊天工具(可選/可不選)，支持多種數(shù)據(jù)庫(
MySQL、MSSQL、 PostgreSQ、
Oracle、DB2)，提供WebService(SOAP)接口，提供Wap訪問。
MantisBT基本特性:
個人可定制的Email通知功能，每個用戶可根據(jù)自身的工作特點只訂閱相關(guān)缺陷狀態(tài)郵件；
支持多項目、多語言；
權(quán)限設(shè)置靈活，不同角色有不同權(quán)限，每個項目可設(shè)為公開或私有狀態(tài)，每個缺陷可設(shè)為公開或私有狀態(tài)，每個缺陷可以在不同項目間
移動；
主頁可發(fā)布項目相關(guān)新聞，方便信息傳播；
方便的缺陷關(guān)聯(lián)功能，除重復(fù)缺陷外，每個缺陷都可以鏈接到其他相關(guān)缺陷；
缺陷報告可打印或輸出為CSV格式：支持可定制的報表輸出，可定制用戶輸入域；
有各種缺陷趨勢圖和柱狀圖，為項目狀態(tài)分析提供依據(jù)，如果不能滿足要求，可以把數(shù)據(jù)輸出到Excel中進一步分析；
流程定制不夠方便，但該流程可滿足一般的缺陷跟蹤；
可以實現(xiàn)與CVS集成：缺陷和CVS倉庫中文件實現(xiàn)關(guān)聯(lián)；
可以對歷史缺陷進行檢索。
平時
工作，多數(shù)是開發(fā)Web項目，由于一般是開發(fā)內(nèi)部使用的業(yè)務(wù)系統(tǒng)，所以對于安全性一般不是看的很重，基本上由于是內(nèi)網(wǎng)系統(tǒng)，一般也很少會受到攻擊，但有時候一些系統(tǒng)平臺，需要外網(wǎng)也要使用，這種情況下，各方面的安全性就要求比較高了，所以往往會交付給一些專門做
安全測試的第三方機構(gòu)進行測試，然后根據(jù)反饋的
漏洞進行修復(fù)，如果你平常對于一些安全漏洞不夠了解，那么反饋的結(jié)果往往是很殘酷的，迫使你必須在很多細節(jié)上進行修復(fù)完善。本文主要根據(jù)本人項目的一些第三方安全測試結(jié)果，以及本人針對這些漏洞問題的修復(fù)方案，介紹在這方面的一些經(jīng)驗，希望對大家有幫助。
基本上，參加的安全測試（滲透測試）的網(wǎng)站，可能或多或少存在下面幾個漏洞：
SQL注入漏洞、跨站腳本攻擊漏洞、登陸后臺管理頁面、IIS短文件/文件夾漏洞、系統(tǒng)敏感信息泄露。
1、測試的步驟及內(nèi)容
這些安全性測試，據(jù)了解一般是先收集數(shù)據(jù)，然后進行相關(guān)的滲透測試工作，獲取到網(wǎng)站或者系統(tǒng)的一些敏感數(shù)據(jù)，從而可能達到控制或者破壞系統(tǒng)的目的。
第一步是信息收集，收集如IP地址、DNS記錄、軟件版本信息、IP段等信息。可以采用方法有：
1）基本網(wǎng)絡(luò)信息獲取；
2）Ping目標網(wǎng)絡(luò)得到IP地址和TTL等信息；
3）Tcptraceroute和Traceroute 的結(jié)果；
4）Whois結(jié)果；
5）Netcraft獲取目標可能存在的域名、Web及服務(wù)器信息；
6）Curl獲取目標Web基本信息；
8）
Google、Yahoo、Baidu等搜索引擎獲取目標信息；
9）FWtester 、Hping3 等工具進行防火墻規(guī)則探測；
10）其他。
第二步是進行滲透測試，根據(jù)前面獲取到的數(shù)據(jù)，進一步獲取網(wǎng)站敏感數(shù)據(jù)。此階段如果成功的話，可能獲得普通權(quán)限。采用方法會有有下面幾種：
1）常規(guī)漏洞掃描和采用商用軟件進行檢查；
2）結(jié)合使用ISS與Nessus等商用或免費的掃描工具進行漏洞掃描；
3）采用SolarWinds對網(wǎng)絡(luò)設(shè)備等進行搜索發(fā)現(xiàn)；
4）采用Nikto、Webinspect等軟件對Web常見漏洞進行掃描；
6）對Web和數(shù)據(jù)庫應(yīng)用進行分析；
7）采用WebProxy、SPIKEProxy、Webscarab、ParosProxy、Absinthe等工具進行分析；
8）用Ethereal抓包協(xié)助分析；
9）用Webscan、Fuzzer進行SQL注入和XSS漏洞初步分析；
10）手工檢測SQL注入和XSS漏洞；
11）采用類似OScanner的工具對數(shù)據(jù)庫進行分析；
12）基于通用設(shè)備、數(shù)據(jù)庫、操作系統(tǒng)和應(yīng)用的攻擊；采用各種公開及私有的緩沖區(qū)溢出程序代碼，也采用諸如MetasploitFramework 之類的利用程序集合。
13）基于應(yīng)用的攻擊。基于Web、數(shù)據(jù)庫或特定的B/S或C/S結(jié)構(gòu)的網(wǎng)絡(luò)應(yīng)用程序存在的弱點進行攻擊。
14）口令猜解技術(shù)。進行口令猜解可以采用 X-Scan、Brutus、Hydra、溯雪等工具。
第三步就是嘗試由普通權(quán)限提升為管理員權(quán)限，獲得對系統(tǒng)的完全控制權(quán)。在時間許可的情況下，必要時從第一階段重新進行。采用方法
1）口令嗅探與鍵盤記錄。嗅探、鍵盤記錄、木馬等軟件，功能簡單，但要求不被防病毒軟件發(fā)覺，因此通常需要自行開發(fā)或修改。
2）口令破解。有許多著名的口令破解軟件，如 L0phtCrack、John the Ripper、Cain 等。
以上一些是他們測試的步驟，不過我們不一定要關(guān)注這些過程性的東西，我們可能對他們反饋的結(jié)果更關(guān)注，因為可能會爆發(fā)很多安全漏洞等著我們?nèi)バ迯?fù)的。
2、SQL注入漏洞的出現(xiàn)和修復(fù)
1）SQL注入定義：
SQL注入攻擊是黑客對數(shù)據(jù)庫進行攻擊的常用手段之一。隨著B/S模式應(yīng)用開發(fā)的發(fā)展，使用這種模式編寫應(yīng)用程序的程序員也越來越多。但是由于程序員的水平及經(jīng)驗也參差不齊，相當大一部分程序員在編寫代碼的時候，沒有對用戶輸入數(shù)據(jù)的合法性進行判斷，使應(yīng)用程序存在安全隱患。用戶可以提交一段數(shù)據(jù)庫查詢代碼，根據(jù)程序返回的結(jié)果，獲得某些他想得知的數(shù)據(jù)，這就是所謂的SQL Injection，即SQL注入。
SQL注入有時候，在地址參數(shù)輸入，或者控件輸入都有可能進行。如在鏈接后加入’號，頁面報錯，并暴露出網(wǎng)站的物理路徑在很多時候，很常見，當然如果關(guān)閉了Web.Config的CustomErrors的時候，可能就不會看到。
另外，Sql注入是很常見的一個攻擊，因此，如果對頁面參數(shù)的轉(zhuǎn)換或者沒有經(jīng)過處理，直接把數(shù)據(jù)丟給Sql語句去執(zhí)行，那么可能就會暴露敏感的信息給對方了。如下面兩個頁面可能就會被添加注入攻擊：
①HTTP://xxx.xxx.xxx/abc.asp?p=YY and (select top 1 name from TestD ... type='U' and status>0)>0 得到第一個用戶建立表的名稱，并與整數(shù)進行比較，顯然abc.asp工作異常，但在異常中卻可以發(fā)現(xiàn)表的名稱。假設(shè)發(fā)現(xiàn)的表名是xyz，則
②HTTP://xxx.xxx.xxx/abc.asp?p=YY and (select top 1 name from TestDB.dbo.sysobjects& ... tatus>0 and name not in('xyz'))>0 可以得到第二個用戶建立的表的名稱，同理就可得到所有用建立的表的名稱。
為了屏蔽危險Sql語句的執(zhí)行，可能需要對進行嚴格的轉(zhuǎn)換，例如如果是整形的，就嚴格把它轉(zhuǎn)換為整數(shù)，然后在操作，這樣可以避免一些潛在的危險，另外對構(gòu)造的sql語句必須進行Sql注入語句的過濾，如我的框架（Winform開發(fā)框架、Web開發(fā)框架等）里面就內(nèi)置了對這些有害的語句和符號進行清除工作，由于是在基類進行了過濾，因此基本上子類都不用關(guān)心也可以避免了這些常規(guī)的攻擊了。
/// <summary> /// 驗證是否存在注入代碼(條件語句） /// </summary> /// <param name="inputData"></param> public bool HasInjectionData(string inputData) { if (string.IsNullOrEmpty(inputData)) return false; //里面定義惡意字符集合 //驗證inputData是否包含惡意集合 if (Regex.IsMatch(inputData.ToLower(), GetRegexString())) { return true; } else { return false; } } /// <summary> /// 獲取正則表達式 /// </summary> /// <returns></returns> private static string GetRegexString() { //構(gòu)造SQL的注入關(guān)鍵字符 string[] strBadChar = { //"select\\s", //"from\\s", "insert\\s", "delete\\s", "update\\s", "drop\\s", "truncate\\s", "exec\\s", "count\\(", "declare\\s", "asc\\(", "mid\\(", "char\\(", "net user", "xp_cmdshell", "/add\\s", "exec master.dbo.xp_cmdshell", "net localgroup administrators" }; //構(gòu)造正則表達式 string str_Regex = ".*("; for (int i = 0; i < strBadChar.Length - 1; i++) { str_Regex += strBadChar[i] + "|"; } str_Regex += strBadChar[strBadChar.Length - 1] + ").*"; return str_Regex; } |
上面的語句用于判別常規(guī)的Sql攻擊字符，我在數(shù)據(jù)庫操作的基類里面，只需要判別即可，如下面的一個根據(jù)條件語句查找數(shù)據(jù)庫記錄的函數(shù)。
/// <summary> /// 根據(jù)條件查詢數(shù)據(jù)庫,并返回對象集合 /// </summary> /// <param name="condition">查詢的條件</param> /// <param name="orderBy">自定義排序語句，如Order By Name Desc；如不指定，則使用默認排序</param> /// <param name="paramList">參數(shù)列表</param> /// <returns>指定對象的集合</returns> public virtual List<T> Find(string condition, string orderBy, IDbDataParameter[] paramList) { if (HasInjectionData(condition)) { LogTextHelper.Error(string.Format("檢測出SQL注入的惡意數(shù)據(jù), {0}", condition)); throw new Exception("檢測出SQL注入的惡意數(shù)據(jù)"); } ........................... } |
以上只是防止Sql攻擊的一個方面，還有就是堅持使用參數(shù)化的方式進行賦值，這樣很大程度上減少可能受到SQL注入攻擊。
3、跨站腳本攻擊漏洞出現(xiàn)和修復(fù)
跨站腳本攻擊，又稱XSS代碼攻擊，也是一種常見的腳本注入攻擊。例如在下面的界面上，很多輸入框是可以隨意輸入內(nèi)容的，特別是一些文本編輯框里面，可以輸入例如<script>alert('這是一個頁面彈出警告');</script>這樣的內(nèi)容，如果在一些首頁出現(xiàn)很多這樣內(nèi)容，而又不經(jīng)過處理，那么頁面就不斷的彈框，更有甚者，在里面執(zhí)行一個無限循環(huán)的腳本函數(shù)，直到頁面耗盡資源為止，類似這樣的攻擊都是很常見的，所以我們?nèi)绻窃谕饩W(wǎng)或者很有危險的網(wǎng)絡(luò)上發(fā)布程序，一般都需要對這些問題進行修復(fù)。
XSS代碼攻擊還可能會竊取或操縱客戶會話和 Cookie，它們可能用于模仿合法用戶，從而使黑客能夠以該用戶身份查看或變更用戶記錄以及執(zhí)行事務(wù)。[建議措施]清理用戶輸入，并過濾出 JavaScript 代碼。我們建議您過濾下列字符：
[1] <>（尖括號）
[2] "（引號）
[3] '（單引號）
[4] %（百分比符號）
[5] ;（分號）
[6] ()（括號）
[7] &（& 符號）
[8] +（加號）
為了避免上述的XSS代碼攻擊，解決辦法是可以使用HttpUitility的HtmlEncode或者最好使用微軟發(fā)布的AntiXSSLibrary進行處理，這個更安全。
微軟反跨站腳本庫（AntiXSSLibrary）是一種編碼庫，旨在幫助保護開發(fā)人員保護他們的基于Web的應(yīng)用不被XSS攻擊。
例如上面的內(nèi)容，賦值給一個Lable控件，不會出現(xiàn)彈框的操作。
但是，我們雖然顯示的時候設(shè)置了轉(zhuǎn)義，輸入如果要限制它們怎么辦呢，也是使用AntiXSSLibrary里面的HtmlSanitizationLibrary類庫Sanitizer.GetSafeHtmlFragment即可。
protected void btnPost_Click(object sender, EventArgs e)
{
this.lblName.Text = Sanitizer.GetSafeHtmlFragment(txtName.Text);
}
這樣對于特殊腳本的內(nèi)容，會自動剔除過濾，而不會記錄了，從而達到我們想要的目的。
Database db = CreateDatabase();
DbCommand command = db.GetSqlStringCommand(sql);
command.Parameters.AddRange(param);
4、IIS短文件/文件夾漏洞出現(xiàn)和修復(fù)
通過猜解，可能會得出一些重要的網(wǎng)頁文件地址，如可能在/Pages/Security/下存在UserList.aspx和MenuList.aspx文件。
[建議措施]
1）禁止url中使用“~”或它的Unicode編碼。
2）關(guān)閉windows的8.3格式功能。
修復(fù)可以參考下面的做法，或者找相關(guān)運維部門進行處理即可。
http://sebug.net/vuldb/ssvid-60252
http://webscan.360.cn/vul/view/vulid/1020
http://www.bitscn.com/network/security/200607/36285.html
5、系統(tǒng)敏感信息泄露出現(xiàn)和修復(fù)
如果頁面繼承一般的page，而沒有進行Session判斷，那么可能會被攻擊者獲取到頁面地址，進而獲取到例如用戶名等重要數(shù)據(jù)的。
一般避免這種方式是對于一些需要登錄才能訪問到的頁面，一定要進行Session判斷，可能很容易給漏掉了。如我在Web框架里面，就是繼承一個BasePage，BasePage 統(tǒng)一對頁面進行一個登錄判斷。
public partial class UserList : BasePage { protected void Page_Load(object sender, EventArgs e) { ............... /// <summary> /// BasePage 集成自權(quán)限基礎(chǔ)抽象類FPage，其他頁面則集成自BasePage /// </summary> public class BasePage : FPage { /// <summary> /// 默認構(gòu)造函數(shù) /// </summary> public BasePage() { this.IsFunctionControl = true;//默認頁面啟動權(quán)限認證 } /// <summary> /// 檢查用戶是否登錄 /// </summary> private void CheckLogin() { if (string.IsNullOrEmpty(Permission.Identity)) { string url = string.Format("{0}/Pages/CommonPage/Login.aspx?userRequest={1}", Request.ApplicationPath.TrimEnd('/'), HttpUtility.UrlEncode(Request.Url.ToString())); Response.Redirect(url); } } /// <summary> /// 覆蓋HasFunction方法以使權(quán)限類判斷是否具有某功能點的權(quán)限 /// </summary> /// <param name="functionId"></param> /// <returns></returns> protected override bool HasFunction(string functionId) { CheckLogin(); bool breturn = false; try { breturn = Permission.HasFunction(functionId); } catch (Exception) { Helper.Alerts(this, "BasePage調(diào)用權(quán)限系統(tǒng)的HasFunction函數(shù)出錯"); } return breturn; } protected override void OnInit(EventArgs e) { Response.Cache.SetNoStore(); //清除緩存 base.OnInit(e); CheckLogin(); } |
否則可能會受到攻擊，并通過抓包軟件發(fā)現(xiàn)頁面數(shù)據(jù)，獲得一些重要的用戶名或者相關(guān)信息。
還有一個值得注意的地方，就是一般這種不是很安全的網(wǎng)絡(luò)，最好要求輸入比較復(fù)雜一點的密碼（強制要求），例如不能全部是數(shù)字密碼或者不能是純字符，對位數(shù)也要求多一點，因為很多人輸入12345678,123456，123這樣的密碼，很容易被猜出來并登錄系統(tǒng)，造成不必要的損失。
6、總結(jié)性建議
針對上面發(fā)現(xiàn)的問題，提出下面幾條建議。
1）在服務(wù)器與網(wǎng)絡(luò)的接口處配置防火墻，用于阻斷外界用戶對服務(wù)器的掃描和探測。
2）限制網(wǎng)站后臺訪問權(quán)限，如：禁止公網(wǎng)IP訪問后臺；禁止服務(wù)員使用弱口令。
3）對用戶輸入的數(shù)據(jù)進行全面安全檢查或過濾，尤其注意檢查是否包含SQL 或XSS特殊字符。這些檢查或過濾必須在服務(wù)器端完成。
4）關(guān)閉windows的8.3格式功能。
5）限制敏感頁面或目錄的訪問權(quán)限。
介紹在Spring的框架下，做
單元測試的兩種辦法。
除了junit4和spring的jar包，還需要spring-test.jar。引入如下依賴：
<span style="font-size:18px;"><span style="white-space:pre"> </span><dependency> <groupId>org.springframework</groupId> <artifactId>spring-test</artifactId> <version>3.1.1.RELEASE</version> </dependency></span> |
然后測試類需要繼承自AbstractJUnit4SpringContextTests，這樣就可以在測試類中使用注解簡單的注入需要的bean了。
<span style="font-size:18px;"><span style="color:#ff0000;">@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration({"classpath:applicationContext.xml"})</span> public class ReadDaoImplTest extends<span style="color:#ff0000;"> AbstractJUnit4SpringContextTests</span>{ @Resource ReadDao readDao; @Test public void getListTest(){ List<Client> clientList = readDao.getList("client.test", null); for(Client c:clientList){ System.out.println(c.getVersionNum()); } } } </span> |
二、手動加載spring的配置文件，并啟動spring容器
public class ReadDaoImplTest { public static void main(String[] args){ ClassPathXmlApplicationContext context = <span style="color:#ff0000;">new ClassPathXmlApplicationContext("applicationContext.xml");</span> context.start(); ReadDao fqaService = (ReadDao) context.getBean("readDao"); System.out.println(fqaService); } } |
用這種方式測試，只需要Ctrl+F11就行了
Chris Zetter是FutureLearn產(chǎn)品組的一名開發(fā)者，他為我們講述了自己的小組為了使
功能測試兼具可維護性與可讀性，在把Cucumber替換為RSpec之后是如何來編寫測試的。
測試是建立與維護一個大型平臺不可或缺的一部分。每當我們?yōu)镕utureLearn這個平臺增添新功能時，我們都會編寫自動化的功能測試來記錄這些新功能是如何運作的，并確保他們不運轉(zhuǎn)時我們也能知曉。
令人愛恨交加的Cucumber
Cucumber是一款用來編寫功能測試的常用工具，每當我們開啟項目時它都是我們的不二選擇。它可以讓我們以用戶的視角編寫出高層級的行為驅(qū)動測試。
Feature: Enrolment Scenario: Enrolling in a course Given there is a course And I am logged in as a learner When I enrol on a course Then the course should appear in 'my courses' |
我們樂于使用Cucumber因為它可以使根據(jù)用戶故事編寫測試變得簡單易行，而且寫完的測試通俗易懂。然而使用Cucumber也有些許不足之處。首先，我們已經(jīng)在項目里使用了RSpec，再引入Cucumber意味著又要多維護一個測試框架；其次，由于兩者的DSLs和測試運行器不同，在他們之間進行腦筋切換又會帶來額外開銷；最后，我們特別不喜歡Cucumber所使用的正則表達式，因為同
Ruby的標準方法調(diào)用相比，它們使測試變得更加晦澀難懂。
編寫更好的RSpec features
那么，我么該如何在不失測試可讀性的前提下停用Cucumber呢？
我們已經(jīng)開始使用RSpec features來替代Cucumber，它們通常看起來會是這樣：
feature 'Enrolment' do scenario 'Enrolling in a course' do course = FactoryGirl.create(:course) learner = FactoryGirl.create(:learner) login_as learner visit course_path(course) find('.join').click expect(page).to have_content('Thanks for joining!') visit '/' expect(page).to have_main_header('My Courses') expect(page).to have_content(course.full_title) end end |
它們總是趨于變得很長，使得難以辨明其究竟在測試些什么。而且難以區(qū)分諸如Arrange, Act, Assert（在Cucumber里又被稱為’Given’、’When’和’Then’）這些部分。我們試過在代碼中這些步驟里添加注釋，但它們就和通常那些程序代碼里的注釋一樣不盡如人意：一段時間之后這些注釋就變得與實際代碼不同步了。
一般來說，如果是在程序里別的地方寫出這么長的方法，我們就會有所警覺，并且通常會采用提取方法的辦法進行重構(gòu)。何不也這么做呢？讓我們依據(jù)Cucumber步驟的風(fēng)格，把這些代碼也提取成一個個方法吧。
feature 'Enrolment' do scenario 'Enrolling in a course' do given_there_is_a_course and_i_am_logged_in_as_a_learner when_i_enrol_on_a_course then_the_course_should_appear_in_my_courses end def given_there_is_a_course @course = FactoryGirl.create(:course) end def and_i_am_logged_in_as_a_learner @learner = FactoryGirl.create(:learner) login_as @learner end def when_i_enrol_on_a_course visit course_path(@course) find('.join').click expect(page).to have_content('Thanks for joining!') end def then_the_course_should_appear_in_my_courses visit '/' expect(page).to have_main_header('My Courses') expect(page).to have_content(@course.full_title) end end |
我們有何發(fā)現(xiàn)
我們移除了全部的Cucumber功能測試，并把它們中大部分用新式的RSpec features加以重寫。這樣一來即可保證擁有Cucumber所提供的優(yōu)秀的可讀性，又使得測試變得更加便于編寫和維護。
我們做了一個慎重的決定，不把各個features文件里提取的方法進行復(fù)用，因為擔(dān)心這么做會使得測試難于理解。我們發(fā)現(xiàn)在編寫一個feature下的多條scenario時，會不自覺的就想要進行代碼復(fù)用。