1什麼是DotNet的CLR? CLR作用是什麼？
A不知道 B知道很少 C知道一些 D非常瞭解
2 DotNet中如何使用Win32的DLL？（沒有reference可以添加）
A不知道 B知道很少 C知道一些 D非常瞭解
3 C#使用什麼關鍵字實現可變個數參數(variable number parameters)？
A不知道 B知道很少 C知道一些 D非常瞭解
4 C#中的weak reference是什麼？用於什麼場合？
A不知道 B知道很少 C知道一些 D非常瞭解
5 C#中的using dispose模式是什麼？用於什麼場合？
A不知道 B知道很少 C知道一些 D非常瞭解
6 C#中Garbage Collection是什麼？簡介GC的internal工作方式(如果你是微軟開發人員，如何實現GC)?
A不知道 B知道很少 C知道一些 D非常瞭解
7 C#中的關鍵字as, yield, out/ref, virtual/abstract/override？
A不知道 B知道很少 C知道一些 D非常瞭解
8 Strong name signature是什麼？有什麼用？
A不知道 B知道很少 C知道一些 D非常瞭解
9 字串intern暫留機制是怎麼一回事？
A不知道 B知道很少 C知道一些 D非常瞭解
10 Windows平臺下多進程通訊方式？越多越好
A不知道 B知道很少 C知道一些 D非常瞭解
11 Delegate, Event, Action, Func都是什麼？
A不知道 B知道很少 C知道一些 D非常瞭解
12 MVC, MVP, MVVM設計模式？
A不知道 B知道很少 C知道一些 D非常瞭解
13 除了工廠模式和單例模式，列舉並且簡單介紹你知道的設計模式以及應用場合？
A不知道 B知道很少 C知道一些 D非常瞭解
14 C#中overload和override如何實現？
A不知道 B知道很少 C知道一些 D非常瞭解
15 介面和抽象類別有什麼區別？都應用在什麼場合？
A不知道 B知道很少 C知道一些 D非常瞭解
16 LINQ是什麼？寫一個簡單的LINQ語句？
A不知道 B知道很少 C知道一些 D非常瞭解
17 C# Lambda是什麼？寫一個簡單的lambda?
A不知道 B知道很少 C知道一些 D非常瞭解
18 C#中class與struct區別？
訂閱
文章
所有留言
2011年7月27日星期三
2011年6月27日星期一
Web伺服器及資料庫伺服器安全性:
建議：
1. 刪除不必要的服務。
2. 管理員儘量使用本地登錄或內部網路登入訪問限制，儘量關閉遠端存取。
3. 分離開發、測試和產品環境。
4. 除了Web應用程式內容及腳本，注意控制Web應用程式目錄內有價值檔、系統檔的訪問，阻止用戶採用腳本化手段訪問系統檔或執行系統命令。
5. 對於Web應用程式訪問系統所持有的網路服務（Network Service），賦予盡可能少的許可權。
6. 及時安裝所有安全補丁。
7. 通過監視器監視和審核伺服器，經常查看伺服器日誌，捕捉其中的異常並及時進行處理。
8. 將不必要的和系統預設的部分刪除，系統管理員要使用自己創建的密碼安全的帳戶。
9. 刪除所有不使用的模組和應用程式擴展。
10. 使用Web伺服器自帶的安全工具。
11. 持續關注安全問題，經常學習安全知識、最新漏洞及更新手段，瞭解安全工具及相關知識。
12. 儘量使用掃描器定期對安全設定進行掃描，檢查伺服器是否符合安全標準。
1. 刪除不必要的服務。
2. 管理員儘量使用本地登錄或內部網路登入訪問限制，儘量關閉遠端存取。
3. 分離開發、測試和產品環境。
4. 除了Web應用程式內容及腳本，注意控制Web應用程式目錄內有價值檔、系統檔的訪問，阻止用戶採用腳本化手段訪問系統檔或執行系統命令。
5. 對於Web應用程式訪問系統所持有的網路服務（Network Service），賦予盡可能少的許可權。
6. 及時安裝所有安全補丁。
7. 通過監視器監視和審核伺服器，經常查看伺服器日誌，捕捉其中的異常並及時進行處理。
8. 將不必要的和系統預設的部分刪除，系統管理員要使用自己創建的密碼安全的帳戶。
9. 刪除所有不使用的模組和應用程式擴展。
10. 使用Web伺服器自帶的安全工具。
11. 持續關注安全問題，經常學習安全知識、最新漏洞及更新手段，瞭解安全工具及相關知識。
12. 儘量使用掃描器定期對安全設定進行掃描，檢查伺服器是否符合安全標準。
2011年6月25日星期六
軟體專案開發過程中主要遇到的核心問題小結
01：軟體專案開發合同的訂立，合同需要對將來幾個月甚至幾年需要做的事情有個明確的定義說明，限定好工作範圍、工作內容、承擔的責任、專案總費用，每個階段支付的費用都需要有明確的說明甚至付款條件等都需要一清二楚，很多東西都沒講明白是將來合作不愉快的導火索，這些都需要白紙黑字寫清楚，其實從合同上也能看出甲乙雙方的水準在什麼層次上的。
02：軟體發展過程中，往往會發生客戶不按時支付費用的事情，因為軟體發展不只是腦力活兒，也是強度非常大的體力活兒，難免會遇到不能按時交付軟體的可能性，除非遇上非常有經驗的能相對準確評估工作量、工期的管理人員，參考歷史的開發經驗、再按自身團隊的開發技術能力、協調工作效率，計畫出一個合理的工期計畫來，因為整個公司都需要考慮到資金安全、開發風險，需要有一定的水準能說服客戶及時付款，至少可以支付大部分款項的人，在開發軟體專案的過程中往往會發生需要墊資幾十萬的事情，其間需要做好防備工作需要防止資金鏈斷裂了。
03：軟體發展人員中途離職也是家常便飯，相對規範的公司，一年也大概也會有10%的人員流動性，若薪資待遇也不怎麼樣、公司管理也不規範，開發人員也學不到知識、業務也不穩定的，那估計有50%的流動性也是很正常的事情，連微軟、Google都會有開發人員離職現象，更何況一個不知名的公司，人員離職是很正常的現象，但是人員離職了就得需要有後備開發人員，公司管理人員需要在最短的時間內招聘到合適的人員，這也需要必備的技能。
04：現在已經不是單槍匹馬就能搞定中型軟體系統的年代了，一個軟體專案開發過程中往往需要N多人參與，客戶對軟體專案的品質要求，功能要求也越來越高，不只是需要把程式寫好，還需要有各種配套文檔，測試都需要跟上，所以這些人的協調工作、及時溝通也是很大的問題，若一個專案經理的溝通能力有問題也很容易遇到很多沒必要的麻煩，也會使得項目進展會很不順利的局面，甚至到有敵對力量產生的程度，一個公司，一個項目最怕的是內耗，我們國家其實很多東西也都浪費在內耗上了，若沒幾千年封建王朝的內耗，我們應該會發展的比美國強大很多。
05：合理的安排工作計畫、有目的有計劃的做事情，很不容易，專案裡需要完成的工作NN多，需要協調的人員NN多，需要設計實現的功能NN多，做一個軟體專案並沒有學習程式設計那麼輕鬆愉快，更不項打網路遊戲一樣輸了還可以從頭再來，軟體專案開發是不允許輸了再來的，輸了就需要按合同進行經濟賠償、又要丟人、又容易吃官司、還無法在這個圈子裡繼續生存了，至少會口碑很差了。
06：進度的把控比制定工作計畫更難，我們可以制定個計畫2012年開發好作業系統、2013年開發好資料庫、2014年開發好編譯器、開發環境，看上去很美，其實更本沒那個能力實現這個計畫，計畫計畫難免會有變化，計畫目標需要不斷地調整，但是調整得太大，那說明這個計畫有問題不符合實際甚至是有些空洞的計畫瞎搞搞而已，開發專案過程中需要分工合理，有一定的穩定性，例如今天讓你ASP開發，明天PHP開發，後天C#開發，大後面又是JAVA開發，估計沒幾個開發人員不會被折磨瘋了，工作分配也是一個道理，需要有一定的穩定性。
及時的驗收確認好工作安排也是需要有水準的，若開會問大家任務完成了嗎？大部分都會說“快好了”，快好了可以理解為，已經完成了10%？已經完成了90%？但是剩下10%是技術難題，超級複雜的功能，那其實這並不是完成了90%，雖然開發人員理解為90%，但是可能10%都不到而已。
07：高效的會議，解決問題需要有效率，特別緊急時需要有站立式會議，專案緊急時也需要安排每天的會議，會議不適合超過20-30分鐘，甚至10分鐘內開好會議是最理想的，例如我們10個人參加會議，會議開了1天，那其實是超級浪費生命，如何高效的指揮大家，如何開一個高效的會議，責任明確的，能解決問題的會議是需要有一些水準的，若以前參與過牛B管理人員主持的會議，那很容易有經驗了，參考別人的好處多多。
08：及時的強有力的測試，人都不可能自己找出自己的缺點，寫程式也一樣，能自己找出自己缺點的，能自己測試出自己程式錯誤的人，都是牛人，啥叫牛人？就是這樣的人不多才叫牛人，普通人是還是需要別人來測試出問題，回饋給大家的，這個就是生產裡的一個工序，筆記本生產線上少了一個測試檢驗的，那會惹來多少麻煩？天天有客戶投訴，天天有人退款，天天折騰更換本本的事情來回快遞來回折騰，何必呢？增加一個測試環節，減少很多後期麻煩的產生。
09：成熟的功能設計套路、函數命名套路、表單命名、變數命名等等，也會大大的減少專案的開發週期，專案前期需要把例副程式都寫好，適當的進行一些培訓工作，然後讓大家模仿例副程式就可以了，例副程式不適合寫得超級複雜，功能超級強大，只要能把主要核心思想都表明了就可以了，最好還是拿個投影講一下比較好，這樣大家的印象也會更深刻一些。
10：成熟的資料庫設計套路，其實資料庫設計也是一門學問，看起來簡單，真正想設計好也需要有硬功夫，也需要手藝精湛、技藝高超的。資料庫基本上還是目前開發各種管理系統必不可少的組成部分，甚至現在還是穩定的執行資訊系統的基石，所以資料庫設計是否合理、至少30-40%的專案是否順利穩定的分量是有的。
11：代碼規範，代碼品質檢查，由於項目不是一杆子買賣，往往還擔負著後期的維護，甚至部分運行工作，若專案的代碼品質不好後期會有無窮無盡的痛苦，把一些問題扼殺在搖籃裡，總比把問題培養大了，再去消滅得麻煩、頭大，所以專案的中後期一定要安排嚴格的代碼品質檢查工作，可以找個工作效率非常高，做事情又相對仔細認真的人，來個地毯式轟炸，從頭到尾把掃一眼，很多有SQL注入漏洞、有重複功能的代碼、命名不合理的代碼等等還是會被發現很多，畢竟專案開發中參與的人多，人多了就很容易啥鳥都有了。
12：系統架構重構上也花費蠻多時間，由於客戶是要求在分散式環境裡運行系統，開發時又往往是單機上開發調試，又沒充足的時間慢慢勾畫、慢慢設計，工作安排往往是排得滿滿的，系統的架構有時候需要進行一些調整，若剛開始開發時就架構不明確、思路不嚴謹，到項目的中後期，整個項目就會大亂，更本經不起系統架構的重構，當然這裡的架構架構重構更多的是小調整，若真的是大調整那說明剛開始的架構就是非常失敗的，專案由於不是1個人開發的，若是一個人開發專案那還好說，想怎麼調整就調整，現在是多個人開發項目，雖然不能比喻是航空母艦，至少像個護衛艦，想怎麼拐彎就怎麼拐彎不是那麼容易的。
13：技術疑難為題外包，項目過程中遇到了一些WCF配置相關的疑難問題，前後解決了10多個問題，還是無法順利搞定資訊加密傳輸、電子證書SSL安全配置等等，甚至兩台電腦之間的TCP方式通訊上也遇到了問題，由於手上有300多個付費用戶，而且他們都是開發人員，所以把這個資訊一發佈，馬上就有專家回應，人家2個小時就搞定問題了，支付了500元辛苦費，錢雖然少也是個心意，我也把問題搞定了，我的付費客戶也從我這裡賺到辛苦錢了，2個小時若都能賺500元，而且是自己擅長的事情，我想也足夠可以了，有時候選擇花錢辦事比花時間辦事更爽。
14：項目經理的帶頭作用是不可低估的，若碰上一個天天吃喝嫖賭、天天遊手好閒的項目經理，那這個項目的最後的結局就是等著賠款就可以了，其他人員看到項目是這樣的人沒幾個SB會拼命幹了，大家頂多裝裝樣子，混混日子找找那裡有更好的前途了，這裡就是不是久留之地的念頭沒幾天就產生了，我自己曾經就遇到過這樣的情況，我沒到半年就跑路了，公司沒兩年就關門大吉了，因為這樣的領導不是真正幹事的，頂多就是轉了空子碰到到了狗屎運而已長久不來。
15：採用成熟的軟體元件也會大大的促進軟體專案的開發進度，這次我們工作流自己開發了一套B/S的，在網頁上拖拖拉拉就可以設定好工作流的，自己也比較滿意的效果，但是現在想想有接近足足開發了5個月，這個開發成本算 開發人員的工資 + 公司的房租、辦公費用 +相應的管理費用 + 測試成本 ，遠遠超過了6萬以上的成本，只是這個錢沒一次性拿出，而是每個月一點點的往外付出而已。而且還花費了5個月時間，還不能確保沒任何錯誤，其實到真正穩定好用，至少要燒掉10萬了。若從專案開始開發就用合理的價格購買了一套，不用5個月時間自己開發，而是用1個月時間學會怎麼用，然後剩下的4個月時間放在核心的業務系統的開發上，專案會相對來說更輕鬆、更順利一些，畢竟戰線就縮短了很多了，可以集中優勢兵力重點突破。兵力分散乃大忌也。
16：軟體在開發測試階段往往會有客戶的需求變更，甚至有可能會有大面積的需求變更，每變更一次需求，客戶會覺得這個是簡單的變更，開發人員會說是超級複雜的需求變更甚至會說前面的工作都白做了，這時候需要有超級強的溝通能力，一方面儘量阻止客戶發生沒必要的變更，甚至徹底想清楚了再變更，每次變更都有文檔記錄，好向客戶追加軟體發展費用，其實這個除了大客戶、實際強的客戶外，想追加費用是難於上天的事情。只能是跟客戶處理好關係、下次客戶還能找你就不錯了，客戶的錢也不是飄來的，預算也是有限的，所以若不想把客戶得罪了，還只能按著客戶的變更來、頂多是把事情都講清楚，這部分變更帶來了多少工作量等等，至少按合同支付費用時，能有個協商的籌碼對吧。
開發人員這裡，有再大的牢騷也是沒辦法的事情，為人民服務、為客戶服務，客戶是上帝，讓客戶滿意，讓客戶用我們的軟體更舒服、爽一些，只能按客戶的要求重新調整程式，若水準高怎麼調整都沒事，例如用通用許可權管理系統元件來說，我還真希望客戶能提改進意見，那會開心死了，怎麼調整都不怕，因為維護了7-8年，經得起折騰，再說我的開發技能也是頂呱呱的，不怕客戶折騰，經得起折騰，因為這東西是銅牆鐵壁地。
客戶是上帝、客戶既然選擇了我們，客戶燒了錢找我們做軟體發展了，我們就得讓客戶把這錢燒更舒坦，得更爽。
昨天晚上調試優化程式又住在辦公室了，今天還得繼續戰鬥，等項目結束了出去旅遊一下，放鬆幾個月再戰鬥。
謝謝大家補充完善、有不足之處請指點。
02：軟體發展過程中，往往會發生客戶不按時支付費用的事情，因為軟體發展不只是腦力活兒，也是強度非常大的體力活兒，難免會遇到不能按時交付軟體的可能性，除非遇上非常有經驗的能相對準確評估工作量、工期的管理人員，參考歷史的開發經驗、再按自身團隊的開發技術能力、協調工作效率，計畫出一個合理的工期計畫來，因為整個公司都需要考慮到資金安全、開發風險，需要有一定的水準能說服客戶及時付款，至少可以支付大部分款項的人，在開發軟體專案的過程中往往會發生需要墊資幾十萬的事情，其間需要做好防備工作需要防止資金鏈斷裂了。
03：軟體發展人員中途離職也是家常便飯，相對規範的公司，一年也大概也會有10%的人員流動性，若薪資待遇也不怎麼樣、公司管理也不規範，開發人員也學不到知識、業務也不穩定的，那估計有50%的流動性也是很正常的事情，連微軟、Google都會有開發人員離職現象，更何況一個不知名的公司，人員離職是很正常的現象，但是人員離職了就得需要有後備開發人員，公司管理人員需要在最短的時間內招聘到合適的人員，這也需要必備的技能。
04：現在已經不是單槍匹馬就能搞定中型軟體系統的年代了，一個軟體專案開發過程中往往需要N多人參與，客戶對軟體專案的品質要求，功能要求也越來越高，不只是需要把程式寫好，還需要有各種配套文檔，測試都需要跟上，所以這些人的協調工作、及時溝通也是很大的問題，若一個專案經理的溝通能力有問題也很容易遇到很多沒必要的麻煩，也會使得項目進展會很不順利的局面，甚至到有敵對力量產生的程度，一個公司，一個項目最怕的是內耗，我們國家其實很多東西也都浪費在內耗上了，若沒幾千年封建王朝的內耗，我們應該會發展的比美國強大很多。
05：合理的安排工作計畫、有目的有計劃的做事情，很不容易，專案裡需要完成的工作NN多，需要協調的人員NN多，需要設計實現的功能NN多，做一個軟體專案並沒有學習程式設計那麼輕鬆愉快，更不項打網路遊戲一樣輸了還可以從頭再來，軟體專案開發是不允許輸了再來的，輸了就需要按合同進行經濟賠償、又要丟人、又容易吃官司、還無法在這個圈子裡繼續生存了，至少會口碑很差了。
06：進度的把控比制定工作計畫更難，我們可以制定個計畫2012年開發好作業系統、2013年開發好資料庫、2014年開發好編譯器、開發環境，看上去很美，其實更本沒那個能力實現這個計畫，計畫計畫難免會有變化，計畫目標需要不斷地調整，但是調整得太大，那說明這個計畫有問題不符合實際甚至是有些空洞的計畫瞎搞搞而已，開發專案過程中需要分工合理，有一定的穩定性，例如今天讓你ASP開發，明天PHP開發，後天C#開發，大後面又是JAVA開發，估計沒幾個開發人員不會被折磨瘋了，工作分配也是一個道理，需要有一定的穩定性。
及時的驗收確認好工作安排也是需要有水準的，若開會問大家任務完成了嗎？大部分都會說“快好了”，快好了可以理解為，已經完成了10%？已經完成了90%？但是剩下10%是技術難題，超級複雜的功能，那其實這並不是完成了90%，雖然開發人員理解為90%，但是可能10%都不到而已。
07：高效的會議，解決問題需要有效率，特別緊急時需要有站立式會議，專案緊急時也需要安排每天的會議，會議不適合超過20-30分鐘，甚至10分鐘內開好會議是最理想的，例如我們10個人參加會議，會議開了1天，那其實是超級浪費生命，如何高效的指揮大家，如何開一個高效的會議，責任明確的，能解決問題的會議是需要有一些水準的，若以前參與過牛B管理人員主持的會議，那很容易有經驗了，參考別人的好處多多。
08：及時的強有力的測試，人都不可能自己找出自己的缺點，寫程式也一樣，能自己找出自己缺點的，能自己測試出自己程式錯誤的人，都是牛人，啥叫牛人？就是這樣的人不多才叫牛人，普通人是還是需要別人來測試出問題，回饋給大家的，這個就是生產裡的一個工序，筆記本生產線上少了一個測試檢驗的，那會惹來多少麻煩？天天有客戶投訴，天天有人退款，天天折騰更換本本的事情來回快遞來回折騰，何必呢？增加一個測試環節，減少很多後期麻煩的產生。
09：成熟的功能設計套路、函數命名套路、表單命名、變數命名等等，也會大大的減少專案的開發週期，專案前期需要把例副程式都寫好，適當的進行一些培訓工作，然後讓大家模仿例副程式就可以了，例副程式不適合寫得超級複雜，功能超級強大，只要能把主要核心思想都表明了就可以了，最好還是拿個投影講一下比較好，這樣大家的印象也會更深刻一些。
10：成熟的資料庫設計套路，其實資料庫設計也是一門學問，看起來簡單，真正想設計好也需要有硬功夫，也需要手藝精湛、技藝高超的。資料庫基本上還是目前開發各種管理系統必不可少的組成部分，甚至現在還是穩定的執行資訊系統的基石，所以資料庫設計是否合理、至少30-40%的專案是否順利穩定的分量是有的。
11：代碼規範，代碼品質檢查，由於項目不是一杆子買賣，往往還擔負著後期的維護，甚至部分運行工作，若專案的代碼品質不好後期會有無窮無盡的痛苦，把一些問題扼殺在搖籃裡，總比把問題培養大了，再去消滅得麻煩、頭大，所以專案的中後期一定要安排嚴格的代碼品質檢查工作，可以找個工作效率非常高，做事情又相對仔細認真的人，來個地毯式轟炸，從頭到尾把掃一眼，很多有SQL注入漏洞、有重複功能的代碼、命名不合理的代碼等等還是會被發現很多，畢竟專案開發中參與的人多，人多了就很容易啥鳥都有了。
12：系統架構重構上也花費蠻多時間，由於客戶是要求在分散式環境裡運行系統，開發時又往往是單機上開發調試，又沒充足的時間慢慢勾畫、慢慢設計，工作安排往往是排得滿滿的，系統的架構有時候需要進行一些調整，若剛開始開發時就架構不明確、思路不嚴謹，到項目的中後期，整個項目就會大亂，更本經不起系統架構的重構，當然這裡的架構架構重構更多的是小調整，若真的是大調整那說明剛開始的架構就是非常失敗的，專案由於不是1個人開發的，若是一個人開發專案那還好說，想怎麼調整就調整，現在是多個人開發項目，雖然不能比喻是航空母艦，至少像個護衛艦，想怎麼拐彎就怎麼拐彎不是那麼容易的。
13：技術疑難為題外包，項目過程中遇到了一些WCF配置相關的疑難問題，前後解決了10多個問題，還是無法順利搞定資訊加密傳輸、電子證書SSL安全配置等等，甚至兩台電腦之間的TCP方式通訊上也遇到了問題，由於手上有300多個付費用戶，而且他們都是開發人員，所以把這個資訊一發佈，馬上就有專家回應，人家2個小時就搞定問題了，支付了500元辛苦費，錢雖然少也是個心意，我也把問題搞定了，我的付費客戶也從我這裡賺到辛苦錢了，2個小時若都能賺500元，而且是自己擅長的事情，我想也足夠可以了，有時候選擇花錢辦事比花時間辦事更爽。
14：項目經理的帶頭作用是不可低估的，若碰上一個天天吃喝嫖賭、天天遊手好閒的項目經理，那這個項目的最後的結局就是等著賠款就可以了，其他人員看到項目是這樣的人沒幾個SB會拼命幹了，大家頂多裝裝樣子，混混日子找找那裡有更好的前途了，這裡就是不是久留之地的念頭沒幾天就產生了，我自己曾經就遇到過這樣的情況，我沒到半年就跑路了，公司沒兩年就關門大吉了，因為這樣的領導不是真正幹事的，頂多就是轉了空子碰到到了狗屎運而已長久不來。
15：採用成熟的軟體元件也會大大的促進軟體專案的開發進度，這次我們工作流自己開發了一套B/S的，在網頁上拖拖拉拉就可以設定好工作流的，自己也比較滿意的效果，但是現在想想有接近足足開發了5個月，這個開發成本算 開發人員的工資 + 公司的房租、辦公費用 +相應的管理費用 + 測試成本 ，遠遠超過了6萬以上的成本，只是這個錢沒一次性拿出，而是每個月一點點的往外付出而已。而且還花費了5個月時間，還不能確保沒任何錯誤，其實到真正穩定好用，至少要燒掉10萬了。若從專案開始開發就用合理的價格購買了一套，不用5個月時間自己開發，而是用1個月時間學會怎麼用，然後剩下的4個月時間放在核心的業務系統的開發上，專案會相對來說更輕鬆、更順利一些，畢竟戰線就縮短了很多了，可以集中優勢兵力重點突破。兵力分散乃大忌也。
16：軟體在開發測試階段往往會有客戶的需求變更，甚至有可能會有大面積的需求變更，每變更一次需求，客戶會覺得這個是簡單的變更，開發人員會說是超級複雜的需求變更甚至會說前面的工作都白做了，這時候需要有超級強的溝通能力，一方面儘量阻止客戶發生沒必要的變更，甚至徹底想清楚了再變更，每次變更都有文檔記錄，好向客戶追加軟體發展費用，其實這個除了大客戶、實際強的客戶外，想追加費用是難於上天的事情。只能是跟客戶處理好關係、下次客戶還能找你就不錯了，客戶的錢也不是飄來的，預算也是有限的，所以若不想把客戶得罪了，還只能按著客戶的變更來、頂多是把事情都講清楚，這部分變更帶來了多少工作量等等，至少按合同支付費用時，能有個協商的籌碼對吧。
開發人員這裡，有再大的牢騷也是沒辦法的事情，為人民服務、為客戶服務，客戶是上帝，讓客戶滿意，讓客戶用我們的軟體更舒服、爽一些，只能按客戶的要求重新調整程式，若水準高怎麼調整都沒事，例如用通用許可權管理系統元件來說，我還真希望客戶能提改進意見，那會開心死了，怎麼調整都不怕，因為維護了7-8年，經得起折騰，再說我的開發技能也是頂呱呱的，不怕客戶折騰，經得起折騰，因為這東西是銅牆鐵壁地。
客戶是上帝、客戶既然選擇了我們，客戶燒了錢找我們做軟體發展了，我們就得讓客戶把這錢燒更舒坦，得更爽。
昨天晚上調試優化程式又住在辦公室了，今天還得繼續戰鬥，等項目結束了出去旅遊一下，放鬆幾個月再戰鬥。
謝謝大家補充完善、有不足之處請指點。
2011年6月11日星期六
企業應用架構模式筆記
企業應用：
1.企業應用一般都涉及持久化資料。
2.企業應用一般都涉及大量資料。
3.一般都涉及很多人同時訪問資料。
4.還涉及大量運算元據的使用者介面螢幕。
要學會通過簡化，把一個大型專案簡化成小型專案。
因為如果是一個小型系統的失敗，可能對於一個大型系統來說，這種失敗就不會顯得那麼起眼了。這樣的思想是因為沒有對小型項目的積累作用足夠的重視。
企業應用的種類：
關於可伸縮性：
1.回應時間：是一個系統完成一次外部請求處理所需的時間。可能是用戶的一次交互行為，也可能是伺服器API的調用。
2.回應性：系統相應請求的速度有多快。最好可以在回應處理完之前給使用者一些資訊表明系統已經接到請求，則回應性會更好一些。
3.等待時間：獲得系統任何形式回應的最小時間。即使應該做的工作並不存在。通常這是遠端系統中的大s問題。
假設什麼都不做，只是調用返回即可。如果是本地，一般會立即得到回應。但是如果是遠端，這樣的回應往往是數秒甚至更長。
4.吞吐率：給定時間內可以處理多大的請求量。
而性能有可能指吞吐率，或者是回應時間，也可能有用戶自己決定。回應性往往比回應時間更重要。
6.負載：關於系統當前負荷的表達，也可以用當前有多少個使用者與系統相連來表示。
7.負載敏感度：回應時間隨負載變化的程度。
8.效率：性能除以資源。如一個雙CPU的系統性能是30tps,而另一個系統有4個CPU,性能是40tps，那麼前者的效率比後者的高。
9.可伸縮性度量的是向系統中增加資源(通常是硬體)對於系統性能的影響。
模式：
模式的定義：
對於特定的解決方案，它有效而且有足夠的通用性，能解決重複出現的問題。
另一種視角是把它看成一組建議，而創造模式的藝術則是將很多的建議分解開來，形成相互獨立的組，在此基礎上可以相對獨立的討論它們。
1.企業應用一般都涉及持久化資料。
2.企業應用一般都涉及大量資料。
3.一般都涉及很多人同時訪問資料。
4.還涉及大量運算元據的使用者介面螢幕。
要學會通過簡化，把一個大型專案簡化成小型專案。
因為如果是一個小型系統的失敗，可能對於一個大型系統來說，這種失敗就不會顯得那麼起眼了。這樣的思想是因為沒有對小型項目的積累作用足夠的重視。
企業應用的種類：
關於可伸縮性：
1.回應時間：是一個系統完成一次外部請求處理所需的時間。可能是用戶的一次交互行為，也可能是伺服器API的調用。
2.回應性：系統相應請求的速度有多快。最好可以在回應處理完之前給使用者一些資訊表明系統已經接到請求，則回應性會更好一些。
3.等待時間：獲得系統任何形式回應的最小時間。即使應該做的工作並不存在。通常這是遠端系統中的大s問題。
假設什麼都不做，只是調用返回即可。如果是本地，一般會立即得到回應。但是如果是遠端，這樣的回應往往是數秒甚至更長。
4.吞吐率：給定時間內可以處理多大的請求量。
而性能有可能指吞吐率，或者是回應時間，也可能有用戶自己決定。回應性往往比回應時間更重要。
6.負載：關於系統當前負荷的表達，也可以用當前有多少個使用者與系統相連來表示。
7.負載敏感度：回應時間隨負載變化的程度。
8.效率：性能除以資源。如一個雙CPU的系統性能是30tps,而另一個系統有4個CPU,性能是40tps，那麼前者的效率比後者的高。
9.可伸縮性度量的是向系統中增加資源(通常是硬體)對於系統性能的影響。
模式：
模式的定義：
對於特定的解決方案，它有效而且有足夠的通用性，能解決重複出現的問題。
另一種視角是把它看成一組建議，而創造模式的藝術則是將很多的建議分解開來，形成相互獨立的組，在此基礎上可以相對獨立的討論它們。
2011年5月23日星期一
8種網站防止盜鏈的方法
作為普通的線民來說，一般不需要知道也不用關心什麼是盜鏈，不過如果你是網站的開發者或維護者，就不得不重視盜鏈的問題了。如果你剛剛開發完一個沒有防盜鏈的帶有檔下載功能的網站，掛上internet，然後上傳幾個時下非常熱門的軟體或電影並在網站內公佈下載地址，讓MSN上的所有好友都來體驗一下你的傑作。不用多久就會發現網速出奇地變慢，甚至伺服器託管中心的服務員會熱情地打電話告訴你的網站流量很大，估計是網站受歡迎起來了，問你是不是該考慮加錢租用頻寬更寬但價格更貴的網線了。在這個值得慶祝的時候趕快打開Google Analytics看看有多少人來光顧你的網站了吧，如果發現訪客每天才十來個人，很遺憾地告訴你：你的網站資源不幸地被人盜鏈了。而且更糟糕的是，當你把網站上的檔和電影通通刪光之後，網站仍然沒有變快多少，從web伺服器的訪問日誌裡會發現瘋狂的訪問請求正從四面八方湧過來，web伺服器為了迎接這批訪客而沒有時間處理正常的頁面，這種狀況可能會一直持續好幾個周時間。
網站資源被盜鏈簡單來說就是別人不是從你的網站通過下載資源，被盜鏈的幾種可能情況：
1、在人氣非常旺的網站、論壇、社區的網頁裡直接引用了（使用標記）你網站上的圖片，或者直接在其他網頁（使用flash或媒體播放外掛程式）裡嵌入了你網站上的mp3。
2、在人氣非常旺的網站、論壇、社區裡提供了你的資源的下載地址。
3、你網站的資源可能被一些下載軟體列入了“資源候選名單”，當其他人用下載工具下載相同的檔時，下載軟體會自動找上門並且從你的伺服器下載。
既然被盜鏈的後果這麼可怕，那有哪些方法可以防止盜鏈呢下面從簡到繁總結一下常見的以及自己實踐過的一些方法，並簡單分析一下。不過很遺憾地，這些方法都沒法完全杜絕被盜鏈，並且防盜鏈的目的應該是從一定的程度上減少被盜鏈所產生的影響，同時能讓合法的使用者能夠以自然的方式、順暢地從你的網站下載資源。
方法1：判斷引用地址
這個方法是最早及最常見的方法。所謂判斷引用位址，就是判斷流覽器請求時HTTP頭的Referer欄位的值，這個值在asp.net裡面可以用 Request.UrlReferrer屬性取得。幾個例子來說，在正常情況下當使用者在流覽 http://uushare.com/abc.html 時點擊一個連結去到 http://uushare.com/jacky.mp3 檔時，流覽器在發出請求jacky.mp3 資源時還會附帶當刻流覽器所處的頁面位址（即http://uushare.com/abc.html），所以當你的網站程式接收到下載 jacky.mp3 資源請求的時候，先判斷http的referer欄位的值，如果是從 自己的功能變數名稱（uushare.com）過來的，則可以認為是合法的連接請求，否則就返回一個錯誤的提示資訊。
這種方法通常用於圖片、 mp3這種容易被人用html“嵌入”到其他網站的資源，使用這種方法可以防止你的圖片直接出現在別人的網頁裡（或者防止mp3直接被其他網站嵌入到 flash播放機裡），不過訪客使用下載工具還是可以輕鬆下載，因為現在的下載工具一般會自動用你的功能變數名稱構造一個引用位址，所以如果想再進一步防範的話，可以使用一個對應表限制每個資源的引用位址，例如將 jacky.mp3 的引用地址限制為 http://uushare.com/abc.htmlid=12345，這樣下載工具就不太可能構造一個“正確”的引用位址了。
方法2：使用登錄驗證
這個方法常見於論壇、社區。當訪客請求網站上的一個資源時，先判斷此請求是否通過登錄驗證（在asp.net裡常用session或form驗證來記錄登錄狀態），如果尚未登錄則返回一個錯誤提示資訊。使用這個方法還可以進一步判斷登錄的用戶的許可權是否足夠，以實現帶“許可權”的下載。
不過因為登錄狀態依賴於會話id，而會話id往往儲存於http請求的cookie欄位裡，下載工具一般沒法獲得流覽器的cookie欄位，所以這些資源往往無法使用下載工具來下載，給正常合法用戶帶來諸多不便（因為大部分線民的系統都安裝了下載工具，一點擊下載連結一般會被下載工具攔截，導致無法使用流覽器本身的下載功能）。簡單的解決方法是將這個session id放到URL中。
這種方法的另外一個缺點是訪客無法匿名下載，所以這個方法一般只用於論壇和社區網站。
方法3：使用cookie
其實這種方法原理上跟方法2差不多。就是在顯示“下載”連結的頁面裡產生一個動態值的cookie，然後在處理資源下載請求時先判斷cookie裡有沒有正確的cookie，如果沒有則返回錯誤提示資訊。至於這個動態值如何產生，只要能逆向判斷動態值是否合法的都可以，例如將當前的時間去除秒數取雜湊值（也叫散列值）。如果網頁程式是asp.net則更簡單，可以往Session裡隨便存一個字串或數位，然後在處理下載請求時先檢查Session 裡是否存在這個字串或數位。使用這個方法的缺點跟方法2一樣。
方法4：使用POST下載
用戶端流覽器請求資源都是使用HTTP的GET方法的，其實使用POST方法也可以往用戶端返回資料。所以可以將下載連結換成一個表單（Form）和一個按鈕(Submit)，將待下載的檔的名稱或id放到表單的一個隱藏文字方塊（Input）裡，當使用者點擊提交按鈕時，服務程式先判斷請求是否為 POST方式，如果是則讀取目標資源的二進位資料並寫入響應物件（在asp.net裡是respone.BinaryWrite方法）。
使用這個方法的缺點同樣是無法使用下載工具，更沒法實現中斷點續傳。 不過比方法2，3好一點的是，下載工具不會攔截你的下載動作，所以正常用戶還是比較順暢地下載到檔。這個方法比較適合小檔的下載。
方法5：使用圖形驗證碼
使用這個方法可以保證每次下載都是“人”在你的網站上下載，而不是下載工具。因為網上很多介紹使用圖形驗證碼的方法，所以這裡就不再重複了。這個方法的缺點是比較容易讓正常的用戶感到麻煩。
方法6：使用動態檔案名
也叫動態鑰匙法，當使用者點擊一個下載連結時，先在程式端計算一個Key（使用一定規律產生的Key，最好不要使用隨機字串例如GUID，並且這個 Key必須有一定時效的），然後在資料庫或Cache裡記錄這個Key以及它所對應的資源ID或檔案名，最後讓網頁重定向一個新的URL位址，這個新 URL位址裡需要包含這個Key。當流覽器或下載工具發出下載請求時，程式先檢測這個Key是否存在，如果存在則返回對應的資來源資料。
使用這個方法的好處是下載工具也可以下載，並且在Key失效前可以中斷點續傳，並且可以通過Key來控制下載的執行緒數。
使用這個方法（包括以上所有支持下載工具的方法）的缺點是：當任意一個用戶下載成功之後，你的資源就會被一些下載工具列入“資源候選名單”，以後其他人在其他地方下載同樣的檔時，下載工具會不斷連接你的伺服器，即使你的檔已經刪除或者Key已經失效了，這樣會造成類DDos攻擊的後果，下面再介紹兩個即可以讓下載工具下載，又可以防止盜鏈的方法。
方法7：擅改資源的內容
一般熱門的資源都是電影、mp3、較大的壓縮包等，這些檔都是有很多可以插入資料的地方的，例如mp3有一個tag區，rar/zip有一個備註區，電影的內容隨便一個地方，只要在下載過程當中，動態地往這些地方注入一些隨機的位元組（幾個位元組即可），就可以達到讓整個檔的雜湊值（即散列值、指紋值）發生改變，讓從你網站下載的檔的雜湊值跟別人的不一樣，就可以防止下載工具主動找上門了。用這個方法配合方法6，可以達到較好的防盜鏈的效果。缺點是，雖然檔被修改的部分不會被“看”、“聽”出來，不過多多少少讓知道的人覺得不爽。另外就是如果別人把從你網站下載的檔放到其他網站，那麼仍然存在下載工具主動找上門的情況（雖然實際上它下載不了內容）。
方法8：打包下載
這個方法跟方法7的道理是一樣的，只不過這次不是往原始檔裡修改，而是在原始的檔基礎上再加個“外殼”，讓資源的雜湊值跟別人的不一樣。使用這個方法可以在不擅改資源原始的內容基礎上實現方法6同樣的效果，並且狠一點的話，甚至可以在打包的時候放入自己的一些廣告。缺點是使用者每次下載都得加壓縮，不過目前大部分人都懂得解壓，所以這個缺點有時可以忽略不計。
網站資源被盜鏈簡單來說就是別人不是從你的網站通過下載資源，被盜鏈的幾種可能情況：
1、在人氣非常旺的網站、論壇、社區的網頁裡直接引用了（使用標記）你網站上的圖片，或者直接在其他網頁（使用flash或媒體播放外掛程式）裡嵌入了你網站上的mp3。
2、在人氣非常旺的網站、論壇、社區裡提供了你的資源的下載地址。
3、你網站的資源可能被一些下載軟體列入了“資源候選名單”，當其他人用下載工具下載相同的檔時，下載軟體會自動找上門並且從你的伺服器下載。
既然被盜鏈的後果這麼可怕，那有哪些方法可以防止盜鏈呢下面從簡到繁總結一下常見的以及自己實踐過的一些方法，並簡單分析一下。不過很遺憾地，這些方法都沒法完全杜絕被盜鏈，並且防盜鏈的目的應該是從一定的程度上減少被盜鏈所產生的影響，同時能讓合法的使用者能夠以自然的方式、順暢地從你的網站下載資源。
方法1：判斷引用地址
這個方法是最早及最常見的方法。所謂判斷引用位址，就是判斷流覽器請求時HTTP頭的Referer欄位的值，這個值在asp.net裡面可以用 Request.UrlReferrer屬性取得。幾個例子來說，在正常情況下當使用者在流覽 http://uushare.com/abc.html 時點擊一個連結去到 http://uushare.com/jacky.mp3 檔時，流覽器在發出請求jacky.mp3 資源時還會附帶當刻流覽器所處的頁面位址（即http://uushare.com/abc.html），所以當你的網站程式接收到下載 jacky.mp3 資源請求的時候，先判斷http的referer欄位的值，如果是從 自己的功能變數名稱（uushare.com）過來的，則可以認為是合法的連接請求，否則就返回一個錯誤的提示資訊。
這種方法通常用於圖片、 mp3這種容易被人用html“嵌入”到其他網站的資源，使用這種方法可以防止你的圖片直接出現在別人的網頁裡（或者防止mp3直接被其他網站嵌入到 flash播放機裡），不過訪客使用下載工具還是可以輕鬆下載，因為現在的下載工具一般會自動用你的功能變數名稱構造一個引用位址，所以如果想再進一步防範的話，可以使用一個對應表限制每個資源的引用位址，例如將 jacky.mp3 的引用地址限制為 http://uushare.com/abc.htmlid=12345，這樣下載工具就不太可能構造一個“正確”的引用位址了。
方法2：使用登錄驗證
這個方法常見於論壇、社區。當訪客請求網站上的一個資源時，先判斷此請求是否通過登錄驗證（在asp.net裡常用session或form驗證來記錄登錄狀態），如果尚未登錄則返回一個錯誤提示資訊。使用這個方法還可以進一步判斷登錄的用戶的許可權是否足夠，以實現帶“許可權”的下載。
不過因為登錄狀態依賴於會話id，而會話id往往儲存於http請求的cookie欄位裡，下載工具一般沒法獲得流覽器的cookie欄位，所以這些資源往往無法使用下載工具來下載，給正常合法用戶帶來諸多不便（因為大部分線民的系統都安裝了下載工具，一點擊下載連結一般會被下載工具攔截，導致無法使用流覽器本身的下載功能）。簡單的解決方法是將這個session id放到URL中。
這種方法的另外一個缺點是訪客無法匿名下載，所以這個方法一般只用於論壇和社區網站。
方法3：使用cookie
其實這種方法原理上跟方法2差不多。就是在顯示“下載”連結的頁面裡產生一個動態值的cookie，然後在處理資源下載請求時先判斷cookie裡有沒有正確的cookie，如果沒有則返回錯誤提示資訊。至於這個動態值如何產生，只要能逆向判斷動態值是否合法的都可以，例如將當前的時間去除秒數取雜湊值（也叫散列值）。如果網頁程式是asp.net則更簡單，可以往Session裡隨便存一個字串或數位，然後在處理下載請求時先檢查Session 裡是否存在這個字串或數位。使用這個方法的缺點跟方法2一樣。
方法4：使用POST下載
用戶端流覽器請求資源都是使用HTTP的GET方法的，其實使用POST方法也可以往用戶端返回資料。所以可以將下載連結換成一個表單（Form）和一個按鈕(Submit)，將待下載的檔的名稱或id放到表單的一個隱藏文字方塊（Input）裡，當使用者點擊提交按鈕時，服務程式先判斷請求是否為 POST方式，如果是則讀取目標資源的二進位資料並寫入響應物件（在asp.net裡是respone.BinaryWrite方法）。
使用這個方法的缺點同樣是無法使用下載工具，更沒法實現中斷點續傳。 不過比方法2，3好一點的是，下載工具不會攔截你的下載動作，所以正常用戶還是比較順暢地下載到檔。這個方法比較適合小檔的下載。
方法5：使用圖形驗證碼
使用這個方法可以保證每次下載都是“人”在你的網站上下載，而不是下載工具。因為網上很多介紹使用圖形驗證碼的方法，所以這裡就不再重複了。這個方法的缺點是比較容易讓正常的用戶感到麻煩。
方法6：使用動態檔案名
也叫動態鑰匙法，當使用者點擊一個下載連結時，先在程式端計算一個Key（使用一定規律產生的Key，最好不要使用隨機字串例如GUID，並且這個 Key必須有一定時效的），然後在資料庫或Cache裡記錄這個Key以及它所對應的資源ID或檔案名，最後讓網頁重定向一個新的URL位址，這個新 URL位址裡需要包含這個Key。當流覽器或下載工具發出下載請求時，程式先檢測這個Key是否存在，如果存在則返回對應的資來源資料。
使用這個方法的好處是下載工具也可以下載，並且在Key失效前可以中斷點續傳，並且可以通過Key來控制下載的執行緒數。
使用這個方法（包括以上所有支持下載工具的方法）的缺點是：當任意一個用戶下載成功之後，你的資源就會被一些下載工具列入“資源候選名單”，以後其他人在其他地方下載同樣的檔時，下載工具會不斷連接你的伺服器，即使你的檔已經刪除或者Key已經失效了，這樣會造成類DDos攻擊的後果，下面再介紹兩個即可以讓下載工具下載，又可以防止盜鏈的方法。
方法7：擅改資源的內容
一般熱門的資源都是電影、mp3、較大的壓縮包等，這些檔都是有很多可以插入資料的地方的，例如mp3有一個tag區，rar/zip有一個備註區，電影的內容隨便一個地方，只要在下載過程當中，動態地往這些地方注入一些隨機的位元組（幾個位元組即可），就可以達到讓整個檔的雜湊值（即散列值、指紋值）發生改變，讓從你網站下載的檔的雜湊值跟別人的不一樣，就可以防止下載工具主動找上門了。用這個方法配合方法6，可以達到較好的防盜鏈的效果。缺點是，雖然檔被修改的部分不會被“看”、“聽”出來，不過多多少少讓知道的人覺得不爽。另外就是如果別人把從你網站下載的檔放到其他網站，那麼仍然存在下載工具主動找上門的情況（雖然實際上它下載不了內容）。
方法8：打包下載
這個方法跟方法7的道理是一樣的，只不過這次不是往原始檔裡修改，而是在原始的檔基礎上再加個“外殼”，讓資源的雜湊值跟別人的不一樣。使用這個方法可以在不擅改資源原始的內容基礎上實現方法6同樣的效果，並且狠一點的話，甚至可以在打包的時候放入自己的一些廣告。缺點是使用者每次下載都得加壓縮，不過目前大部分人都懂得解壓，所以這個缺點有時可以忽略不計。
2011年4月29日星期五
ASP.NET中如何防範SQL注入式攻擊
ASP.NET中如何防範SQL注入式攻擊
1將sql中使用的一些特殊符號，如' -- /* ; %等用Replace()過濾；
2限制文字方塊輸入字元的長度；
3檢查用戶輸入的合法性；用戶端與伺服器端都要執行，可以使用正則。
4使用帶參數的SQL語句形式。
ASP.NET中如何防範SQL注入式攻擊
一、什麼是SQL注入式攻擊？
所謂SQL注入式攻擊，就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字串，欺騙伺服器執行惡意的SQL命令。在某些表單中，使用者輸入的內容直接用來構造（或者影響）動態SQL命令，或作為存儲過程的輸入參數，這類表單特別容易受到SQL注入式攻擊。常見的SQL注入式攻擊過程類如：
⑴ 某個ASP.NET Web應用有一個登錄頁面，這個登錄頁面控制著使用者是否有權訪問應用，它要求使用者輸入一個名稱和密碼。
⑵ 登錄頁面中輸入的內容將直接用來構造動態的SQL命令，或者直接用作存儲過程的參數。下麵是ASP.NET應用構造查詢的一個例子：
System.Text.StringBuilder query = new System.Text.StringBuilder(
"SELECT * from Users WHERE login = '")
.Append(txtLogin.Text).Append("' AND password='")
.Append(txtPassword.Text).Append("'");
⑶ 攻擊者在用戶名字和密碼輸入框中輸入"'或'1'='1"之類的內容。
⑷ 使用者輸入的內容提交給伺服器之後，伺服器運行上面的ASP.NET代碼構造出查詢用戶的SQL命令，但由於攻擊者輸入的內容非常特殊，所以最後得到的SQL命令變成：SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'。
⑸ 伺服器執行查詢或存儲過程，將使用者輸入的身份資訊和伺服器中保存的身份資訊進行對比。
⑹ 由於SQL命令實際上已被注入式攻擊修改，已經不能真正驗證使用者身份，所以系統會錯誤地授權給攻擊者。
如果攻擊者知道應用會將表單中輸入的內容直接用於驗證身份的查詢，他就會嘗試輸入某些特殊的SQL字串篡改查詢改變其原來的功能，欺騙系統授予存取權限。
系統環境不同，攻擊者可能造成的損害也不同，這主要由應用訪問資料庫的安全許可權決定。如果用戶的帳戶具有管理員或其他比較高級的許可權，攻擊者就可能對資料庫的表執行各種他想要做的操作，包括添加、刪除或更新資料，甚至可能直接刪除表。
二、如何防範？
好在要防止ASP.NET應用被SQL注入式攻擊闖入並不是一件特別困難的事情，只要在利用表單輸入的內容構造SQL命令之前，把所有輸入內容過濾一番就可以了。過濾輸入內容可以按多種方式進行。
⑴ 對於動態構造SQL查詢的場合，可以使用下面的技術：
第一：替換單引號，即把所有單獨出現的單引號改成兩個單引號，防止攻擊者修改SQL命令的含義。再來看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”顯然會得到與“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的結果。
第二：刪除使用者輸入內容中的所有連字號，防止攻擊者構造出類如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之類的查詢，因為這類查詢的後半部分已經被注釋掉，不再有效，攻擊者只要知道一個合法的用戶登錄名稱，根本不需要知道使用者的密碼就可以順利獲得存取權限。
第三：對於用來執行查詢的資料庫帳戶，限制其許可權。用不同的使用者帳戶執行查詢、插入、更新、刪除操作。由於隔離了不同帳戶可執行的操作，因而也就防止了原本用於執行SELECT命令的地方卻被用於執行INSERT、UPDATE或DELETE命令。
⑵ 用存儲過程來執行所有的查詢。SQL參數的傳遞方式將防止攻擊者利用單引號和連字號實施攻擊。此外，它還使得資料庫許可權可以限制到只允許特定的存儲過程執行，所有的用戶輸入必須遵從被調用的存儲過程的安全上下文，這樣就很難再發生注入式攻擊了。
⑶ 限制表單或查詢字串輸入的長度。如果使用者的登錄名字最多只有10個字元，那麼不要認可表單中輸入的10個以上的字元，這將大大增加攻擊者在SQL命令中插入有害代碼的難度。
⑷ 檢查用戶輸入的合法性，確信輸入的內容只包含合法的資料。資料檢查應當在用戶端和伺服器端都執行——之所以要執行伺服器端驗證，是為了彌補用戶端驗證機制脆弱的安全性。
在用戶端，攻擊者完全有可能獲得網頁的原始程式碼，修改驗證合法性的腳本（或者直接刪除腳本），然後將非法內容通過修改後的表單提交給伺服器。因此，要保證驗證操作確實已經執行，唯一的辦法就是在伺服器端也執行驗證。你可以使用許多內建的驗證物件，例如RegularExpressionValidator，它們能夠自動生成驗證用的用戶端指令碼，當然你也可以插入伺服器端的方法調用。如果找不到現成的驗證物件，你可以通過CustomValidator自己創建一個。
⑸ 將使用者登錄名稱、密碼等資料加密保存。加密使用者輸入的資料，然後再將它與資料庫中保存的資料比較，這相當於對使用者輸入的資料進行了“消毒”處理，使用者輸入的資料不再對資料庫有任何特殊的意義，從而也就防止了攻擊者注入SQL命令。System.Web.Security.FormsAuthentication類有一個HashPasswordForStoringInConfigFile，非常適合於對輸入資料進行消毒處理。
⑹ 檢查提取資料的查詢所返回的記錄數量。如果程式只要求返回一個記錄，但實際返回的記錄卻超過一行，那就當作出錯處理。
1將sql中使用的一些特殊符號，如' -- /* ; %等用Replace()過濾；
2限制文字方塊輸入字元的長度；
3檢查用戶輸入的合法性；用戶端與伺服器端都要執行，可以使用正則。
4使用帶參數的SQL語句形式。
ASP.NET中如何防範SQL注入式攻擊
一、什麼是SQL注入式攻擊？
所謂SQL注入式攻擊，就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字串，欺騙伺服器執行惡意的SQL命令。在某些表單中，使用者輸入的內容直接用來構造（或者影響）動態SQL命令，或作為存儲過程的輸入參數，這類表單特別容易受到SQL注入式攻擊。常見的SQL注入式攻擊過程類如：
⑴ 某個ASP.NET Web應用有一個登錄頁面，這個登錄頁面控制著使用者是否有權訪問應用，它要求使用者輸入一個名稱和密碼。
⑵ 登錄頁面中輸入的內容將直接用來構造動態的SQL命令，或者直接用作存儲過程的參數。下麵是ASP.NET應用構造查詢的一個例子：
System.Text.StringBuilder query = new System.Text.StringBuilder(
"SELECT * from Users WHERE login = '")
.Append(txtLogin.Text).Append("' AND password='")
.Append(txtPassword.Text).Append("'");
⑶ 攻擊者在用戶名字和密碼輸入框中輸入"'或'1'='1"之類的內容。
⑷ 使用者輸入的內容提交給伺服器之後，伺服器運行上面的ASP.NET代碼構造出查詢用戶的SQL命令，但由於攻擊者輸入的內容非常特殊，所以最後得到的SQL命令變成：SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'。
⑸ 伺服器執行查詢或存儲過程，將使用者輸入的身份資訊和伺服器中保存的身份資訊進行對比。
⑹ 由於SQL命令實際上已被注入式攻擊修改，已經不能真正驗證使用者身份，所以系統會錯誤地授權給攻擊者。
如果攻擊者知道應用會將表單中輸入的內容直接用於驗證身份的查詢，他就會嘗試輸入某些特殊的SQL字串篡改查詢改變其原來的功能，欺騙系統授予存取權限。
系統環境不同，攻擊者可能造成的損害也不同，這主要由應用訪問資料庫的安全許可權決定。如果用戶的帳戶具有管理員或其他比較高級的許可權，攻擊者就可能對資料庫的表執行各種他想要做的操作，包括添加、刪除或更新資料，甚至可能直接刪除表。
二、如何防範？
好在要防止ASP.NET應用被SQL注入式攻擊闖入並不是一件特別困難的事情，只要在利用表單輸入的內容構造SQL命令之前，把所有輸入內容過濾一番就可以了。過濾輸入內容可以按多種方式進行。
⑴ 對於動態構造SQL查詢的場合，可以使用下面的技術：
第一：替換單引號，即把所有單獨出現的單引號改成兩個單引號，防止攻擊者修改SQL命令的含義。再來看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”顯然會得到與“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的結果。
第二：刪除使用者輸入內容中的所有連字號，防止攻擊者構造出類如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之類的查詢，因為這類查詢的後半部分已經被注釋掉，不再有效，攻擊者只要知道一個合法的用戶登錄名稱，根本不需要知道使用者的密碼就可以順利獲得存取權限。
第三：對於用來執行查詢的資料庫帳戶，限制其許可權。用不同的使用者帳戶執行查詢、插入、更新、刪除操作。由於隔離了不同帳戶可執行的操作，因而也就防止了原本用於執行SELECT命令的地方卻被用於執行INSERT、UPDATE或DELETE命令。
⑵ 用存儲過程來執行所有的查詢。SQL參數的傳遞方式將防止攻擊者利用單引號和連字號實施攻擊。此外，它還使得資料庫許可權可以限制到只允許特定的存儲過程執行，所有的用戶輸入必須遵從被調用的存儲過程的安全上下文，這樣就很難再發生注入式攻擊了。
⑶ 限制表單或查詢字串輸入的長度。如果使用者的登錄名字最多只有10個字元，那麼不要認可表單中輸入的10個以上的字元，這將大大增加攻擊者在SQL命令中插入有害代碼的難度。
⑷ 檢查用戶輸入的合法性，確信輸入的內容只包含合法的資料。資料檢查應當在用戶端和伺服器端都執行——之所以要執行伺服器端驗證，是為了彌補用戶端驗證機制脆弱的安全性。
在用戶端，攻擊者完全有可能獲得網頁的原始程式碼，修改驗證合法性的腳本（或者直接刪除腳本），然後將非法內容通過修改後的表單提交給伺服器。因此，要保證驗證操作確實已經執行，唯一的辦法就是在伺服器端也執行驗證。你可以使用許多內建的驗證物件，例如RegularExpressionValidator，它們能夠自動生成驗證用的用戶端指令碼，當然你也可以插入伺服器端的方法調用。如果找不到現成的驗證物件，你可以通過CustomValidator自己創建一個。
⑸ 將使用者登錄名稱、密碼等資料加密保存。加密使用者輸入的資料，然後再將它與資料庫中保存的資料比較，這相當於對使用者輸入的資料進行了“消毒”處理，使用者輸入的資料不再對資料庫有任何特殊的意義，從而也就防止了攻擊者注入SQL命令。System.Web.Security.FormsAuthentication類有一個HashPasswordForStoringInConfigFile，非常適合於對輸入資料進行消毒處理。
⑹ 檢查提取資料的查詢所返回的記錄數量。如果程式只要求返回一個記錄，但實際返回的記錄卻超過一行，那就當作出錯處理。
2011年4月26日星期二
企業網站建設方法論
1.企業網站需要靈魂
伴隨互聯網的飛速普及，及相關建站軟體的日新月異，現如今建設一個企業網站已相當容易，即使是對技術一竅不通的小白也能依靠智慧軟體信手拈來，所以說，科技很給力。通過觀察不難發現，依靠上述這種簡單粗暴方式建設網站的企業不再少數，尤其是中小企業，分析原因有三個：一是與其“短平快”的經營思路有關；二是成本低廉；三是不重視。
上周與國內某知名網站建設專家討論企業網站建設話題，其中談到的一點至今仍記憶猶新：企業網站需要靈魂。可以判斷：依靠上述那種依靠智慧軟體或簡單抄襲完成的網站一定是缺少靈魂的。
那如何才能建立一個有靈魂的企業網站呢？在這之前，我們需要先知曉何為企業網站的靈魂？簡單說來就是：邏輯，想使用者之所想的邏輯，有效傳遞品牌價值的邏輯。
如何才能做到想用戶之所想，並有效傳遞品牌價值呢？
乍一想，可能會感覺無從下手，其實就是缺少方法論。剛剛在最新一期《銷售與市場》雜誌上看到一句很貼切的形容“模式”的話，即：有地圖者不迷路，有模式者不盲目。沒錯，模式，或者說方法論其實就是做事情的指南針。
最近怠慢了博客更新，主要原因也是忙於公司網站改版，週末了，梳理梳理思路，也對近一段時間網站建設籌備工作做一個小總結、小分享。
2.企業網站建設方法論
近期與Google、百度兩位同學打交道比較多，以下是在兩位童鞋幫助下，集思廣益後總結整理出的一套有效的企業網站建設方法論，希望對各位熱愛網站運營的朋友有所參考價值，也歡迎各位拍磚、發言。
第一步：目標明確
建站之前首先要明確企業網站的目的是什麼，期待企業官網做什麼？如：是線上銷售？品牌資訊傳遞？資訊查詢？
第二步：策略分析
明確網站目標後，要開始目標受眾分析（來企業網站做什麼，興趣點是什麼）、自身現狀分析（品牌影響力如何，產品線如何、服務水準如何）及行業競品調研（行業對手都在怎麼做）；
第三步：方案制定
通過綜合策略分析後，需要明確我們要做什麼（定義需求），以及如何實現。
第四步：專案執行
明確實現方案後，需要制定網站架構，開始創意設計、內容組織、程式開發等工作。
第五步：維護和提高
最後，網站上線後，還有更重要的工作：運營維護、資料監測、結果追蹤。這樣才能形成閉環，推動網站持續、穩定、向前發展。
純文字的介紹可能不太直觀，繪製了一張示意圖（如下），可以對上述一攬子方法論一目了然。按此思路執行，有血有肉有靈魂的企業網站將水到渠成。
伴隨互聯網的飛速普及，及相關建站軟體的日新月異，現如今建設一個企業網站已相當容易，即使是對技術一竅不通的小白也能依靠智慧軟體信手拈來，所以說，科技很給力。通過觀察不難發現，依靠上述這種簡單粗暴方式建設網站的企業不再少數，尤其是中小企業，分析原因有三個：一是與其“短平快”的經營思路有關；二是成本低廉；三是不重視。
上周與國內某知名網站建設專家討論企業網站建設話題，其中談到的一點至今仍記憶猶新：企業網站需要靈魂。可以判斷：依靠上述那種依靠智慧軟體或簡單抄襲完成的網站一定是缺少靈魂的。
那如何才能建立一個有靈魂的企業網站呢？在這之前，我們需要先知曉何為企業網站的靈魂？簡單說來就是：邏輯，想使用者之所想的邏輯，有效傳遞品牌價值的邏輯。
如何才能做到想用戶之所想，並有效傳遞品牌價值呢？
乍一想，可能會感覺無從下手，其實就是缺少方法論。剛剛在最新一期《銷售與市場》雜誌上看到一句很貼切的形容“模式”的話，即：有地圖者不迷路，有模式者不盲目。沒錯，模式，或者說方法論其實就是做事情的指南針。
最近怠慢了博客更新，主要原因也是忙於公司網站改版，週末了，梳理梳理思路，也對近一段時間網站建設籌備工作做一個小總結、小分享。
2.企業網站建設方法論
近期與Google、百度兩位同學打交道比較多，以下是在兩位童鞋幫助下，集思廣益後總結整理出的一套有效的企業網站建設方法論，希望對各位熱愛網站運營的朋友有所參考價值，也歡迎各位拍磚、發言。
第一步：目標明確
建站之前首先要明確企業網站的目的是什麼，期待企業官網做什麼？如：是線上銷售？品牌資訊傳遞？資訊查詢？
第二步：策略分析
明確網站目標後，要開始目標受眾分析（來企業網站做什麼，興趣點是什麼）、自身現狀分析（品牌影響力如何，產品線如何、服務水準如何）及行業競品調研（行業對手都在怎麼做）；
第三步：方案制定
通過綜合策略分析後，需要明確我們要做什麼（定義需求），以及如何實現。
第四步：專案執行
明確實現方案後，需要制定網站架構，開始創意設計、內容組織、程式開發等工作。
第五步：維護和提高
最後，網站上線後，還有更重要的工作：運營維護、資料監測、結果追蹤。這樣才能形成閉環，推動網站持續、穩定、向前發展。
純文字的介紹可能不太直觀，繪製了一張示意圖（如下），可以對上述一攬子方法論一目了然。按此思路執行，有血有肉有靈魂的企業網站將水到渠成。
訂閱：
文章 (Atom)