一次C#用戶端與Java Web伺服器的互動經曆(求助)

來源:互聯網
上載者:User

  公司即將要做一套用戶端系統,C#開發。在用戶端中有很多涉及到money的地方,所以不得不與資料庫互動一下。

  問題由此而來,所以今天在陪伴我學習.net的部落格園求助。

   

  如果是公司內部使用一套用戶端系統,可能常見的方式就是通過用戶端直接連接內部的資料庫伺服器進行資料互動。由於是企業內部使用的原因,所以不需要考慮資料安全問題。可我們需要開發的是一套面向N位客戶的一套軟體,這樣我們就無法保證使用者的水平。如果從某個方面稍微發生一點失誤,我們的資料庫可能就直接被download掉了。畢竟串連資料庫的帳號和密碼可能是儲存在用戶端程式中的,通過反編譯的方式可以直接查看到所有串連資訊。即使加密,也有可能被解密掉。

  最初想到了一套模式,就是稍微複雜一點的用戶端對Web Service資料操作,這樣可以避免用戶端直接對資料庫操作,而且以後資料庫的改動也不會影響到用戶端,從各方面都很有優勢。在實施前團隊又對此方案進行了一系列討論及研究,最終還是被暫時pass掉。因為資料量大時,先對web伺服器互動得到結果就夠嗆了,還需要在解析xml,這也不是一件輕鬆的事。就這樣,開始去網上求助,最終也沒有得到好的結論。

   先放棄的資料互動的開發後開始的簡訊相關的業務,新的任務來了,通過華為的MAS系統進行簡訊發送。API都是華為提供好的,應該是C開發的API,難度到不是很大。可安全問題又來了,而且使用API的要求也比較bt,必須裝有db2的驅動程式。因為使用需要引用華為提供的dll,並且在使用時需要串連我們的企業帳號及硬體裝置。這樣一些敏感的串連資訊還是被暴漏在程式原始碼中,反編譯出源碼後還是會讓別人免費的發簡訊。不得不把簡訊相關業務封裝到Web Service了。公司的Web伺服器是已經配置好的Java環境,沒必要在去配置.net的。所以Web Service的開發我選擇了java中的XFire架構。沒必要的東西先不說了,給大家說說我的具體操作流程,幫我看看可能會存在什麼問題,畢竟我在技術方面不是很專,先謝謝各位了。

  直接讓用戶端與伺服器的Web Service互動肯定不是一個好辦法,如果使用者抓取到了Web Service的串連地址,這樣又讓人家免費玩了。所以我在初步設計時想到了在用戶端每次調用伺服器時用一個帳號密碼驗證,並將其進行加密。寫著寫著,發現問題又來了。用戶端去串連Web Service的最終原理肯定是http請求,這樣如果使用者攔截了原生所有請求就能馬上暴漏我們的Service地址和參數,然後直接自己寫個程式去類比這個請求,這樣不管在用戶端進行多麼進階的加密,還是會被直接繞過驗證。於事進化了我的想法,通過一個隨機的值每次發送到Web Service,然後Web Service去驗證。最初想到的是通過時間並加密的一個值去驗證,因為時間時唯一的,而且還能保證用戶端和伺服器一致。呵呵,過了一會還是pass掉了自己的想法,因為萬一用戶端與伺服器時間不一直,那此功能直接廢掉,因為時間不同步,加密出來的值不同,在加上網路的各種延遲,肯定會導致這個驗證方式不成立。

  因此,想法又進化了一步。從Web Service的初始化方法中產生一個NNID(C#中的GUID,java叫NNID)此ID被記錄,N分鐘後自動銷毀(銷毀後用戶端會從新執行個體化類,產生新的NNID),再從伺服器產生一個1-10以內的隨機數(做什麼後面會說)。然後從用戶端得到這個值,在為Web Service提供一個登陸方法,每次登陸都傳入一個從用戶端加密的值。至於這個用戶端加密的值,就是通過伺服器產生的NNID進行加密,加密的次數由上述說到的隨機數決定,假設隨機數為3,就加密3次。剛剛說的是從用戶端加密一個從伺服器產生的唯一值,所以我們需要從伺服器進行相同演算法和相同次數的加密,最終比較伺服器端的加密結果與用戶端產生的結果,如相同,則說明驗證成功!可能我這個方法比較笨,所以需要大家提供更多的意見。下面我來解釋一下為什麼要這麼做,我考慮到了如下幾點。

  1. 如按上面的方法進行互動,假設使用者得到了我的Web Service地址,那麼你還得去驗證,可能這時大家會想到我直接抓出你所有的請求參數,類比這個請求不就OK了嗎?剛才說到NNID會被記錄在某個地方,N分鐘會被自動銷毀。
  2. 假設使用者抓到了這個地址,那麼使用者也無法脫離了我的用戶端去直接使用我這個Web Service,因為我的NNID被加密了,他光知道還不行,而且NNID被加密的次數還是隨機的,他還要即時去掌握加密了多少次才能成功驗證。
  3. 可能使用者會反編譯我的程式,然後看看我是怎麼進行加密的。那我可以把我的密碼編譯演算法通過C++去實現,產生一個dll檔案,並對這個dll檔案進行加殼,防止反編譯,這樣就能保證我的密碼編譯演算法不泄露。
  4. 就算使用者可以脫離我的程式去使用,那麼使用者也只能使用N分鐘而已,因為N分鐘後就要銷毀這個ID了,這時使用者驗證就無法通過了。因為NNID號稱全球唯一的,出現重複的幾率非常低。而且我在伺服器對每次驗證都進行記錄,如果一旦發現某使用者驗證出現錯誤,那說明肯定存在問題,這時可以直接屏蔽掉這個使用者,不允許去使用。

  這就是我想到的方式,現在已經實現了,預想的效果跟我想象的一樣,就是在管理NNID時可能浪費一點記憶體,但我想以後應該可以進行最佳化,比如使用者多了可以儲存在資料庫中,這就是我很天真想法,我技術方面還不行,我真心希望部落格園的兄弟們能夠給我一些指點,我可能很多細節沒有考慮到,謝謝!

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.