HTTP請求和數據安全

HTTP請求

1.超文本傳輸協議.
2.http請求過程.

1> http協議: 超文本傳輸協議(Hypertext Transfer Protocol)

http協議規定了客戶端和服務器之間的數據傳輸格式.
http協議是在網絡開發中最常用的協議.不管是移動客戶端還是PC端,訪問網絡資源經常使用http協議.

http優點:
<1> 簡單快速:
http協議簡單,通信速度很快.               
<2> 靈活:
http協議允許傳輸任意類型的數據.
<3> http協議是短連接(非持續性連接)
http協議限制每次連接只處理一個請求,服務器對客戶端的請求作出響應后,馬上斷開連接.這種方式可以節省傳輸時間.

2> http協議的使用;

完整的http通信分為兩步:

<1> 請求:客戶端向服務器索要數據.

http協議規定:一個完整的http請求包含'請求行','請求頭','請求體'三個部分;               
'請求行':包含了請求方法,請求資源路徑,http協議版本.
"GET /resources/images/ HTTP/1.1"             
'請求頭':包含了對客戶端的環境描述,客戶端請求的主機地址等信息.
"Accept: text/html // 客戶端所能接收的數據類型"
"Accept-Language: zh-cn // 客戶端的語言環境"
"Accept-Encoding: gzip // 客戶端支持的數據壓縮格式"
"Host: m.baidu.com // 客戶端想訪問的服務器主機地址"
"User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0 // 客戶端的類型,客戶端的軟件環境 "             
'請求體':客戶端發給服務器的具體數據,比如文件/圖片等.

<2> 響應:服務器返回客戶端想要的數據.

http協議規定:一個完整的http響應包含'狀態行','響應頭','實體內容'三個部分;

'狀態行':包含了http協議版本,狀態嗎,狀態英文名稱.
"HTTP/1.1 200 OK"

'響應頭':包含了對服務器的描述,對返回數據的描述.
"Content-Encoding: gzip // 服務器支持的數據壓縮格式"
"Content-Length:  1528 // 返回數據的長度"
"Content-Type:  application/xhtml+xml;charset=utf-8 // 返回數據的類型"
"Date: Mon, 15 Jun 2015 09:06:46 GMT // 響應的時間"
"Server: apache  // 服務器類型"

'實體內容':服務器返回給客戶端的具體數據(圖片/html/文件...).

3> 發送http請求:

在iOS開發中,發送http請求的方案有很多,常見的有如下幾種:

<1> 蘋果原生:
  • NSURLConnection:用法簡單,古老經典的一種方案.
  • NSURLSession:iOS7以后推出的技術,功能比NSURLConnection更加強大.
  • CFNetWork:NSURL 的底層,純C語言,一般不用.
<2> 第三方框架:
  • ASIHttpRequest:http終結者,功能很強大,可惜作者已停止更新.
  • AFNetWorking:簡單易用,提供了基本夠用的常用功能,維護和使用者多.
  • MKNetWorkKit:簡單易用,產自印度,維護和使用者少.
  • 在開發中,一般使用第三方框架.

GET 和 POST

1.GET 和 POST的區別?
2.用POST方法發送登陸請求.

<1> http方法: http協議定義了很多方法對應不同的資源操作,其中最常用的是GET 和 POST 方法.

例如:GET、POST、OPTIONS、HEAD、PUT、DELETE、TRACE、CONNECT、PATCH
增:PUT
刪:DELETE
改:POST
查:GET

<2> 參數

因為 GET 和 POST 可以實現上述所有操作,所以,在現實開發中,我們只要會用GET 和 POST 方法就可以了.
在與服務器交互時,有時候需要給服務器發送一些數據,比如登錄時需要發送用戶名和密碼.
參數:就是指傳遞給服務器的具體數據.

<3> GET 和 POST 的主要區別表現在參數的傳遞上.

#######"GET":
GET的本質是從服務器得到數據,效率更高.并且GET請求可以被緩存.
'注意': 網絡緩存數據,保存在SQLite的數據庫中(路徑:NSHomeDirectory()).

查看緩存數據命令行:
'cd 文件目錄'  (打開文件目錄)
'ls'  查看當前文件下目錄
'sqlite3 Cache.db'  打開數據庫
'.tables'    查看數據庫中的表單
'select * from cfurl_cache_response;'  查看服務器響應緩存
'select * from cfurl_cache_receiver_data;'  查看服務器返回的數據緩存

在請求 URL 后面以 ? 的形式跟上發給服務器的參數,參數以 "參數名"="參數值"的形式拼接,多個參數之間用 & 分隔.
注意:GET的長度是有限制的,不同的瀏覽器有不同的長度限制,一般在2~8K之間.
#######"POST":
POST的本質是向服務器發送數據,也可以獲得服務器處理之后的結果,效率不如GET.POST請求不可以被緩存,每次刷新之后都需要重新提交表單.
發送給服務器的參數全部放在'請求體'中;
理論上,POST傳遞的數據量沒有限制.
注意:所有涉及到用戶隱私的數據(密碼/銀行卡號等...)都要用POST的方式傳遞.

<4>注意:URL中不能出現空格以及中文等特殊符號.

1>URL中,所有的字符都必須是 ASCII 碼;
2>URL中不能出現中文和特殊符號(如空格);

所以,如果 URL 中出現了中文,需要添加百分號轉譯.
urlString = [urlString stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
<5> POST 發送登陸請求:
注意:
1> 用可變請求: NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
2> 指定請求方法: request.HTTPMethod = @"POST";
3> 設置請求體數據: request.HTTPBody = data;
// 實例化請求體字符串
NSString *body = [NSString stringWithFormat:@"username=%@&password=%@",self.userName.text,self.password.text];
// 將字符串轉換成二進制數據
NSData *data = [body dataUsingEncoding:NSUTF8StringEncoding];
4> 發送異步網絡請求.
// 網絡請求的回調.
// NSURLResponse *response: 服務器響應
// NSData *data: 服務器返回的數據
// NSError *connectionError: 連接錯誤處理
[NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue mainQueue] completionHandler:^(NSURLResponse *response, NSData *data, NSError *connectionError)

保存用戶信息

1.偏好設置保存用戶信息.

<1>如果用戶登陸成功,就保存用戶信息.下次直接從偏好設置中讀取用戶信息,以此做到用戶只需要輸入一次賬號和密碼,以后登陸就可以不用再次輸入.

1>.登陸成功,保存用戶信息(偏好設置)
2>.再次進入,直接顯示用戶之前保存的信息.避免用戶重復輸入.
// 偏好設置存儲用戶信息
-(void)savaUserInfo    {
// 實例化偏好設置對象(單例)
NSUserDefaults *User = [NSUserDefaults standardUserDefaults];
// 保存用戶名
[User setObject:self.userName.text forKey:kITUSERNAMEKEY];
// 保存用戶密碼
[User setObject:pass forKey:kITUSERPASSKEY];
// 同步保存用戶信息
[User synchronize];
}
// 加載偏好設置中的用戶信息
- (void)loadUserInfo    {
NSUserDefaults *User = [NSUserDefaults standardUserDefaults];
if ([User objectForKey:ITUSERNAMEKEY]) {
self.userName.text = [User objectForKey:ITUSERNAMEKEY];
}if ([User objectForKey:ITUSERPASSKEY]) {
self.password.text = [User objectForKey:ITUSERPASSKEY];
};    } 

<2> 用戶登陸業務邏輯

<1> 用戶登陸需要一個單獨的控制器,因為只需要登陸一次(Login.storyboard). 應用程序需要有一個入口:main.storyboard: app 主頁面
<2> 判斷用戶是否登陸成功過(通過偏好設置中存儲的用戶信息判斷)

1> 如果偏好設置中存有用戶信息(說明之前登陸成功過),直接進入 app 主頁面 :main.storyboard
2> 如果偏好設置中不存在用戶信息(第一次登陸或者之前注銷了用戶信息),進入登陸界面 :Login.storyboard
3> 如果用戶登陸成功,跳轉到 app 主頁面:main.storyboard.并且在偏好設置中保存用戶信息.
4> 如果用戶點擊注銷按鈕,注銷用戶信息,返回到登陸頁面.

<3> 問題: 用戶密碼不能以明文的形式保存,需要對用戶密碼加密之后再保存!

密碼的安全原則:
1> 本地和服務器都不允許保存用戶的密碼明文.
2> 在網絡上,不允許傳輸用戶的密碼明文.現代密碼學趣聞! 中途島海戰(AF)

<4> 數據加密算法:

1> 對稱加密算法:加密和解密使用同一密鑰.加密解密速度快,要保證密鑰安全.適合給大數據加密.
2> 非對稱加密算法:使用公鑰加密,私鑰解密.或者使用私鑰加密,公鑰解密.更加安全,但是加密解密速度慢,適合給小數據加密.

<5> 小技巧:

openssl :是一個強大的安全套接字層密碼庫,囊括主要的密碼算法,常用的密鑰和證書封裝管理功能以及 SSL 協議.提供豐富的應用程序測試功能.

終端命令:
echo hello |openssl md5
echo hello |openssl sha1
echo hello |openssl sha -sha256
echo hello |openssl sha -sha512

信息安全加密

常用加密方法:

1> base64
2> MD5
3> MD5加鹽
4> HMAC
5> 時間戳密碼(用戶密碼動態變化)

1> base64

base64 編碼是現代密碼學的基礎.
原本是 8個bit 一組表示數據,改為 6個bit一組表示數據,不足的部分補零,每 兩個0 用 一個 = 表示.
用base64 編碼之后,數據長度會變大,增加了大約 1/3 左右.
base64 基本能夠達到安全要求,但是,base64能夠逆運算,非常不安全!
base64 編碼有個非常顯著的特點,末尾有個 '=' 號.

利用終端命令進行base64運算:
將文件 meinv.jpg 進行 base64運算之后存儲為 meinv.txt
base64 meinv.jpg -o meinv.txt 
// 講meinv.txt 解碼生成 meinv.png
base64 -D meinv.txt -o meinv.png
// 將字符串 "hello" 進行 base 64 編碼 結果:aGVsbG8=
echo "hello" | base64
// 將 base64編碼之后的結果 aGVsbG8= 反編碼為字符串
echo aGVsbG8= | base64 -D

2> MD5 -- (信息-摘要算法) 哈希算法之一.

把一個任意長度的字節串變換成一定長度的十六進制的大整數. 注意,字符串的轉換過程是不可逆的.
用于確保'信息傳輸'完整一致.

MD5特點:

1.壓縮性: 任意長度的數據,算出的 MD5 值長度都是固定的.
2.容易計算: 從原數據計算出 MD5 值很容易.
3.抗修改性: 對原數據進行任何改動,哪怕只修改一個字節,所得到的 MD5 值都有很大區別.
4.弱抗碰撞: 已知原數據和其 MD5 值,想找到一個具有相同 MD5 值的數據(即偽造數據)是非常困難的.
5.強抗碰撞: 想找到兩個不同數據,使他們具有相同的 MD5 值,是非常困難的.

MD5 應用:

  1. 一致性驗證: MD5 將整個文件當做一個大文本信息,通過不可逆的字符串變換算法,產生一個唯一的 MD5 信息摘要.
    就像每個人都有自己獨一無二的指紋,MD5 對任何文件產生一個獨一無二的"數字指紋".
    利用 MD5 來進行文件校驗, 被大量應用在軟件下載站,論壇數據庫,系統文件安全等方面.
  2. 數字簽名;
  3. 安全訪問認證;

3> MD5加鹽

MD5 本身是不可逆運算,但是,目前網絡上有很多數據庫支持反查詢.
MD5加鹽 就是在密碼哈希過程中添加的額外的隨機值.
注意:加鹽要足夠長,足夠復雜.

4> HMAC

HMAC 利用哈希算法,以一個密鑰和一個消息為輸入,生成一個消息摘要作為輸出.
HMAC 主要使用在身份認證中;

認證流程:

  1. 客戶端向服務器發送一個請求.
  2. 服務器接收到請求后,生成一個'隨機數'并通過網絡傳輸給客戶端.
  3. 客戶端將接收到的'隨機數'和'密鑰'進行 HMAC-MD5 運算,將得到的結構作為認證數據傳遞給服務器. (實際是將隨機數提供給 ePass,密鑰也是存儲在 ePass中的)
  4. 與此同時,服務器也使用該'隨機數'與存儲在服務器數據庫中的該客戶'密鑰'進行 HMAC-MD5 運算,如果服務器的運算結果與客戶端傳回的認證數據相同,則認為客戶端是一個合法用法.

5> 時間戳密碼(用戶密碼動態變化)

相同的密碼明文 + 相同的加密算法 ===>> 每次計算都得出不同的結果.可以充分保證密碼的安全性.
原理:將當前時間加入到密碼中;
因為每次登陸時間都不同,所以每次計算出的結果也都不相同.
服務器也需要采用相同的算法.這就需要服務器和客戶端時間一致.

注意:服務器端時間和客戶端時間,可以有一分鐘的誤差(比如:第59S發送的網絡請求,一秒鐘后服務器收到并作出響應,這時服務器當前時間比客戶端發送時間晚一分鐘).
這就意味著,服務器需要計算兩次(當前時間和一分鐘之前兩個時間點各計算一次).
只要有一個結果是正確的,就可以驗證成功!
可用于IP輔助/手機綁定...

鑰匙串訪問

1.鑰匙串訪問

蘋果在 iOS 7.0.3 版本以后公布鑰匙串訪問的SDK. 鑰匙串訪問接口是純C語言的.
鑰匙串使用 AES 256加密算法,能夠保證用戶密碼的安全.
鑰匙串訪問的第三方框架(SSKeychain),是對 C語言框架 的封裝.注意:不需要看源碼.
鑰匙串訪問的密碼保存在哪里?只有蘋果才知道.這樣進一步保障了用戶的密碼安全.

使用步驟:

獲取應用程序唯一標識.
NSString *bundleId = [NSBundle mainBundle].bundleIdentifier;

"注意"三個參數:
1>.密碼:可以直接使用明文.鑰匙串訪問本身是使用 AES 256加密,就是安全的.所以使用的時候,直接傳遞密碼明文就可以了.
2>.服務名:可以隨便亂寫,建議唯一! 建議使用 bundleId.
bundleId是應用程序的唯一標識,每一個上架的應用程序都有一個唯一的 bundleId
3>.賬戶名:直接用用戶名稱就可以.
1.利用第三方框架,將用戶密碼保存在鑰匙串
[SSKeychain setPassword:self.pwdText.text forService:bundleId account:self.usernameText.text];

2.從鑰匙串加載密碼
self.pwdText.text = [SSKeychain passwordForService:bundleId account:self.usernameText.text];

指紋識別

1.指紋識別用法

指紋識別功能是 iphone 5S之后推出的.SDK是 iOS 8.0 推出!
推出指紋識別功能的目的,是為了簡化移動支付環節,占領移動支付市場.

使用步驟:

1> 導入框架;
#import <LocalAuthentication/LocalAuthentication.h>
2> 指紋識別的實現:
1. 需要判斷手機系統版本是否是 iOS 8.0 以上的版本.只有 iOS 8.0 以上才支持.
// 獲得當前系統版本號
float version = [UIDevice currentDevice].systemVersion.floatValue;
// 判斷當前系統版本
if (version < 8.0 )  {
                     NSLog(@"系統版本太低,請升級至最新系統");
                     return;
}
2. 實例化指紋識別對象,判斷當前設備是否支持指紋識別功能(是否帶有TouchID).
// 1> 實例化指紋識別對象
LAContext *laCtx = [[LAContext alloc] init];
// 2> 判斷當前設備是否支持指紋識別功能.
if (![laCtx canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:NULL]){
// 如果設備不支持指紋識別功能
                     NSLog(@"該設備不支持指紋識別功能");
                     return;
};
3.指紋登陸(默認是異步方法)
// 指紋登陸
[laCtx evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:@"指紋登陸" reply:^(BOOL success, NSError *error)  {
// 如果成功,表示指紋輸入正確.
         if (success) {
         NSLog(@"指紋識別成功!");
   }else {                    
         NSLog(@"指紋識別錯誤,請再次嘗試");
                 } 
            }];
        }
    }}
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,606評論 6 533
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,582評論 3 418
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,540評論 0 376
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,028評論 1 314
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,801評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,223評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,294評論 3 442
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,442評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,976評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,800評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,996評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,543評論 5 360
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,233評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,662評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,926評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,702評論 3 392
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,991評論 2 374

推薦閱讀更多精彩內容