這種情況，最容易解決的方案，就是使用https協議，我在上海的時候配過tomcat的https協議，不難，配置好了，CA與RA的兩個tomcat之間通訊數據就加密了。我們同樣可以使用這種方法解決其他類似的問題。不過服務器之間的https配置特別麻煩，現在還沒弄明白。
1.1.2 數據加密以及數據簽名
記得在做139郵箱的時候，我們所有的通訊數據，都用了base64編碼進行了處理。不過這種數據，能夠很容易的被解析出來，欺騙的隻是一些網絡小毛毛蟲而已，稍微有點編程基礎的，就能很快的解析出來，畢竟走的是標準的base64嘛。
現在做安全產品了，原來保證數據的安全就有很多方式哦。
在信息通信過程中，有四個基本的安全要素：一是機密性，通信是否機密的，是否能被攔截，通信的機密性無法保障，則對於個人的通信隱私無法保障；二是完整性，通信中的信息是否被篡改了？無法保障完整性，就無法保障通信過程的準確和有效；三是身份認證，通信的基本前提是我得知道是在和誰通信，在信息傳輸的開放互聯環境中，身份認證能否被偽造，無法確認身份，則無法實現信息交流和交互;四是不可抵賴，即交易的過程不被抵賴，特別是在電子商務、電子政務等過程中，通信的抗抵賴顯得尤其迫切。
第一種場景：首先女朋友和我約定一個共享密鑰，女朋友使用該密鑰進行信息的加密，然後通過公開環境進行傳輸，而我收到信息後，利用共享密鑰解密，得到“明晚西單見”的信息，就算被其他人截獲，沒有該共享密鑰，無法解密，也就無法知道信息的確切內容，保障了信息傳輸過程中的機密性。但是，該場景忽略了一個問題：女朋友和我的如何約定這個共享密鑰？需要一位紅娘通過線下的方式傳遞消息，在實際的 Internet通信中，沒有紅娘怎麼辦？我們可以引入另一類算法，非對稱算法，非對稱加密算法則很好的解決了這個問題。
第二種場景：我和女朋友利用非對稱密碼算法。即通信的雙方女朋友和我都各有一對密鑰，其中，對社會公布一個密鑰，稱公鑰；自己私自保護好另一個密鑰，稱為私鑰，通過公鑰加密的信息，可以通過私鑰來進行解密，通過私鑰加密的信息，可以通過公鑰來解密。女朋友要發送這個信息，可以通過公開途徑，得到我的公鑰，然後將信息通過我公鑰進行加密後得到密文，然後將信息傳給我，因為隻有我有私鑰，所以隻有我才能解開密文，得到明文信息，其他人得到密文，沒有私鑰，無法解密密文。這種通信方式也很好的保證了信息的機密性，而且相比較對稱密鑰的密鑰分發困難，非對稱密鑰對的公鑰可以通過公開途徑就能得到，不用擔心密鑰分發的問題。當然非對稱密鑰還有另外一種應用場景：我們看這個場景，也有個問題，那就是我如何能確切知道這個信息就是女朋友發送的呢，因為公鑰是通過公開途徑就能得到，有可能是其他人使用我的公鑰做的惡作劇呢？或者說女朋友將來抵賴，說根本沒傳送過這個信息呢？
第三種場景：女朋友為了讓我確信該信息就是她發送的，可以使用她自己的私鑰對信息進行加密，得到密文，發送給我，我通過公開途徑得到女朋友的公鑰，利用女朋友的公鑰對密文進行解密，如果能解密開，則證明了信息確實是女朋友發送的，如果解不開，則說明信息不是女朋友發送的，這樣就解決了女朋友的身份確認問題。實現了抗抵賴功能。總結非對稱密鑰的兩個用法，很好的解決了信息通信的機密性、身份認證、抗抵賴等問題，但實際在實現過程中，我們會發現非對稱密鑰也有個問題，就是非對稱算法複雜，對長信息進行加密，比非對稱算法慢100倍甚至上千倍，會慢的無法接受。針對該問題，在通信係統中，又引入了一種新的算法，信息摘要算法。
數字摘要算法和現實生活中的指紋識別或者虹膜識別一樣，具有三個典型的特征：一是原實體信息量大，而摘要後的信息量要小很多；二是實體與摘要一一對應，不同的實體不可能生成一樣的摘要，不同的摘要肯定對應不同的實體；三是算法不可逆，通過摘要無法還原或推導出信息實體。這樣的一個算法過程就稱為摘要算法。目前采用的摘要算法主要有 MD5和SHA1，其中信息編碼中的一個字節的改變，都將導致輸出摘要的改變。目前三種算法都介紹完了，實際通信過程中，往往綜合利用三種算法，進行安全通信。
數字簽名的過程。首先將發送方A要發送的明文，通過摘要算法生成信息摘要，然後用發送發A的私鑰對摘要進行加密，形成摘要的密文，我們稱該密文為數字簽名。將數字簽名和明文一起打包發送給接收方。接收方B用戶收到信息後將數字簽名，使用用戶A的公鑰進行解密，得到簽名前的信息摘要。另外接收方B將與數字簽名一起發送的明文進行與A用戶相同的摘要算法得到信息摘要，與解密數字簽名後的信息摘要進行對比，如果一致，就說明信息沒有被篡改，同時也表示信息確實是用戶A發出的，有效解決了信息傳輸過程中的數據完整性、身份認證、和抗抵賴等問題，同時由於信息摘要數據短，有效避免了非對稱算法加密長數據慢的問題，同時信息摘要與原明文信息一一對應，對摘要進行簽名，與對原明文進行簽名所獲得的效果一樣，一般簽名就是對原明文信息摘要用私鑰進行加密，完成一個數字簽名的過程。
剛解釋完了數字簽名，我們再來來看看數字信封的過程。數字信封過程是：發送發用戶A要發送一個信息給接收方用戶B明文信息，通過對稱密鑰對明文信息進行加密，形成密文，然後通過公開途徑獲取接收方用戶B的公鑰，用該公鑰對對稱密鑰進行加密，形成數字信封，將對稱密鑰加密後的密文和數字信封一起傳送給接收方。接收方B獲取密文和數字信封後，通過獨有的私鑰對數字信封進行解密得到對稱密鑰，然後使用對稱密鑰對密文進行解密得到明文。這就完成了一個數字信封的通信過程。數字信封綜合利用對稱密鑰加密運算速度快和非對稱密鑰加密強度高、密鑰分發容易的特點，使用非對稱密鑰來分發對稱密鑰，用對稱密鑰對明文進行加密，保障了通信過程中，信息傳輸的機密性問題。
數字信封的一個典型應用過程，清晰地表示了發送方用戶A要發送明文給接收方用戶B，通過綜合利用數字簽名、數字信封等技術，確保整個通信過程的機密性、完整性、身份認證和抗抵賴。首先：發送方A將需要發送的明文通過摘要算法形成數字摘要，然後使用A的私鑰進行加密形成數字簽名，然後將要發送的明文和數字簽名及發送方A的公鑰打包使用對稱密鑰進行加密形成密文，然後用接收方的公鑰對該對稱密鑰進行加密形成數字信封，將密文和數字信封一起發送給接收方B用戶。接收方用戶B收到信息後，使用接收方B的私鑰對數字信封進行解密，得到對稱密鑰，然後用該對稱密鑰對密文進行解密，還原出加密前的明文、發送方的數字簽名、發送方的公開密鑰。將明文通過與發送方同樣的算法進行摘要算法得到摘要，另外利用發送方的公開密鑰對數字簽名進行解密得到發送消息明文的數字摘要，比較兩摘要，如果相同則表示信息確實是發送方用戶A發送的，且傳輸過程中沒有被篡改，因為有發送方對信息摘要進行私鑰加密，私鑰隻有發送方用戶A所有和保管，表明了信息發送方的確是A用戶，有效防止以後A用戶對所發信息的抵賴。由於在網絡上傳輸的都是密文，有效降低了信息泄露的風險。所有綜合使用，最終，有效解決了信息通信過程中麵臨的四個問題：機密性，完整性、身份認證和抗抵賴的需求，是信息安全的有效解決方案。
1.2 係統代碼暴露情況
這個我話題我也不班門弄斧，還是由研發人員去做。不過，如果某天我需要做這些，再去學習了
2、網絡安全：
2.1 本地安全
記得在學校，我們老師就用netstat命令查看各個端口的使用情況。今天，查了些資料，把具體的使用寫下來，方麵以後自己用。
Netstat命令是Windows內置的一種網絡測試工具，通過這個命令，就可以檢測到第一種情況所有可能出現的東西。
● Netstat命令語法
NETSTAT [-a] [-b] [-e] [-n] [-o] [-p proto] [-r] [-s] [-v] [interval]
○ 參數說明
-a：顯示所有連接和監聽端口。
-b：顯示包含於創建每個連接或監聽端口的可執行組件。在某些情況下已知可執行組件擁有多個獨立組件，並且在這些情況下包含於創建連接或監聽端口的組件序列被顯示。這種情況下，可執行組件名在底部的[ ]中，頂部是其調用的組件等，直到TCP/IP部分。注意此選項執行可能需要很長的時間，如果沒有足夠權限可能失敗。
-e：顯示以太網統計信息。此選項可以與“-s”選項組合使用。
-n：以數字形式顯示地址和端口號。
-o：顯示與每個連接相關的所屬進程ID。
-p proto：顯示proto指定的協議的連接;proto可以是下列協議之一，TCP、UDP、TCPv6或UDPv6。如果與“-s”選項一起使用可顯示按協議統計信息，proto可以是下列協議之一：IP、IPv6、ICMP、ICMPv6、TCP、TCPv6、UDP和UDPv6。
-r：顯示路由表。
-s：顯示按協議統計信息。默認顯示IP、IPv6、ICMP、ICMPv6、TCP、TCPv6、UDP和UDPv6的統計信息。
-p選項用於指定默認情況的子集。
-v：與“-b”選項一起使用時將顯示包含於為所有可執行組件創建連接或監聽端口的組件。
Interval：重新顯示選定統計信息，每次顯示暫停時間間隔(以秒計)。按【Ctrl+C】組合鍵停止重新顯示統計信息。如果省略，netstat顯示當前配置信息(隻顯示一次)
2.2 網絡主機安全
這個是我問公司的網絡工程師得來的，有一種檢測工具叫（HostScan）的，安裝在服務器上，就可以掃描主機的IP地址、IP端口還有網絡服務等。然後我下載了這個工具使用了一把，操作也很簡單，這裏就不做詳細的描述了，不過每個數據的含義，希望自己根據實際情況慢慢摸索，畢竟工具是死的，人是活的唄。
2.3 漏洞檢測
這個話題僅僅作為拋磚引玉用，漏洞的檢測很複雜，我們需要專業的去了解。一般的公司，都有自己的網絡工程師，這些，讓他們保證就可以啦。我們測試工程師，把主要的精力放在產品安全的測試上吧。（以上言論僅代表作者的個人觀點，不代表51Testing觀點）
需求不明確的情況下如何進行測試？
1.根據客戶的功能點整理測試需求追朔表：