ThinkPHP 數據庫表結構處理類(簡單實用)

posted @ 2014-08-29 09:49 順其自然EVO 閱讀(474) | 評論 (0) | 編輯 收藏

Linux搭建VPN服務器

posted @ 2014-08-29 09:49 順其自然EVO 閱讀(213) | 評論 (0) | 編輯 收藏

淺談測試管理—bug的含義知多少？

posted @ 2014-08-29 09:48 順其自然EVO 閱讀(244) | 評論 (0) | 編輯 收藏

Java桌面游戲巡禮—Java數獨

“數獨”（sudoku）一詞來自日語，意思是“單獨的數字”或“只出現一次的數字”。概括來說，它就是一種填數字游戲。但這一概念最初并非來自日本，而 是源自拉丁方塊，它是十八世紀的瑞士數學家歐拉發明的。數獨把填字游戲和棋盤游戲巧妙地結合在一起，采用填字游戲式的棋盤，解題時在空格中填上1-9的數 字。這種游戲不僅需要邏輯思維能力，還需要一點加法運算。

　　規則

　　數獨的游戲規則很簡單，9x9個格子里，已有若干數字，其它宮位留白，玩家需要自己按照邏輯推敲出剩下的空格里是什么數字，使得每一行與每一列都有1到9的數字，每個小九宮格里也有1到9的數字，并且一個數字在每個行列及每個小九宮格里都只能出現一次。

　　這次介紹的，是一個Java版的數獨游戲實現，轉載于[url]http://mcsudoku.sourceforge.net/[/url]，作者collomb,是一個基于Swing的javaSE應用。

　　應該說這是一個中規中矩的程序，既沒有別出心裁的創意，也沒有明顯的敗筆存在，把它作為熟悉Swing各個組件功能或者Java游戲入門的案例都可以，適合中到初級用戶學習。

　　游戲界面如下：

posted @ 2014-08-29 09:48 順其自然EVO 閱讀(181) | 評論 (0) | 編輯 收藏

與缺陷共舞

posted @ 2014-08-29 09:47 順其自然EVO 閱讀(181) | 評論 (0) | 編輯 收藏

也談配置管理團隊的建設

　公司在組建配置管理團隊（主要是項目級的配置管理員）時，通常有兩種選擇。

　　1）兼職項目CM。即開發人員兼任項目CM。選擇研發人員兼職的好處是項目CM了解項目進展和研發流程，能夠與項目經理等一起合作，溝通無障礙。缺點是研發人員以開發任務為主，工作量大時可能難以兼顧配管工作，易導致配管工作延遲。這個方案的另外一個缺點是兼職配管的人員流動性大，項目內任務的調配，人員離職等都會造成配管更換的問題。從就職資格的角度來說。每位新任的配管都需要經過培訓。這就加大了培訓的難度。盡管，硬幣的另一面是更多的開發人員接受了較為正式的配管培訓。

　　2）專職項目配管。比如一條產品線設一個專職配管，負責該產品線下所有項目的配管工作。這種做法有利于配管人員的專業化發展，長期對公司來說也是有利的。但是這種模式的前提是公司的配置管理體系已經較為完善，對于項目配管的工作流程比較清楚，權責界定也較為明確。對于新加入的項目配管，企業能夠很快通過培訓讓其上崗。確保公司的配管流程正常運轉。

　　有人可能會問，第二種方案顯然比第一種好，第一種方案還有存在必要嗎？問題是現在很多企業在面臨管理問題時，由于一些原因不能給足夠的資金購買商業軟件，也不會招聘正式的專職人員（這兩點是企業配置管理三大誤區中的兩點）。背后的深層次根源還是對配管工作沒有引起足夠的重視。在領導還未能對配管引起足夠重視的前提下，第一種方案就成了曲線救國的辦法。至少解決了有無問題。慢慢的研發人員就會開始抱怨，任務重，事情雜。第二種方案也就順理成章地成為領導自主自發的要求。

　　此外，配置管理團隊（這里主要指組織級配置管理工程師）的定位和匯報機制也比較關鍵。由于該崗位與研發關系密切，最好是歸屬研發部門或項目管理部。向研發部經理或項目管理部的leader匯報。必須獲得對配管工作的完全授權，避免出現研發部不認可、不配合的情況，甚至無法觸及研發流程和數據的問題（聽起來奇怪，但你見多了國內企業的亂象就會理解什么叫”見怪不怪”）。

posted @ 2014-08-29 09:47 順其自然EVO 閱讀(186) | 評論 (0) | 編輯 收藏

Mantis Bug Tracker一個開源的bug追蹤系統

posted @ 2014-08-29 09:46 順其自然EVO 閱讀(243) | 評論 (0) | 編輯 收藏

Web開發常見的幾個漏洞解決方法

　　2、SQL注入漏洞的出現和修復

　　1）SQL注入定義：

　　SQL注入攻擊是黑客對數據庫進行攻擊的常用手段之一。隨著B/S模式應用開發的發展，使用這種模式編寫應用程序的程序員也越來越多。但是由于程序員的水平及經驗也參差不齊，相當大一部分程序員在編寫代碼的時候，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段數據庫查詢代碼，根據程序返回的結果，獲得某些他想得知的數據，這就是所謂的SQL Injection，即SQL注入。

　　SQL注入有時候，在地址參數輸入，或者控件輸入都有可能進行。如在鏈接后加入’號，頁面報錯，并暴露出網站的物理路徑在很多時候，很常見，當然如果關閉了Web.Config的CustomErrors的時候，可能就不會看到。

　　另外，Sql注入是很常見的一個攻擊，因此，如果對頁面參數的轉換或者沒有經過處理，直接把數據丟給Sql語句去執行，那么可能就會暴露敏感的信息給對方了。如下面兩個頁面可能就會被添加注入攻擊：

　　①HTTP://xxx.xxx.xxx/abc.asp?p=YY and (select top 1 name from TestD ... type='U' and status>0)>0 得到第一個用戶建立表的名稱，并與整數進行比較，顯然abc.asp工作異常，但在異常中卻可以發現表的名稱。假設發現的表名是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語句的執行，可能需要對進行嚴格的轉換，例如如果是整形的，就嚴格把它轉換為整數，然后在操作，這樣可以避免一些潛在的危險，另外對構造的sql語句必須進行Sql注入語句的過濾，如我的框架（Winform開發框架、Web開發框架等）里面就內置了對這些有害的語句和符號進行清除工作，由于是在基類進行了過濾，因此基本上子類都不用關心也可以避免了這些常規的攻擊了。

/// <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() { //構造SQL的注入關鍵字符 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" }; //構造正則表達式 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; }

　　上面的語句用于判別常規的Sql攻擊字符，我在數據庫操作的基類里面，只需要判別即可，如下面的一個根據條件語句查找數據庫記錄的函數。

/// <summary> /// 根據條件查詢數據庫,并返回對象集合 /// </summary> /// <param name="condition">查詢的條件</param> /// <param name="orderBy">自定義排序語句，如Order By Name Desc；如不指定，則使用默認排序</param> /// <param name="paramList">參數列表</param> /// <returns>指定對象的集合</returns> public virtual List<T> Find(string condition, string orderBy, IDbDataParameter[] paramList) { if (HasInjectionData(condition)) { LogTextHelper.Error(string.Format("檢測出SQL注入的惡意數據, {0}", condition)); throw new Exception("檢測出SQL注入的惡意數據"); } ........................... }

　　以上只是防止Sql攻擊的一個方面，還有就是堅持使用參數化的方式進行賦值，這樣很大程度上減少可能受到SQL注入攻擊。

3、跨站腳本攻擊漏洞出現和修復

　　跨站腳本攻擊，又稱XSS代碼攻擊，也是一種常見的腳本注入攻擊。例如在下面的界面上，很多輸入框是可以隨意輸入內容的，特別是一些文本編輯框里面，可以輸入例如<script>alert('這是一個頁面彈出警告');</script>這樣的內容，如果在一些首頁出現很多這樣內容，而又不經過處理，那么頁面就不斷的彈框，更有甚者，在里面執行一個無限循環的腳本函數，直到頁面耗盡資源為止，類似這樣的攻擊都是很常見的，所以我們如果是在外網或者很有危險的網絡上發布程序，一般都需要對這些問題進行修復。

　　XSS代碼攻擊還可能會竊取或操縱客戶會話和 Cookie，它們可能用于模仿合法用戶，從而使黑客能夠以該用戶身份查看或變更用戶記錄以及執行事務。[建議措施]清理用戶輸入，并過濾出 JavaScript 代碼。我們建議您過濾下列字符：

　　[1] <>（尖括號）

　　[2] "（引號）

　　[3] '（單引號）

　　[4] %（百分比符號）

　　[5] ;（分號）

　　[6] ()（括號）

　　[7] &（& 符號）

　　[8] +（加號）

　　為了避免上述的XSS代碼攻擊，解決辦法是可以使用HttpUitility的HtmlEncode或者最好使用微軟發布的AntiXSSLibrary進行處理，這個更安全。

　　微軟反跨站腳本庫（AntiXSSLibrary）是一種編碼庫，旨在幫助保護開發人員保護他們的基于Web的應用不被XSS攻擊。

　　例如上面的內容，賦值給一個Lable控件，不會出現彈框的操作。

　　但是，我們雖然顯示的時候設置了轉義，輸入如果要限制它們怎么辦呢，也是使用AntiXSSLibrary里面的HtmlSanitizationLibrary類庫Sanitizer.GetSafeHtmlFragment即可。

　　protected void btnPost_Click(object sender, EventArgs e)

　　{

　　this.lblName.Text = Sanitizer.GetSafeHtmlFragment(txtName.Text);

　　}

　　這樣對于特殊腳本的內容，會自動剔除過濾，而不會記錄了，從而達到我們想要的目的。

　　Database db = CreateDatabase();

　　DbCommand command = db.GetSqlStringCommand(sql);

　　command.Parameters.AddRange(param);

　4、IIS短文件/文件夾漏洞出現和修復

　　通過猜解，可能會得出一些重要的網頁文件地址，如可能在/Pages/Security/下存在UserList.aspx和MenuList.aspx文件。

　　[建議措施]

　　1）禁止url中使用“~”或它的Unicode編碼。

　　2）關閉windows的8.3格式功能。

　　修復可以參考下面的做法，或者找相關運維部門進行處理即可。

　　http://sebug.net/vuldb/ssvid-60252

　　http://webscan.360.cn/vul/view/vulid/1020

　　http://www.bitscn.com/network/security/200607/36285.html

　　5、系統敏感信息泄露出現和修復

　　如果頁面繼承一般的page，而沒有進行Session判斷，那么可能會被攻擊者獲取到頁面地址，進而獲取到例如用戶名等重要數據的。

　　一般避免這種方式是對于一些需要登錄才能訪問到的頁面，一定要進行Session判斷，可能很容易給漏掉了。如我在Web框架里面，就是繼承一個BasePage，BasePage 統一對頁面進行一個登錄判斷。

public partial class UserList : BasePage { protected void Page_Load(object sender, EventArgs e) { ............... /// <summary> /// BasePage 集成自權限基礎抽象類FPage，其他頁面則集成自BasePage /// </summary> public class BasePage : FPage { /// <summary> /// 默認構造函數 /// </summary> public BasePage() { this.IsFunctionControl = true;//默認頁面啟動權限認證 } /// <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方法以使權限類判斷是否具有某功能點的權限 /// </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調用權限系統的HasFunction函數出錯"); } return breturn; } protected override void OnInit(EventArgs e) { Response.Cache.SetNoStore(); //清除緩存 base.OnInit(e); CheckLogin(); }

　　否則可能會受到攻擊，并通過抓包軟件發現頁面數據，獲得一些重要的用戶名或者相關信息。

　　還有一個值得注意的地方，就是一般這種不是很安全的網絡，最好要求輸入比較復雜一點的密碼（強制要求），例如不能全部是數字密碼或者不能是純字符，對位數也要求多一點，因為很多人輸入12345678,123456，123這樣的密碼，很容易被猜出來并登錄系統，造成不必要的損失。

　　6、總結性建議

　　針對上面發現的問題，提出下面幾條建議。

　　1）在服務器與網絡的接口處配置防火墻，用于阻斷外界用戶對服務器的掃描和探測。

　　2）限制網站后臺訪問權限，如：禁止公網IP訪問后臺；禁止服務員使用弱口令。

　　3）對用戶輸入的數據進行全面安全檢查或過濾，尤其注意檢查是否包含SQL 或XSS特殊字符。這些檢查或過濾必須在服務器端完成。

　　4）關閉windows的8.3格式功能。

　　5）限制敏感頁面或目錄的訪問權限。

posted @ 2014-08-29 09:45 順其自然EVO 閱讀(656) | 評論 (0) | 編輯 收藏

Spring框架下的單元測試方法

posted @ 2014-08-29 09:43 順其自然EVO 閱讀(273) | 評論 (0) | 編輯 收藏

使用RSpec編寫具有可讀性的功能測試

posted @ 2014-08-29 09:42 順其自然EVO 閱讀(183) | 評論 (0) | 編輯 收藏