2011年12月20日星期二
[Security]SQL injection的簡介與預防
前言
『程式不是會動就好!』,在安全性上的設計,更是完全的貼切這句話。如果設計出在裸奔的網站(請參考黑大的文章),就算網站上的功能可以正常運作,但千瘡百孔的網站,可能淪為人家的玩物或是提款機。
SQL injection的問題,在前幾年掀起了不少次旋風,甚至包括現在可能還有一堆網站有著同樣的問題,要命的是,根本不需要到駭客等級,就可以把有SQL injection問題的網站搞掛。一個程式設計師寫出來的程式,最要不得的就是有SQL injection的問題,我個人認為那是程式設計師不夠專業,甚至不夠格的表現。這不需要多高深的技巧跟學問,要嘛就是程式設計師偷懶,要嘛就是還不夠專業。
這篇文章簡介一下,SQL injection的基本原理,以及基本的防範措施。
什麼是SQL injection
回到之前重構系列的第一篇文章:[ASP.NET]重構之路系列v1 – UI, Business logic, Data access概念分開
畫面:
需求:
當輸入的帳號密碼,在資料庫中有吻合的資料,代表帳號密碼是對的。(再強調一次,一般設計驗證密碼的部分,應該是透過畫面上輸入密碼的值進行hash,再與資料庫中該帳號所對應hash完的密碼比對,以保障密碼不是以明文存在於資料庫中,確保密碼無法被還原)
直覺設計且造成SQL injection問題的程式碼:
view source
print?
01 protected void Verify_Click(object sender, EventArgs e)
02 {
03 string connectionString = @"myConnectionString";
04 int count;
05 using (SqlConnection cn = new SqlConnection(connectionString))
06 {
07 cn.Open();
08 string sqlStatement = @"Select Count(1) From SomeTable Where ID= '" + this.Id.Text + "' AND Password= '" + this.Password.Text + "'";
09 SqlCommand sqlCommand = new SqlCommand(sqlStatement, cn);
10 count = (int)sqlCommand.ExecuteScalar();
11 }
12
13 this.Result.Text = (count > 0) ? "Pass" : "帳號或密碼錯誤";
14 }
這樣的程式碼會有什麼問題? 問題可大了! 假設我是壞人,知道或猜測這功能的SQL是這樣串的(大部分功能都很好猜的,猜錯了也不會被咬),那麼我只要在畫面上的Id,隨便輸入個值,接著在密碼的部分,輸入' OR 1=1; --
這時候,這一支聰明的功能就可以把完整的SQL statement組出來,變成:
view source
print?
1 Select Count(1) From SomeTable Where ID= '隨便輸入' AND Password ='' OR 1=1; --
輸入這樣的值代表什麼,代表所有畫面上的輸入值都無所謂,因為1=1恆等式一定會成立,且前面的condition為OR,所以可以把前面的where condition都忽略掉。後面再補上個分號,代表這一個SQL子句已經結束,最後再補上--,代表後面的sql為註解。
就這樣,最基本的SQL injection就成功了。是的,這個網站在裸奔了。
如果你以為,只有登入頁面會存在這樣的問題,或是這樣的問題影響不大,那就大錯特錯了。通常會寫出這樣程式的人,如果又都是自己設計,那洞就不只一個。首先,DB的存取帳號,可能就是預設的sa或admin,也就是權限開到最大。這時候的SQL injection要進DB做事,就跟進自己家廚房一樣,例如:
view source
print?
1 Select Count(1) From SomeTable Where ID= '隨便輸入' AND Password ='' OR 1=1; DROP DATABASE pubs --
恭喜你,你DB中的pubs這個DataBase就被Drop掉了。
駭客高興的話,也可以針對sysobjects跟syscolumns來瞭解你DB中有哪些table, 欄位,再比對一下網頁的資料,接著透過Update的語法,把相關的欄位資料加入一些html tag或惡意的程式碼,進而引發從SQL injection觸發的Cross-site Scripting(XSS攻擊),常見的結果就是連到那一頁時,可能被導到別頁,或是XX政府網站上被掛上特殊的國旗,再來就是莫名其妙的個資外洩。
這些情況充斥在我們的生活中,這一切的原罪,都是因為程式設計師的偷懶或不專業。
除了上述的例子,還可以怎麼瞭解SQL的組成?以ASP.NET來說,一樣,通常會寫出那樣有問題的程式,web.config可能也沒有設定custom error頁面,所以當程式出錯時,IIS就大剌剌的幫你把程式錯誤的資訊show在網頁上(就是黃頁的那個),要讓錯誤資訊是掛在SQL statement執行錯誤,是一件再簡單不過的事。所以,要瞭解該網頁的輸入和對應SQL的組成,根本不需要駭客等級就可以做。瞭解之後,要啟動SQL injection,也就只是易如反掌的事。
如何避免SQL injection
簡單的說,過濾輸入值。
但,攻擊手法相當多種,要過濾的字元組合可能一個都漏不得,所以自己設定黑名單來進行過濾,是一件非不得以才做的事。如果是用ASP.NET寫,那所有人的強烈建議,就是使用Parameters。
Parameter的用法相當簡單,這也是為什麼我前面會說,寫出SQL injection問題的程式碼,是一種偷懶的行為。
對應剛剛上面的範例,使用Parameter的方式來改寫:
view source
print?
01 protected void Verify_Click(object sender, EventArgs e)
02 {
03 string connectionString = @"myConnectionString";
04 var id = this.Id.Text;
05 var password = this.Password.Text;
06
07 int count;
08 using (SqlConnection cn = new SqlConnection(connectionString))
09 {
10 cn.Open();
11 string sqlStatement = @"Select Count(1) From SomeTable Where ID= @id AND Password= @password";
12 SqlCommand sqlCommand = new SqlCommand(sqlStatement, cn);
13
14 ////定義parameter型別
15 sqlCommand.Parameters.Add("@id", SqlDbType.VarBinary);
16 sqlCommand.Parameters["@id"].Value = id;
17
18 ////讓ADO.NET自行判斷型別轉換
19 sqlCommand.Parameters.AddWithValue("@password", password);
20
21 count = (int)sqlCommand.ExecuteScalar();
22 }
23
24 this.Result.Text = (count > 0) ? "Pass" : "帳號或密碼錯誤";
25 }
透過使用parameter,在SqlCommand執行時,會自動過濾掉可能造成問題的字元。
另外,SQL injection並不只會發生在where condition,也有可能發生在Order by等語法中。所以只要是畫面上可能被改變的值,要串到SQL語法中,就應該使用parameter。如果是Parameter無法使用的語法,例如Table的名字,那也應該自己建立一個mapping module,來避免畫面上user可任意輸入且可能為惡意攻擊碼的值,直接存進DB中或被非預期地執行。
結論
在patterns & practices Developer Center簡單歸納出三個步驟防止SQL injection:
1. Constrain input.
2. Use parameters with stored procedures.
3. Use parameters with dynamic SQL.
2011年12月13日星期二
極速理解設計模式系列:簡單工廠模式(Simple Factory Pattern)
四個角色:抽象產品(Product)、具體產品(Concrete Product)、工廠(Creator)、用戶端(Client)
抽象產品(Product):需要創建的各種產品的父類。這類產品有共同的介面。
體產品(Concrete Product):需要創建的具體物件。
工廠(Creator):內部邏輯可以控制生成目標物件。
用戶端(Client):實例化工廠,然後工廠根據傳入參數得到各種產品。調用產品實現不同功能。
實現思路:首先將工廠產生實體,然後使用工廠創建產品賦值給抽象產品的引用,然後通過抽象產品的公共介面調用具體產品的方法以實現功能。
類圖:
應用場景:蘋果公司的工廠生產iphone 4、ipad 2、ipod nano 6。
分析:這裡多種產品都可以運行,所以有一個公共方法,然後抽象為父類。
下面我們在控制台程式去演示一下如何使用Simple Factory Pattern:
一、抽象產品(Product):
//抽象產品(Product)
abstract class Apple
{
public abstract void Run();
}
二、具體產品(Concrete Product):
//具體產品(Concrete Product)
class Iphone : Apple
{
public override void Run()
{
Console.WriteLine("iphone 4 開始運行!");
}
}
//具體產品(Concrete Product)
class Ipad : Apple
{
public override void Run()
{
Console.WriteLine("ipad 2 開始運行!");
}
}
//具體產品(Concrete Product)
class IpodNano : Apple
{
public override void Run()
{
Console.WriteLine("ipod Nano 6 開始運行!");
}
}
三、工廠(Creator):
//工廠(Creator)
class AppleFactory
{
public Apple CreateApple(string productName)
{
switch (productName.ToUpper())
{
case "IPHONE":
return new Iphone();
case "IPAD":
return new Ipad();
case "IPODNANO":
return new IpodNano();
default:
return null;
}
}
}
四、用戶端(Client):
//用戶端(Client)
class Program
{
static void Main(string[] args)
{
AppleFactory factory = new AppleFactory();
Apple iphone= factory.CreateApple("iphone");
iphone.Run();
Apple ipad = factory.CreateApple("ipad");
ipad.Run();
Apple ipodnano = factory.CreateApple("ipodnano");
ipodnano.Run();
Console.ReadLine();
}
}
2011年12月5日星期一
網站常用技巧
1.不管是IE那個版本都規定為IE8使用
2. 關閉自動完成功能
3.Title和keywords寫法
到底我們的Title屬性應該怎麼寫呢?我相信大部分人的網站title都是這樣寫的 網站名稱 - 所在網頁
這樣寫其實也沒有什麼,但是如果你想讓你的網站在從Google和Baidu過來更大的流量,我不建議只這樣寫,還應該把keywords完善
網站名稱|功能名稱|功能名稱的各種寫法
為什麼說是各種寫法呢,因為我們並不知道用戶是怎麼找到你網站的,也不清楚是根據什麼來找到的,比如HttpRequest
我們就可以這樣寫request|http|httpRequest等等,這樣你的網站被找到的幾率就會大在提高。
這個建議大家使用免費的站長統計工具來測試一下,現在的站長工具一般分析的都挺到位,比如http://www.51.la 會統計出來路,根據什麼關鍵字 ,來源IP等等大家可以自己查看一下。
然後你就可以根據使用者常用的關鍵字進行分析,來配置自己的網站,也許這就是簡單的SEo吧,呵呵,不過真正好的網站不能光靠這些,這是不夠的, 內容才是王道
4.網站的 description 我相信大部分人會忘記寫它,它們主要是用來做什麼的呢?
博客園 - 程式師的網上家園
不難看出來標題就是Title 而下面的說明就是description的值。大家應該知道怎麼寫了吧。
5.什麼樣的網站Seo最難優化
我個人認為目前Ajax的網站是最難優化的,因為Ajax的網站全是非同步的調用的,我們可以自己找一個Ajax的網站測試一下,當你調出了整個介面的 資訊時,你表面上看著是非常的多。
但實際是你右鍵看一下原始程式碼只有短短的幾行Js,那這樣的話,網路蜘蛛所抓取到的資訊也就只是一點點JS代碼。它可能會感覺你的網站沒有任何有 意義的東西,
自然權重和檢索量就會有一定的影響。
其實SEo最好優化的還是最基本的,所有資訊都鋪設在網頁 上,當然Ajax的方法,確實從客戶體驗上有大大的提升,也把好多壓力放在了用戶端。 具體要怎麼用,還得看大家的網站是做什麼的
如果對Seo要求不是太高的話,那就不需要管這些東西了。以客戶體驗為主。但相反的話而不然。
----------------常用功能我使用方法----------------
1. 將徹底遮罩滑鼠右鍵
oncontextmenu="window.event.returnValue=false"
用於Table
2. 取消選取、防止複製
3. 不准粘貼
onpaste="return false"
4. 防止複製
oncopy="return false;" oncut="return false;"
5. IE位址欄前換成自己的圖示
6. 可以在我的最愛中顯示出你的圖示
7. 關閉輸入法
8. 永遠都會帶著框架
9. 防止被人frame
10. 網頁將不能被另存為
11. 查看網頁原始程式碼
12.刪除時確認
刪除 刪除
13. 取得控制項的絕對位置
//Javascript //VBScript
14. 游標是停在文字方塊文字的最後
15. 判斷上一頁的來源 View Code
javascript: document.referrer 16. 最小化、最大化、關閉視窗 本例適用於IE
17.遮罩功能鍵Shift,Alt,Ctrl
18. 網頁不會被緩存
View Code
或者
19.怎樣讓表單沒有凹凸感?
或
20.
no |
&的區別?
(division)用來定義大段的頁面元素,會產生轉行 用來定義同一行內的元素,跟
的唯一區別是 不產生轉行 是ns的標記,ie不支援,相當於
21.讓快顯視窗總是在最上面:
22.不要捲軸? 讓豎條沒有:
讓橫條沒有:
兩個都去掉?更簡單了
23.怎樣去掉圖片連結點擊後,圖片周圍的虛線?
24.電子郵件處理提交表單
25.在打開的子視窗刷新父視窗的代碼裡如何寫?
window.opener.location.reload()
26.如何設定打開頁面的大小
打開頁面的位置
27.在頁面中如何加入不是滿鋪的背景圖片,拉動頁面時背景圖不動
28. 檢查一段字串是否全由數位組成
29. 獲得一個視窗的大小
document.body.clientWidth; document.body.clientHeight
30. 怎麼判斷是否是字元
if (/[^/x00-/xff]/g.test(s)) alert("含有漢字"); else alert("全是字元");
31.TEXTAREA自我調整文字行數的多少
32. 日期減去天數等於第二個日期
33. 選擇了哪一個Radio
View Code
Style Barcode
34.腳本永不出錯
35.ENTER鍵可以讓游標移到下一個輸入框
36. 檢測某個網站的連結速度: 把如下代碼加入
View Code
區域中:
37. 各種樣式的游標 auto :標準游標 default :標準箭頭 hand :手形游標 wait :等待游標 text :I形游標 vertical-text :水準I形游標 no-drop :不可拖動游標 not-allowed :無效游標 help :?幫助游標 all-scroll :三角方向標 move :移動標 crosshair :十字標 e-resize n-resize nw-resize w-resize s-resize se-resize sw-resize
38.頁面進入和退出的特效 進入頁面 推出頁面 這個是頁面被載入和調出時的一些特效。duration表示特效的持續時間 ,以秒為單位。transition表示使用哪種特效,取值為1-23: 0 矩形縮小 1 矩形擴大 2 圓形縮小 3 圓形擴大 4 下到上刷新 5 上到下刷新 6 左到右刷新 7 右到左刷新 8 豎百葉窗 9 橫百葉窗 10 錯位橫百葉窗 11 錯位豎百葉窗 12 點
擴散 13 左右到中間刷新 14 中間到左右刷新 15 中間到上下 16 上下到中間 17 右下到左上 18 右上到左下 19 左 上到右下 20 左下到右上 21 橫條 22 豎條 23 以上22種隨機選擇一種
39.在規定時間內跳轉
40.網頁是否被檢索 其中屬性值有以下一些: 屬性值為"all": 檔將被檢索,且頁上連結可被查 詢; 屬性值為"none": 檔不被檢索,而且不查詢頁上的連結; 屬性值為"index": 檔將被檢索; 屬性值為"follow": 查詢頁上的 連結; 屬性值為"noindex": 檔不檢索,但可被查詢連結; 屬性值為"nofollow": 檔不被檢索,但可查詢頁上的連結。
最大化視窗?
解決問題:由於層與下拉清單之間的優先順序是:下拉清單 > 層,因此在顯示的時候,會因為優先順序的次序而會出現如上問題。(如果幾個元素都是層的話 ,我們可以通過層的 z-index 屬性來設置)解決辦法就是:給層中放一個優先順序比下拉清單更高的元素(iframe),從而解決此問題!具體解決代碼如 下:
menu
輸入框也可以做的很漂亮了 head
View Code
注意:這段代碼是在新建檔中的
這個可不是
item 1 |
item 2 |
item 3 |
item 4 |
item 5 |
外向數: 沒回答的題數:
總得分: 結 論:
注意:修 改為即為打開最大
化視窗,而如果改為就變為視窗一打開就最小化
頁面自動刷新(說明)
當你做網頁時,是不是有的時候想讓你的網頁自動不停刷新,或者過一段時間自動跳轉到另外一個你自己設定的頁面?其實實現這個效果非常地簡單
,而且這個效果甚至不能稱之為特效。你只要把如下代碼加入你的網頁中就可以了。
1,頁面自動刷新:把如下代碼加入區域中,其中20指每隔20秒刷新一次頁面.
2,頁面自動跳轉:把如下代碼加入區域中,其中20指隔20秒 後跳轉到http://www.williamlong.info/頁面。
頁面自動關閉
5000是指時間
快顯視窗自動關閉
10秒後快顯視窗自動關閉
注意:在新的tan.htm的body中要加 總得分: 結 論:
2011年11月5日星期六
【高性能web開發】 ASP.NET Web伺服器
本文通過一個特別的案例:最終用戶使用流覽器向伺服器請求包含100條最新新聞紀錄的頁面,慢慢的展開。
本文集中在ASP.NET Web伺服器(特指用於接收使用者請求,處理業務邏輯和回應HTML的伺服器; 分散式,用戶端,IIS,資料庫和應用伺服器配置和優化部分,稍後介紹)
應用程式級別
1.生產環境使用Release版本,而不是Debug版本
•關閉所有調試日誌和資訊
•移除所有用於調試,測試和跟蹤的代碼
•使用宏操作可以很方便的關閉和管理這些代碼
•
#if DEBUG
Console.WriteLine("");//日誌?輸出?調試?#endif
•配置Web.Config關閉調試模式
2.移除不必要的HTTP Module
•通過運行時訪問HttpContext.Current.ApplicationInstance.Modules確定使用到的Module
•通過web.config移除不必要的HTTP Module
•例如如果你不想使用Session那麼就移除SessionModule • 本案例中,由於新聞資料和使用者無關,也許我們可以移除很多Module
3.移除不必要的檔
•特別是沒用的dll和PDB檔
4.啟用伺服器配置
•例如GC運行於伺服器模式
5.檢查Global等全域性代碼和功能
頁面級別
1.考慮使用比Aspx羽量級的處理模式,例如ashx(httphandler)
•例如需要一個頁面作為介面提供或者接收資料,(而不是返回一堆HTML)
•aspx頁面生命週期過於笨重,速度緩慢
•aspx內部經常使用伺服器控制項,這也是重量級的主
•aspx內部伺服器控制項產生的ViewState等。。。。
•個人比較喜歡MVC做頁面和WCF做服務
2.避免使用重量級解決方案
•Asp.net UpdatePanel (這東西搞搞管理員模組也就算了,就不要拿到最終使用者介面來嚇人了)
•EXT,ComponentArt等重量級協力廠商解決方案
3.避免太深的頁面或者類繼承(例如APage:BPage....)
•不要設計超級父類,集中了一大堆功能
•繼承級別過深是較為消耗性能的
4.優化邏輯
•例如已經在PageLoad中初始化過的物件,不要在例如按鈕點擊等事件中再初始化一次
•例如不要有這種代碼。。。
•
DataSet ds = new DataSet();// 無奈的初始化。。。。偶爾還能看到非常重量級的初始化 ds = ClassA.LoadDataSet();
5.小心使用重量級資源,包括但不僅限於以下內容
•Thread
•Sesssion
•Application
•內核鎖
•記憶體
•大量小物件 (GC壓力,例如大量的使用小字串),可以使用WinDbg+SOS調查
6.設計往往對與性能有至關重要的影響
•例如長時間的操作,非同步比同步性能要好很多
•例如大批量同類的操作,批量操作比一次操作一條要好的多
•CPU未滿,而且希望縮短回應時間,考慮多執行緒
•CPU滿了 考慮空間換時間
•CPU沒滿 考慮時間換空間 (注意 IO壓力大也會導致CPU100% 這個時候還是考慮空間換時間)
•例如設計時候考慮資料和樣式分離,每次只要重新拉資料就行了例如每次拉取資料的時候,伺服器只返回已經更新了的資料
•例如按照更新時間排列,如果更新了早一些的資料;那麼每次讀取的時候按照更新時間排列就是一個問題,不如在記憶體中保存最新的100條資料,有更新的話直接把該集合中最舊的一條移除,最新的一條插入 (可以多留幾條備用)
•這個例子一般是讀多寫少,讀寫比例可能達到1000:1,是很好的使用緩存的例子
緩存
1.頁面緩存和頁面片段緩存
<%@ OutputCache Duration="60" VaryByParam="none"%>
本文集中在ASP.NET Web伺服器(特指用於接收使用者請求,處理業務邏輯和回應HTML的伺服器; 分散式,用戶端,IIS,資料庫和應用伺服器配置和優化部分,稍後介紹)
應用程式級別
1.生產環境使用Release版本,而不是Debug版本
•關閉所有調試日誌和資訊
•移除所有用於調試,測試和跟蹤的代碼
•使用宏操作可以很方便的關閉和管理這些代碼
•
#if DEBUG
Console.WriteLine("");//日誌?輸出?調試?#endif
•配置Web.Config關閉調試模式
2.移除不必要的HTTP Module
•通過運行時訪問HttpContext.Current.ApplicationInstance.Modules確定使用到的Module
•通過web.config移除不必要的HTTP Module
•例如如果你不想使用Session那麼就移除SessionModule • 本案例中,由於新聞資料和使用者無關,也許我們可以移除很多Module
3.移除不必要的檔
•特別是沒用的dll和PDB檔
4.啟用伺服器配置
•例如GC運行於伺服器模式
5.檢查Global等全域性代碼和功能
頁面級別
1.考慮使用比Aspx羽量級的處理模式,例如ashx(httphandler)
•例如需要一個頁面作為介面提供或者接收資料,(而不是返回一堆HTML)
•aspx頁面生命週期過於笨重,速度緩慢
•aspx內部經常使用伺服器控制項,這也是重量級的主
•aspx內部伺服器控制項產生的ViewState等。。。。
•個人比較喜歡MVC做頁面和WCF做服務
2.避免使用重量級解決方案
•Asp.net UpdatePanel (這東西搞搞管理員模組也就算了,就不要拿到最終使用者介面來嚇人了)
•EXT,ComponentArt等重量級協力廠商解決方案
3.避免太深的頁面或者類繼承(例如APage:BPage....)
•不要設計超級父類,集中了一大堆功能
•繼承級別過深是較為消耗性能的
4.優化邏輯
•例如已經在PageLoad中初始化過的物件,不要在例如按鈕點擊等事件中再初始化一次
•例如不要有這種代碼。。。
•
DataSet ds = new DataSet();// 無奈的初始化。。。。偶爾還能看到非常重量級的初始化 ds = ClassA.LoadDataSet();
5.小心使用重量級資源,包括但不僅限於以下內容
•Thread
•Sesssion
•Application
•內核鎖
•記憶體
•大量小物件 (GC壓力,例如大量的使用小字串),可以使用WinDbg+SOS調查
6.設計往往對與性能有至關重要的影響
•例如長時間的操作,非同步比同步性能要好很多
•例如大批量同類的操作,批量操作比一次操作一條要好的多
•CPU未滿,而且希望縮短回應時間,考慮多執行緒
•CPU滿了 考慮空間換時間
•CPU沒滿 考慮時間換空間 (注意 IO壓力大也會導致CPU100% 這個時候還是考慮空間換時間)
•例如設計時候考慮資料和樣式分離,每次只要重新拉資料就行了例如每次拉取資料的時候,伺服器只返回已經更新了的資料
•例如按照更新時間排列,如果更新了早一些的資料;那麼每次讀取的時候按照更新時間排列就是一個問題,不如在記憶體中保存最新的100條資料,有更新的話直接把該集合中最舊的一條移除,最新的一條插入 (可以多留幾條備用)
•這個例子一般是讀多寫少,讀寫比例可能達到1000:1,是很好的使用緩存的例子
緩存
1.頁面緩存和頁面片段緩存
<%@ OutputCache Duration="60" VaryByParam="none"%>
Using the Output Cache
Last generated on:
2.適當的使用使用304緩存,或者流覽器端緩存
3.使用HttpRuntimeCache緩存資料,或使用靜態物件緩存資料
•如果不需要控制過期時間,或者永不過期,建議用靜態物件緩存資料,Cache其實還是很重量的
4.就這個方案而言
•可以把這100條資料放在記憶體中,如果有更新的時候直接更新記憶體,需要讀取的時候直接從記憶體中讀取
•緩存的同步和更新永遠都是一個大問題,選擇不同的緩存取決於你所想要的性能和能承受的缺陷 (例如如果能接受1分鐘的的資料延遲,緩存)
•良好的執行緒同步知識,可以減少很多的BUG
代碼級別
1.將可能的類設計為封閉的(不可繼承)
•例如新聞的實體類
2.使用更為有效率的方法
•例如使用Request.QueryString[Key] 而不是Request[Key]
•例如Int.TryParse,而不是Int.Parse
•謹慎使用異常
2011年7月27日星期三
DotNet程式師面試問題評估
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區別?
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年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、百度兩位同學打交道比較多,以下是在兩位童鞋幫助下,集思廣益後總結整理出的一套有效的企業網站建設方法論,希望對各位熱愛網站運營的朋友有所參考價值,也歡迎各位拍磚、發言。
第一步:目標明確
建站之前首先要明確企業網站的目的是什麼,期待企業官網做什麼?如:是線上銷售?品牌資訊傳遞?資訊查詢?
第二步:策略分析
明確網站目標後,要開始目標受眾分析(來企業網站做什麼,興趣點是什麼)、自身現狀分析(品牌影響力如何,產品線如何、服務水準如何)及行業競品調研(行業對手都在怎麼做);
第三步:方案制定
通過綜合策略分析後,需要明確我們要做什麼(定義需求),以及如何實現。
第四步:專案執行
明確實現方案後,需要制定網站架構,開始創意設計、內容組織、程式開發等工作。
第五步:維護和提高
最後,網站上線後,還有更重要的工作:運營維護、資料監測、結果追蹤。這樣才能形成閉環,推動網站持續、穩定、向前發展。
純文字的介紹可能不太直觀,繪製了一張示意圖(如下),可以對上述一攬子方法論一目了然。按此思路執行,有血有肉有靈魂的企業網站將水到渠成。
2011年4月21日星期四
有理想的程式師必須知道的15件事
作為程式師,要取得非凡成就需要記住的15件事。
1、走一條不一樣的路
在有利於自己的市場中競爭,如果你滿足於“泯然眾人矣”,那恐怕就得跟那些低工資國家的程式師們同場競技了。
2、瞭解自己的公司
以我在醫院、諮詢公司、物流企業以及大技術公司工作的經驗來看,這一點所言不虛。
不同公司的運營模式差異極大。如果你理解企業的運營模式,那你就不一樣了!在這家公司中(或者對客戶而言),你是參與業務運營的資產,你的工作能直接產生效益!
3、與最優秀的人為伍
很早以前,我喜歡打籃球,被分配到一個水準比較高的隊裡。一開始適應的確很困難,但環境的壓力越大(重大比賽),我的長進也就越明顯。
每個領域其實都一樣:你周圍人的水準(以及對你的期望)越高,你就會變得越優秀。
4、製造差異
每年學習一門新程式設計語言。為什麼不呢?不斷嘗試新事物,你關注的技術種類越多,腳下的路就越寬廣,你的職業生涯就會日新月異。不知道幾年後Java的趨勢如何?那就學習Clojure。學Ruby還是Python?這兩種語言都可以試試啊。然後你才能知道哪種語言更適合某個特定的項目。看,掌握的語言多了,才能在需要的時候信手拈來吧。
5、畏懼,是最大的敵人
還是直接從書中摘一句吧:“在畏懼中做出的職業規劃,很可能會讓自己後半輩子就一直被‘圈禁’在小隔斷裡,永遠不會有創造明天輝煌的時刻。沒錯,那樣是安全,但有意思嗎?”
6、要成為多面手
如果你掌握了所在領域的知識,那你只能是一名專業人士。用PHP程式設計?花點時間設置一台Apache伺服器,讓PHP和MySQL都跑起來。一直在用jQuery?試試Prototype。你懂了吧。
7、一個字:做
別指望別人過來教你該怎麼做,出去,自己學著去做!
8、找一位好老師
找一位好老師可以讓你在學習技術的時候有的放矢。作者給我們講述了別人是怎麼指導他學習的(順便說一句,作者在這本書裡講了很多個人經歷的小故事,他居然從一位演奏家轉行來做軟體發展!):“好好研究一下目錄服務,熟悉一種UNIX變體,然後再掌握一門指令碼語言。”
請記住這句禪宗諺語:“循路覓宗師,形影不相離,師知吾亦知,吾乃成宗師。”
9、主動教會別人
教會別人是一種最好的學習方式。寫一篇博客能幫你搞清楚一個問題。為此,你必須先掌握很多材料,同時還要有條有理地講給別人聽(寫作技能)。如書中所言:“要想知道自己是不是真的明白,你就講給別人聽聽。”
10、實踐,實踐,再實踐(訓練)
只有進行大量實踐(花大量的時間)才能掌握某種技術。看的很多,寫的很少,遇到問題,改一改,又去讀代碼,……(這樣下去是不行的)。
要特別警惕拖延症。其實,往往只要有了開頭就好辦了。
自我加壓,效果會更好。我曾在一篇博客中提到帕金森定律:緊張的時限可以讓你提高工作效率。為什麼不把這個定律用到學習上呢,比如說在y時間內學會x?
11、從小處入手
每天都取得一項小成果,每天都要堅持做(寫在博客上?)。這樣一來,你只能讓自己比昨天更進步,而不能說自己比上星期進步了一點。
12、享受過程
關注當下,而不是目標,享受那些在追逐未來目標的途中可能無暇顧及的小勝利。人總要生活在當下。我享受程式設計的過程,就像享受程式設計的結果一樣。
13、不要喪失危機感
越是成功,就越容易犯重大錯誤。永遠不要忘了危機感,特別是要認識到你今天所知道的,到了明天可能就會一文不值。過去的榮耀不能保你永遠無虞。
據書中所說,你最好是要讓自己能夠“通用”,而不要對哪種技術或哪個公司產生依賴。你所掌握的某些技能,甚至你的工作,到了明天都可能會變得毫無價值。因此要不斷提高/豐富/擴展自己的技能。
14、推銷自己
為某個項目貢獻自己的一份力量,寫一篇博客,共用自己的原始程式碼,成為對某個社區有用的人。
當然,做這些事可能需要激情,要看你的愛好,但這些事也會間接地推廣你的工作成果,證明你的實力,提高你的知名度。
15、關注市場
書中還提到了“預警極客”,也就是那些始終引領技術發展的人。這些人說過的話往往帶有預見性,他們提到事物也許過幾天就會成為頭條新聞。關注這些人,常看他們的Twitter和博客。
1、走一條不一樣的路
在有利於自己的市場中競爭,如果你滿足於“泯然眾人矣”,那恐怕就得跟那些低工資國家的程式師們同場競技了。
2、瞭解自己的公司
以我在醫院、諮詢公司、物流企業以及大技術公司工作的經驗來看,這一點所言不虛。
不同公司的運營模式差異極大。如果你理解企業的運營模式,那你就不一樣了!在這家公司中(或者對客戶而言),你是參與業務運營的資產,你的工作能直接產生效益!
3、與最優秀的人為伍
很早以前,我喜歡打籃球,被分配到一個水準比較高的隊裡。一開始適應的確很困難,但環境的壓力越大(重大比賽),我的長進也就越明顯。
每個領域其實都一樣:你周圍人的水準(以及對你的期望)越高,你就會變得越優秀。
4、製造差異
每年學習一門新程式設計語言。為什麼不呢?不斷嘗試新事物,你關注的技術種類越多,腳下的路就越寬廣,你的職業生涯就會日新月異。不知道幾年後Java的趨勢如何?那就學習Clojure。學Ruby還是Python?這兩種語言都可以試試啊。然後你才能知道哪種語言更適合某個特定的項目。看,掌握的語言多了,才能在需要的時候信手拈來吧。
5、畏懼,是最大的敵人
還是直接從書中摘一句吧:“在畏懼中做出的職業規劃,很可能會讓自己後半輩子就一直被‘圈禁’在小隔斷裡,永遠不會有創造明天輝煌的時刻。沒錯,那樣是安全,但有意思嗎?”
6、要成為多面手
如果你掌握了所在領域的知識,那你只能是一名專業人士。用PHP程式設計?花點時間設置一台Apache伺服器,讓PHP和MySQL都跑起來。一直在用jQuery?試試Prototype。你懂了吧。
7、一個字:做
別指望別人過來教你該怎麼做,出去,自己學著去做!
8、找一位好老師
找一位好老師可以讓你在學習技術的時候有的放矢。作者給我們講述了別人是怎麼指導他學習的(順便說一句,作者在這本書裡講了很多個人經歷的小故事,他居然從一位演奏家轉行來做軟體發展!):“好好研究一下目錄服務,熟悉一種UNIX變體,然後再掌握一門指令碼語言。”
請記住這句禪宗諺語:“循路覓宗師,形影不相離,師知吾亦知,吾乃成宗師。”
9、主動教會別人
教會別人是一種最好的學習方式。寫一篇博客能幫你搞清楚一個問題。為此,你必須先掌握很多材料,同時還要有條有理地講給別人聽(寫作技能)。如書中所言:“要想知道自己是不是真的明白,你就講給別人聽聽。”
10、實踐,實踐,再實踐(訓練)
只有進行大量實踐(花大量的時間)才能掌握某種技術。看的很多,寫的很少,遇到問題,改一改,又去讀代碼,……(這樣下去是不行的)。
要特別警惕拖延症。其實,往往只要有了開頭就好辦了。
自我加壓,效果會更好。我曾在一篇博客中提到帕金森定律:緊張的時限可以讓你提高工作效率。為什麼不把這個定律用到學習上呢,比如說在y時間內學會x?
11、從小處入手
每天都取得一項小成果,每天都要堅持做(寫在博客上?)。這樣一來,你只能讓自己比昨天更進步,而不能說自己比上星期進步了一點。
12、享受過程
關注當下,而不是目標,享受那些在追逐未來目標的途中可能無暇顧及的小勝利。人總要生活在當下。我享受程式設計的過程,就像享受程式設計的結果一樣。
13、不要喪失危機感
越是成功,就越容易犯重大錯誤。永遠不要忘了危機感,特別是要認識到你今天所知道的,到了明天可能就會一文不值。過去的榮耀不能保你永遠無虞。
據書中所說,你最好是要讓自己能夠“通用”,而不要對哪種技術或哪個公司產生依賴。你所掌握的某些技能,甚至你的工作,到了明天都可能會變得毫無價值。因此要不斷提高/豐富/擴展自己的技能。
14、推銷自己
為某個項目貢獻自己的一份力量,寫一篇博客,共用自己的原始程式碼,成為對某個社區有用的人。
當然,做這些事可能需要激情,要看你的愛好,但這些事也會間接地推廣你的工作成果,證明你的實力,提高你的知名度。
15、關注市場
書中還提到了“預警極客”,也就是那些始終引領技術發展的人。這些人說過的話往往帶有預見性,他們提到事物也許過幾天就會成為頭條新聞。關注這些人,常看他們的Twitter和博客。
2011年4月11日星期一
想給有創業激情的程式師朋友們提供一點兒創業參考:
1:若想靠寫程式、做專案成功那基本上是選了艱難的創業道路,註定了失敗的概率是90%以上,一個軟體公司必須要有屬於自己的軟體產品,哪怕是再小的成熟產品也可以,賣出去的量大了也是一筆可觀的收入來源客戶人脈也會有了,最起碼公司沒單子沒項目也不會餓死,這方面我選擇了“通用許可權管理系統元件”每天可以有銷售業績,總不會淪落到餓死的程度,但是也不能指望靠這個吃個飽。
2:你必須要有一筆啟動資金,也不用很多例如有個20萬也可以,這錢最好是你自己賺來的而不是靠借來的,因為有賺錢的本事才適合經營公司,知道賺錢有多難後才有希望能經營好一家公司來幫大家一起賺錢,若是借來的錢就90%以上的概率等著賠個精光就可以了,然後再想辦法還錢就可以了。
3:創業你需要幾個死黨,他們願意跟你一起打拼,就是3個月公司沒收入也會繼續跟著你幹,3個月不發工資也不會跑路,不會因為別人能多給2000元的月薪就背叛了你和自己的公司,也不會因為其他雞毛竄皮的原因離你而去,創業最忌諱的是人員不穩定,心不齊,創業都需要一個艱難的摸索過程。
4:跟你創業的人也需要吃飯也需要養家糊口,並不是創業就是受苦受累不拿薪水,甚至是需要給創業的人更高的工資待遇,只有穩定的收入人家才會安心跟你一起創業,否則大家也不是SB,早晚都會跑光光的,人家憑什麼要跟你幹。
5:本來就賣不來錢的東西,不用非要等開了公司在嘗試賣錢,例如中國有14億人,1000人裡若有1個程式師,那就是1400000000人程式師是1400000,若10個人裡有一個購買通用許可權管理系統元件學習版本998元的,那就是14000套*998元==13972000元,其實賬算算都很可觀,但是未必會有10個人裡就有1個人購買,做生意沒那麼容易,讓別人購買你的東西非常難,把別人口袋裡的錢掏出來比登天還難一些。
6:想想是很好的事情,往往真實生活裡未必能行得通,就向通用許可權管理系統的推廣,也需要前後推廣10年才會真正佔領市場,需要一個長期的奮鬥,長期的宣傳,創業也是一樣,如不是技術高端或者市場新穎,否則都需要長久的奮鬥。
7:若現在打工時在公司裡混得一般,身邊的人對你的口碑一般,水準也一般,很難自己創業後就會有飛躍的變化,全國從南到北的人都差不多牛人都很多,甚至大家的水準都不差不多,更甚至大家的思想理念價值觀都差不多,現在的公司大家封建,到另外一家公司也同樣封建。
8:創業不能節約成本,該花錢要花,該買的東西要買,該用高薪的人就需要用高薪的人,否則不出活兒、折騰,用低成本的低能的開發人員其實就是浪費生命、浪費機會、浪費錢財,創業開公司不是為了省錢,是為了把事情做好,挖掘開拓更多的有價值的潛在客戶;帶著貓可以抓老鼠,想抓鹿就需要帶著老虎。
有一個很就簡單的例子,500元你那東西太貴了,我們公司有的是人,我讓開發人員開發6個月好了,何必購買你的東西,雖然開發出來的東西不太好用,但是也可以用,寧可讓一個開發人員開發6個月也不會捨得購買500元的軟體,甚至是誰服誰啊,我也能開發一個,我開發出來的會比你的還強,然後折騰2年後放棄了,就算開發出來了,也未必有長期推廣的能力。
若是產品,一個思想很好,想去推廣,想去創業,必須要考慮殘酷的事實,要經得起牛人的推敲,身邊的推廣實驗,效果的確良好,那就可以放手一搏是沒關係的,若連論證都經不起論證的,完全可以放棄創業,沒必要浪費寶貴的社會資源,該給誰打工就可以給誰打工了。
2:你必須要有一筆啟動資金,也不用很多例如有個20萬也可以,這錢最好是你自己賺來的而不是靠借來的,因為有賺錢的本事才適合經營公司,知道賺錢有多難後才有希望能經營好一家公司來幫大家一起賺錢,若是借來的錢就90%以上的概率等著賠個精光就可以了,然後再想辦法還錢就可以了。
3:創業你需要幾個死黨,他們願意跟你一起打拼,就是3個月公司沒收入也會繼續跟著你幹,3個月不發工資也不會跑路,不會因為別人能多給2000元的月薪就背叛了你和自己的公司,也不會因為其他雞毛竄皮的原因離你而去,創業最忌諱的是人員不穩定,心不齊,創業都需要一個艱難的摸索過程。
4:跟你創業的人也需要吃飯也需要養家糊口,並不是創業就是受苦受累不拿薪水,甚至是需要給創業的人更高的工資待遇,只有穩定的收入人家才會安心跟你一起創業,否則大家也不是SB,早晚都會跑光光的,人家憑什麼要跟你幹。
5:本來就賣不來錢的東西,不用非要等開了公司在嘗試賣錢,例如中國有14億人,1000人裡若有1個程式師,那就是1400000000人程式師是1400000,若10個人裡有一個購買通用許可權管理系統元件學習版本998元的,那就是14000套*998元==13972000元,其實賬算算都很可觀,但是未必會有10個人裡就有1個人購買,做生意沒那麼容易,讓別人購買你的東西非常難,把別人口袋裡的錢掏出來比登天還難一些。
6:想想是很好的事情,往往真實生活裡未必能行得通,就向通用許可權管理系統的推廣,也需要前後推廣10年才會真正佔領市場,需要一個長期的奮鬥,長期的宣傳,創業也是一樣,如不是技術高端或者市場新穎,否則都需要長久的奮鬥。
7:若現在打工時在公司裡混得一般,身邊的人對你的口碑一般,水準也一般,很難自己創業後就會有飛躍的變化,全國從南到北的人都差不多牛人都很多,甚至大家的水準都不差不多,更甚至大家的思想理念價值觀都差不多,現在的公司大家封建,到另外一家公司也同樣封建。
8:創業不能節約成本,該花錢要花,該買的東西要買,該用高薪的人就需要用高薪的人,否則不出活兒、折騰,用低成本的低能的開發人員其實就是浪費生命、浪費機會、浪費錢財,創業開公司不是為了省錢,是為了把事情做好,挖掘開拓更多的有價值的潛在客戶;帶著貓可以抓老鼠,想抓鹿就需要帶著老虎。
有一個很就簡單的例子,500元你那東西太貴了,我們公司有的是人,我讓開發人員開發6個月好了,何必購買你的東西,雖然開發出來的東西不太好用,但是也可以用,寧可讓一個開發人員開發6個月也不會捨得購買500元的軟體,甚至是誰服誰啊,我也能開發一個,我開發出來的會比你的還強,然後折騰2年後放棄了,就算開發出來了,也未必有長期推廣的能力。
若是產品,一個思想很好,想去推廣,想去創業,必須要考慮殘酷的事實,要經得起牛人的推敲,身邊的推廣實驗,效果的確良好,那就可以放手一搏是沒關係的,若連論證都經不起論證的,完全可以放棄創業,沒必要浪費寶貴的社會資源,該給誰打工就可以給誰打工了。
訂閱:
文章 (Atom)