WEB安全入門 1 （http篇）

本文為網路搬運整合，僅供學習使用，侵權聯系洗掉！

Web安全崗位需求

1 職位描述

對公司各類系統進行安全加固；

對公司網站、業務系統進行安全評估測驗（黑盒、白盒測驗）

對公司安全事件進行回應、清理后門、根據日志分析攻擊途徑

安全技術研究，包括安全防范技術、黑客技術等；

跟蹤最新漏洞資訊，進行業務產品的安全檢查，

2 崗位要求

熟悉Web滲透測驗方法和攻防技術，包括SQL注入、XSS跨站、CSRF偽造請求、命令執行等OWSP TOP10 安全漏洞與防御；

熟悉Linux、Windows不同平臺的滲透測驗，對網路安全、系統安全、應用安全有深入理解和自己的認識；

熟悉國內外安全工具，包括Kali、Linux、Metasploit、Nessus、Namp、AWVS、Burp等；

對Web安全整體有深刻理解，有一定漏洞分析和挖掘能力；

本篇文章目錄參考鏈接：https://www.secpulse.com/archives/144410.html

一． HTTP基礎

1. HTTP協議介紹

(1) HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）,是因特網上應用最為廣泛的一種網路傳輸協議，所有的WWW檔案都必須遵守這個標準；

(2) HTTP是基于TCP/IP通信協議來傳遞資料的（HTML 檔案, 圖片檔案, 查詢結果等）；

(3) HTTP協議通常承載于TCP協議之上，有時也承載于TLS或SSL協議層之上，這個時候，就成了我們常說的HTTPS；

(4) HTTP是一個應用層協議，由請求和回應構成，是一個標準的客戶端服務器模型,HTTP是一個無狀態的協議；

(5) HTTP默認的埠號為80，HTTPS的埠號為443；

1. HTTP作業流程

（1）用戶在瀏覽器輸入URL網址；

（2）瀏覽器根據URL網址中的域名，通過DNS決議出服務器IP地址；

（3）然后通過TCP/IP協議來和服務端建立鏈接（TCP三次握手）；

（4）建立鏈接后，發送請求給服務器；

（5）服務器回復瀏覽器請求；

（6）瀏覽器拿到對應的html等資源，渲染頁面

3.  短鏈接

短連接的操作步驟是：

建立連接——資料傳輸——關閉連接，...建立連接——資料傳輸——關閉連接；

如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費較多時間和帶寬；

4. 長鏈接

長鏈接,指在一個連接上可以連續發送多個資料包，

在連接保持期間，如果沒有資料包發送，需要雙方發鏈路檢測包，

長鏈接操作步驟： 建立連接——資料傳輸...（保持連接）...資料傳輸——關閉連接，

長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間，

5. HTTP存在的安全問題

可能被竊聽

(1) HTTP 本身不具備加密的功能,HTTP 報文使用明文方式發送;

(2) 由于互聯網是由聯通世界各個地方的網路設施組成,

所有發送和接收經過某些設備的資料都可能被截獲或窺視，(例如大家都熟悉的抓

包工具:Wireshark);

認證問題

（1）無法確認你發送到的服務器就是真正的目標服務器(可能服務器是偽裝的)；

（2）無法確定回傳的客戶端是否是按照真實意圖接收的客戶端(可能是偽裝的客戶端)；

（3）可能被篡改

請求或回應在傳輸途中，遭攻擊者攔截并篡改內容的攻擊被稱為中間人攻擊，

二．HTTPS基礎

基于HTTP存在的一些安全問題，出現了HTTPS來解決這類問題

1. HTTPS介紹

超文本傳輸安全協議（英語：Hypertext Transfer Protocol Secure，縮寫：HTTPS，

常稱為HTTP over TLS，HTTP over SSL或HTTP Secure）,是一種通過計算機網

絡進行安全通信的傳輸協議，

HTTPS經由HTTP進行通信，但利用SSL/TLS來加密資料包，

HTTPS開發的主要目的，是提供對網站服務器的身份認證，保護交換資料的隱私

與完整性，簡言之，就是對HTTP加了一層安全策略

1. HTTPS怎么解決HTTP存在的安全問題的？

HTTPS是在通信介面部分用 TLS(Transport Layer Security 傳輸層安全性協議)；

TLS協議采用主從式架構模型，用于在兩個應用程式間通過網路創建起安全的連

接，防止在交換資料時受到竊聽及篡改；

3. SSL和TLS的關系

(1) 傳輸層安全性協議（英語：Transport Layer Security，縮寫作 TLS），及其前

身安全套接層（Secure Sockets Layer，縮寫作 SSL）是一種安全協議，目的

是為互聯網通信，提供安全及資料完整性保障，

(2) 網景公司（Netscape）在1994年推出首版網頁瀏覽器，網景導航者時，推出

HTTPS協議，以SSL進行加密，這是SSL的起源，

(3) IETF將SSL進行標準化，1999年公布第一版TLS標準檔案，隨后又公布RFC

5246 （2008年8月）與 RFC 6176 （2011年3月），

在瀏覽器、電子郵件、即時通信、VoIP、網路傳真等應用程式中，廣泛支持這

個協議，

4 . TLS/SSL 協議

HTTPS 協議的主要功能基本都依賴于 TLS/SSL 協議，

TLS/SSL 的功能實作主要依賴于三類基本演算法：散列函式 、對稱加密和非對稱

加密，其利用非對稱加密實作身份認證和密鑰協商，對稱加密演算法采用協商的密

鑰對資料加密，基于散列函式驗證資訊的完整性，

5.  HTTPS作業流程的通俗解釋

信鴿解釋，愛麗絲和鮑勃是通過信鴿異地聯系

 開始階段

愛麗絲給鮑勃發了個飛鴿傳書，鮑勃收到了，很happy

但壞蛋馬洛里攔截了愛麗絲的鴿子并且篡改了資訊呢？

鮑勃就沒有辦法去知道愛麗絲發出的資訊在傳遞程序中遭到了修改，

于是，愛麗絲和鮑勃見面商量后，決定對飛鴿傳書內容進行加密，

加密方式：他們會將資訊中的每個字母按照字母表中的順序前移三位，

比如，D→A，E→B，F→C，如此一來，原文為 “secret” 的資訊就變成了 “pbzobq” ，

這下，當愛麗絲給鮑勃再發了個飛鴿傳書時，

壞蛋馬洛里攔截了資訊也沒用；他不知道解密規則，

此時鮑勃收到資訊訊息后，再根據和愛麗絲商量的規則解密獲取資訊，

他很得意自己的聰明才智，他們的做法就是對稱加密，但他們的做法存在一些問題，

他們需要見面才能確定加密方式，這顯然不方便，

問題是如果愛麗絲和鮑勃在開始用信鴿傳信之前沒有見過面怎么辦，

他們沒有一個安全的方式來確立密匙，如果他們自己來在信中傳遞密匙，

馬洛里就會截獲資訊并發現密匙，

這就使得馬洛里可以在愛麗絲和鮑勃開始加密他們的資訊之前或之后，

閱讀到他們資訊的內容并按照她的意愿來篡改資訊，

這是一個中間人攻擊的典型例子，避免這個問題的唯一方法就是收發信的兩方一起確

定加密方式，

 通過信鴿傳遞盒子

所以愛麗絲和鮑勃就想出了一個更好的系統，

當鮑勃想要給愛麗絲發送資訊時，他會按照如下的步驟來進行：

鮑勃向愛麗絲送一只沒有攜帶任何資訊的鴿子，

愛麗絲給鮑勃送回鴿子，并且這只鴿子帶有一個有開著的鎖的盒子，愛麗絲保管著鎖

的鑰匙

鮑勃把信放進盒子中，把鎖鎖上然后把盒子送給愛麗絲，

愛麗絲收到盒子，用鑰匙打開然后閱讀資訊，

這樣馬洛里就不能通過截獲鴿子來篡改資訊了，因為她沒有打開盒子的鑰匙，

當愛麗絲要給鮑勃發送訊息的時候同樣按照上述的流程，

愛麗絲和鮑勃所使用的流程通常被稱為非對稱密鑰加密，之所以稱之為非對稱，是因

為即使是你把資訊編碼（鎖上盒子）也不能破譯資訊（打開鎖住的盒子）

在術語中，盒子被稱為公匙而用來打開盒子的鑰匙被稱為私匙，

上面方式還是會存在問題，

當鮑勃收到盒子時他如何能確定這個盒子來自愛麗絲的，

而不是馬洛里截獲了鴿子然后換了一個她有鑰匙能打開的盒子呢

如何信任盒子

愛麗絲決定簽名標記一下盒子，這樣鮑勃收到盒子的時候就可以檢查簽名來確定是愛

麗絲送出的盒子了，

那么鮑勃如何打一開始就能識別出愛麗絲的簽名呢？這是個好問題，愛麗絲和鮑勃也

確實有這個問題，所以他們決定讓泰德代替愛麗絲來標記這個盒子，

那么誰是泰德呢？泰德很有名的，是一個值得信任的家伙，他會給任何人簽名并且所

有人都信任他只會給合法的人簽名標記盒子，

如果泰德可以確認索要簽名的人是愛麗絲，他就會在愛麗絲的盒子上簽名，因此馬洛

里就不可能搞到一個有著泰德代表愛麗絲簽了名的盒子，因為鮑勃知道泰德只會給他

確認過的人簽名，從而識破馬洛里的詭計，

泰德的角色在術語中被稱為認證機構，而你閱讀此文時所用的瀏覽器打包存有許多認

證機構的簽名，

所以當你首次接入一個網站的時候你可以信任來自這個站點的盒子因為你信任泰德

而泰德會告訴你盒子是合法的，

上述方式雖然比較完美的解決來存在的安全問題，

but，盒子裝東西太多太重，讓飛鴿傳書很慢，

這也是個問題

如何解決盒子太重問題

現在愛麗絲和鮑勃有了一個可靠的系統來進行交流，然他們也意識到讓鴿子攜帶盒子

比原本只攜帶信件要慢一些，

因此他們決定只有在選擇用對稱加密來給資訊編碼（還記得凱撒加密法吧？）的密匙

時，使用傳遞盒子的方法（非對稱加密），

這樣就可以二者的優點兼具了，非對稱加密的可靠性和對稱加密的高效性，

現實世界中我們不會用信鴿這樣慢的送信手段，但用非對稱加密來編碼資訊仍要慢于

使用對稱加密技術，所以我們只有在交換編碼密匙的時候會使用非對稱加密技術，

那么相信現在的你已經大概了解了HTTPS是如何作業的了～～～

參考鏈接：https://juejin.cn/post/6844903842056765447

三．HTTP協議請求回應程序

1. HTTP請求

（1）HTTP協議的請求報文

當瀏覽器向服務器發送一個請求到Web服務器,它發送一個資料塊,或請求資訊,

HTTP請求資訊包括3部分:

請求方法URI協議/版本；

請求頭(Request Header)；

請求正文；

下面是一個HTTP請求的示例：

（1）請求方法URI協議/版本

請求的第一行是“方法/內容 URL協議/協議版本名稱”：

上面的代碼中，“GET”說明請求方法，“/test.jsp”表示網路資源，中間空格，最后說明

協議和協議的版本，

根據HTTP標準，HTTP請求可以使用多種不同的請求方法，例如：HTTP1.1

允許支持七種請求方法（也叫“動作”）：GET、POST、HEAD、OPTIONS、PUT、

DELETE和TARCE，日常開發中， GET和POST是最常用的方法，主要在相關的

Web開發中，

URL路徑指定了要訪問的網路資源，一般來說，我們需要的是相對路徑，因為確定資

源位置，知道網路資源相對于服務器的根目錄的路徑就可以，所以以“/”開頭，在頭信

息結束時，宣告了通信程序中HTTP協議版本的使用版本，

需要注意，方法名稱很重要的一點是嚴格區分大小寫，有些時候，某個請求所針對的

資源可能不支持對應的請求方法，會通過不同的狀態碼給出回應，例如,服務器將返

回一個狀態碼405(方法不允許),當請求服務器或方法不理解不支持相應的時間,回傳

一個狀態碼501(沒有實作)，

（2）請求頭(Request Header)

請求頭包含了一些客戶環境和請求的內容資訊，例如,請求頭可以宣告瀏覽器內核和

語言使用,請求的長度等，

（3）請求正文

請求正文和請求頭要有空行，這個空行必須存在，說明結束請求頭傳輸，開始傳輸正

文請求，請求正文中一般包含很多資訊，例如用戶提交的用戶名和密碼之類的登陸信

息：userlogin=bingyue¤tpwd=bingyue

在真實應用中，協議的請求正文可以包含大量的資訊,而不是如示例的HTTP請

求中一樣，請求正文只有簡單的一行資料，

2 . HTTP回應

和請求報文類似，HTTP回應主要也是3個部分構成：

（1）協議狀態版本代碼描述

（2）回應頭(Response Header)

（3）回應正文

下面是一個HTTP回應的示例：

客戶端向服務器發送請求，和請求報文類似，服務器會以狀態行回應，

回應報文包括：HTTP協議的版本、結果編碼以及其他的必要資訊，如物體資訊等，

回應類別不同，回應報文里可以包含或者不含物體內容，

HTTP回應報文的首先是以狀態行開始，這些可以參考示例的代碼，

回應頭也就是報文首部，和請求頭首部一樣，包含重要的資訊，例子中我們可以看到，

比如日期時間和服務器型別以及內容長度和數量等，

參考鏈接：https://www.cnblogs.com/binyue/p/4500578.html

四．了解HTML、Javascript

1. HTML

   https://baike.baidu.com/item/HTML/97049?fr=aladdin

1. JAVACRIPT   

https://baike.baidu.com/item/JSP/141543?fr=aladdin

五． Get/Post區別

• GET 請求只能 URL 編碼，而 POST 支持多種編碼方式
• GET 請求只接受 ASCII 字符的引數，而 POST 則沒有限制
• GET 請求的引數通過 URL 傳送，而 POST 放在 Request Body 中
• GET 相對于 POST 更不安全，因為引數直接暴露在 URL 中
• GET 請求會被瀏覽器主動快取，而 POST 不會（除非自己手動設定）
• GET 請求在 URL 傳參有長度限制，而 POST 則沒有限制
• GET 產生的 URL 地址可以被收藏，而 POST 不可以
• GET 請求的引數會被完整的保留在瀏覽器的歷史記錄里，而 POST 的引數則不會
• GET 在瀏覽器回退時是無害的，而 POST 會再次提交請求

鏈接：https://www.zhihu.com/question/28586791/answer/774605294   

六． Cookie/Session是什么？

1.背景介紹      

HTTP是一種無狀態的協議，為了分辨鏈接是誰發起的，需自己去解決這個

問題，不然有些情況下即使是同一個網站每打開一個頁面也都要登錄一下，

而Session和Cookie就是為解決這個問題而提出來的兩個機制，

會話（Session）跟蹤是Web程式中常用的技術，用來跟蹤用戶的整個會話，

常用的會話跟蹤技術是Cookie與Session，Cookie通過在客戶端記錄資訊確

定用戶身份，Session通過在服務器端記錄資訊確定用戶身份，

2 . cookie的主要內容

     主要包括：名字，值，過期時間，路徑和域，

     域：其中域可以指定某一個域比如.google.com，也可以指定一個域下的具體

某臺機器比如www.google.com或者froogle.google.com，可以在java中通過

cookie.setDomain(".soncookie.com"); 設定，這個引數必須以“.”開始，

     路徑：就是跟在域名后面的URL路徑，

      路徑與域合在一起就構成了cookie的作用范圍，

     過期時間：如果不設定過期時間，則表示這個cookie的生命期為瀏覽器會

話期間，只要關閉瀏覽器視窗，cookie就消失了，這種cookie被稱為會話

cookie，會話cookie是保存在記憶體里，當然這種行為并不是規范規定的，如

果設定了過期時間，瀏覽器就會把cookie保存到硬碟上，關閉后再次打開

瀏覽器，這些cookie仍然有效直到超過設定的過期時間，

3 . session的主要內容

包括：名字，值，失效時間等，

      4 . Session和Cookie的主要區別

         (1) Cookie是把用戶的資料寫給用戶的瀏覽器;

        (2)Session技術把用戶的資料寫到用戶獨占的session中;

        (3)Session物件由服務器創建，開發人員可以呼叫request物件的

getSession方法得到session物件，

     5 . Session和Cookie的應用場景

       (1)登錄網站，今輸入用戶名密碼登錄了，第二天再打開很多情況下就直接

打開了，這個時候用到的一個機制就是cookie，

       (2)session一個場景是購物車，添加了商品之后客戶端處可以知道添加了哪

些商品，而服務器端如何判別呢，所以也需要存盤一些資訊就用session，

詳細：https://www.cnblogs.com/andy-zhou/p/5360107.html

七． Web安全專業術語

Webshell

菜刀

0day

SQL注入

上傳漏洞

XSS

CSRF

一句話木馬

其他：https://blog.csdn.net/fuhanghang/article/details/83756025

八． 滲透工具使用

1. Vmware安裝 下載地址：https://www.vmware.com/cn.html 

              密鑰：ZF3R0-FHED2-M80TY-8QYGC-NPKYF
                        YF390-0HF8P-M81RQ-2DXQE-M2UT6
                        ZF71R-DMX85-08DQY-8YMNC-PPHV8

         2. Windows/kali虛擬機安裝

         3. Phpstudy，DVWA環境搭建滲透測驗靶場

         4. Java環境變數安裝

         5. Python環境變數安裝

         6. Sqlmap

         7. Burpsuite

         8. Nmap

         9. Nessus

        10. Appscan

        11. AWVS

標籤：其他

上一篇：k8s在csdn里沒有存在感？

下一篇：SQL布爾盲注-（針對SQLi-LABS Page-1(Basic Challenges)第五關）