摘要：大致意思是模擬登陸，一時(shí)手癢，本文將帶領(lǐng)大家一起實(shí)現(xiàn)這個(gè)操作。方案事實(shí)上為了探究這個(gè)有意思的問(wèn)題，我專門動(dòng)手做一個(gè)有意思的實(shí)驗(yàn)。這說(shuō)明了服務(wù)端驗(yàn)證了輸入，并判斷我們的請(qǐng)求不符合正常邏輯。過(guò)程不再贅述，結(jié)果是中的必須和中的對(duì)應(yīng)。

本文來(lái)自我在 SegmentFault 上的 回答，我紀(jì)錄了其中精彩的部分到本博客。

大致意思是模擬登陸 segmentfault.com，一時(shí)手癢，本文將帶領(lǐng)大家一起實(shí)現(xiàn)這個(gè)操作。

這個(gè)問(wèn)題問(wèn)的非常好，但可惜的是大家的回復(fù)都是紙上談兵未經(jīng)探討，最前最高票的回答的竟然說(shuō)讓下抓包工具，簡(jiǎn)直可笑啊，chrome下F12直接就可以看到賬號(hào)密碼是明文發(fā)送的何必還要抓包？另外的題主的http頭就是從chrome下復(fù)制的。

根據(jù)竟然我判斷你的問(wèn)題的原因是發(fā)送了過(guò)多的http頭，其中Content-Length是明顯有問(wèn)題的，這個(gè)代表內(nèi)容長(zhǎng)度，你這次抓包是49，但下次換個(gè)賬號(hào)密碼可就真不一定了。比如，如果賬號(hào)密碼過(guò)長(zhǎng)，可能就會(huì)導(dǎo)致截?cái)?，那么無(wú)論如何都會(huì)提示密碼錯(cuò)誤的（因?yàn)橹话l(fā)送了一部分的密碼過(guò)去）。

事實(shí)上為了探究這個(gè)有意思的問(wèn)題，我專門動(dòng)手做一個(gè)有意思的實(shí)驗(yàn)。這里就用個(gè)最簡(jiǎn)單的腳本語(yǔ)言node.js中的ajax模型來(lái)重新構(gòu)建操作過(guò)程。

我們先去登陸頁(yè)--源碼頁(yè)去大致看一下，其中

這個(gè)跨域請(qǐng)求加載js腳本，看名字應(yīng)該是和登陸有關(guān)的，我們這邊使用嘗試訪問(wèn)下，結(jié)果不用想，一篇亂糟糟的。

根據(jù)命名規(guī)范，我們猜測(cè)壓縮前的名字可能就是叫login.js，我們看下他刪除了沒有，我們嘗試訪問(wèn)https://dfnjy7g2qaazm.cloudfront.net/v-575e20ec/user/script/login.js，嗯哼還在，看來(lái)他們的發(fā)布人員可能不是處女座的。

那好我們往下看下這里：

$("form[action="/api/user/login"]").submit(function() {
  var data, url;
  url = "/api/user/login";
  data = $(this).serialize();
  $.post(url, data, function(d) {
    if (!d.status) {
      return location.href = d.data;
    }
  });
  return false;
});

代碼非常簡(jiǎn)單，我們知道了請(qǐng)求結(jié)果中status為0時(shí)代表登陸成功，同時(shí)我們也知道了后臺(tái)執(zhí)行登陸請(qǐng)求頁(yè)是/api/user/login，即https://segmentfault.com/api/user/login，我們?cè)L問(wèn)一下，嗯404。這說(shuō)明了服務(wù)端驗(yàn)證了輸入，并判斷我們的請(qǐng)求不符合正常邏輯。下面我們開始偽造請(qǐng)求頭。

我們用類似chrome的現(xiàn)代化瀏覽器，正常訪問(wèn)https://segmentfault.com/user/login,按下F12,選擇network面板開始監(jiān)控請(qǐng)求，然后我們隨意填寫賬號(hào)密碼，點(diǎn)擊登陸。

這個(gè)時(shí)候下面會(huì)有一條信息，我們提取其中的Request Header如下

POST /api/user/login?_=93e1b923149fb56c4fd329fe95ea4001 HTTP/1.1
Host: segmentfault.com
Connection: keep-alive
Content-Length: 46
Pragma: no-cache
Cache-Control: no-cache
Accept: */*
Origin: https://segmentfault.com
X-Requested-With: XMLHttpRequest
User-Agent: xxxx
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
DNT: 1
Referer: https://segmentfault.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4
Cookie: PHPSESSID=web5~to8l5ovmt9t3jkb84aevuqf151; Hm_lvt_e23800c454aa573c0ccb16b52665ac26=1465799317; Hm_lpvt_e23800c454aa573c0ccb16b52665ac26=1465799317; _ga=GA1.2.915515414.1465799317; _gat=1

我們只需要同樣發(fā)送這些請(qǐng)求到服務(wù)器上，理論上就不會(huì)有問(wèn)題，同時(shí)也不會(huì)再404了。

這里面的數(shù)據(jù)中，有些不需要發(fā)的，有些是必須要發(fā)送的。我們可以一一測(cè)試下。

我們這里使用nodejs來(lái)簡(jiǎn)單寫段代碼測(cè)試下服務(wù)端所驗(yàn)證的參數(shù)。

枯燥的測(cè)試就是不斷刪減請(qǐng)求來(lái)看看服務(wù)端會(huì)不會(huì)返回404。過(guò)程不再贅述，結(jié)果是：

querystring中的 _必須和Cookie中的PHPSESSID對(duì)應(yīng)。

X-Requested-With的值需要帶ajax請(qǐng)求標(biāo)志，即XMLHttpRequest

Referer的值

看來(lái)他們服務(wù)端還是蠻嚴(yán)格的。

var superagent = require("superagent");


superagent.post("https://segmentfault.com/api/user/login?_=7ef046ad4f224034d7b51655238bd870")
    .set("Referer", "https://segmentfault.com/user/login")
    .set("X-Requested-With", "XMLHttpRequest")
    .set("Cookie", "PHPSESSID=web1~395mahoqliohh5kclv894ibpr3; _gat=1; _ga=GA1.2.1234754628.1465797373; Hm_lvt_e23800c454aa573c0ccb16b52665ac26=1465797373; Hm_lpvt_e23800c454aa573c0ccb16b52665ac26=1465797538")
    .send({
        mail: "xxxxxx",
        password: "xxxx"
    })
    .type("form")
    .end(function(err, res) {
        if (err || !res.ok) {
            console.log(err.status);
        } else {
            console.log("yay got " + JSON.stringify(res.body));
        }
    });

同時(shí)，開源在 GitHub 上，地址 segmentfault_loginer：https://github.com/Rozbo/segmentfault_loginer。